From jmamodio at gmail.com Sun Sep 1 00:26:28 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 31 Aug 2013 19:26:28 -0500 Subject: Akamai Edgekey issues ? Message-ID: Hi There, is anybody having any problems with sites that go through Akamai's CDN ? I'm having problems to connect to many served by them, just two examples. www.ti.com www.newark.com Cheers Jorge From emile.aben at ripe.net Sun Sep 1 20:34:22 2013 From: emile.aben at ripe.net (Emile Aben) Date: Sun, 01 Sep 2013 22:34:22 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net> Message-ID: <5223A4CE.9090505@ripe.net> On 31/08/2013 13:13, Randy Bush wrote: > could you please test with ipv6? This is what I see for various IPv6 payloads (large ICMPv6 echo requests) from all RIPE Atlas probes that where available at the time to a single "known good" MTU 1500 destination: plen fail% nr_probes 100 9.64 1266 500 9.34 1039 1000 9.94 1298 1240 9.94 1308 1241 11.62 1300 1440 12.70 890 1441 14.70 1306 1460 15.18 1304 1461 19.84 1290 1462 22.02 1294 plen: IPv6 payload length (ie. not including 40byte IPv6 header) fail%: percentage of probes that didn't get any of the 5 pkts that were sent. Note that there is a large baseline failure rate in IPv6 on RIPE Atlas probes [1], which would explain the ~10% failure rate for the smaller packets. I plan to do more analysis and start writing this up on RIPE Labs over the next few days. cheers, Emile Aben RIPE NCC [1] https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong From scott at doc.net.au Sun Sep 1 23:17:06 2013 From: scott at doc.net.au (Scott Howard) Date: Sun, 1 Sep 2013 16:17:06 -0700 Subject: couldn't get address for 'w.au': no more , In-Reply-To: References: Message-ID: It would appear there's something very unhealthy with your specific nameservers regarding .au. A direct email I sent you bounced (well, delayed warning) due to : The error that the other server returned was: 451 4.1.8 Domain of sender address scott at doc.net.au does not resolve That address fairly clearly does resolve, and I've had no problems sending email to anywhere else on the internet, so it's obviously a local issue. Scott On Sat, Aug 31, 2013 at 1:05 PM, Mr. James W. Laferriere < babydr at baby-dragons.com> wrote: > > Hello All , Are the roots for .au lost in the haze someplace ? > During my attempts to reach http://www.coker.com.au/**bonnie++/ > I tried a 'dig www.coker.com.au +trace' > > Did some roots change recently ? Tia, JimL > > Which yielded ... > > ; <<>> DiG 9.9.3-P2 <<>> www.coker.com.au +trace > ;; global options: +cmd > . 7424 IN NS i.root-servers.net. > . 7424 IN NS m.root-servers.net. > . 7424 IN NS k.root-servers.net. > . 7424 IN NS a.root-servers.net. > . 7424 IN NS h.root-servers.net. > . 7424 IN NS d.root-servers.net. > . 7424 IN NS c.root-servers.net. > . 7424 IN NS l.root-servers.net. > . 7424 IN NS e.root-servers.net. > . 7424 IN NS g.root-servers.net. > . 7424 IN NS j.root-servers.net. > . 7424 IN NS b.root-servers.net. > . 7424 IN NS f.root-servers.net. > . 517152 IN RRSIG NS 8 0 518400 > 20130907000000 20130830230000 49656 . lWj707jP5hxvgq8BwU5+IVeyuE/**p3wcEmuQRfzuneoFClny1L/xyaT53 > IkhG57jFzRPsXbuvOM6J/**9tZzkbyuN20b5T0QLuxJVQsZT20pzW**SIZ54 MVcVd2HTRtq+* > *Gr0OetDI3THRkgK06IVH0yyKrPqDCQ**I/iHbc+iljg21f lmc= > ;; Received 857 bytes from 50.0.96.199#53(50.0.96.199) in 195 ms > > au. 172800 IN NS z.au. > au. 172800 IN NS y.au. > au. 172800 IN NS x.au. > au. 172800 IN NS w.au. > au. 172800 IN NS v.au. > au. 172800 IN NS u.au. > au. 172800 IN NS s.au. > au. 172800 IN NS r.au. > au. 172800 IN NS b.au. > au. 172800 IN NS a.au. > au. 86400 IN NSEC aw. NS RRSIG NSEC > au. 86400 IN RRSIG NSEC 8 1 86400 > 20130907000000 20130830230000 49656 . LZo++** > i1OBOYRDncdZe8aAuO1TaWgCWVXVc/**aquFb0oT0LBNAbkPljT55 > dQV8jlrsZyZ0QbAm09P29wuq1UBuca**6a1YX72DZrvfDeqX+1oXaAlEPd > ZfFl2eQsao39AZPlRVfVVw18am5VX8**V4K/VmYgBeq1lmV52OVqYz2UVB ygQ= > dig: couldn't get address for 'z.au': no more > > > > -- > +-----------------------------**------------------------------**-------+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network&System Engineer | 3237 Holden Road | Give me Linux | > | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | > +-----------------------------**------------------------------**-------+ > > From fred at cisco.com Mon Sep 2 06:11:22 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Mon, 2 Sep 2013 06:11:22 +0000 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> Message-ID: <8C48B86A895913448548E6D15DA7553B9C755E@xmb-rcd-x09.cisco.com> On Aug 27, 2013, at 12:34 AM, Owen DeLong wrote: > If I send a packet out as a legitimate series of fragments, what is the chance > that they will get dropped somewhere in the middle of the path between the > emitting host and the receiving host? > > To my thinking, the answer to that question is basically "pretty close to 0 and > if that changes in the core, very bad things will happen." I mostly agree. I will argue that the actual path of an IP datagram is end to end, so the question is not the core, but the end to end path. That said, with today's congestion control algorithms, TCP does pretty badly with an other-than-negligible loss rate, so end to end, fragmented messages have a negligible probability of being dropped, so the probability of sending a message that is fragmented and having it arrive at the intended destination is a negligibly small probability smaller than then probability of sending an unfragmented message and having it arrive. The primary argument against that is firewall behavior, in which firewalls are programmed to drop fragments with high probability. If we had a protocol that sat atop IP and did what fragmentation does that we could expect all non-TCP/SCTP protocols to use, I would have a very different viewpoint. But, playing the ball where it lies, the primary change I would recommend would be to support any firewall rule that permitted dropping the first fragment of a fragmented datagram in which the first fragment did NOT include the entire IP header and the entire subsequent header, and expecting a host to keep a fragment of a datagram no more than some stated number of seconds (I might pick "two") with express permission to drop it more rapidly should the need arise. I would *not* support a rule that simple dropped fragments, or a protocol change that disallowed them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robertg at garlic.com Mon Sep 2 14:57:57 2013 From: robertg at garlic.com (Robert Glover) Date: Mon, 02 Sep 2013 07:57:57 -0700 Subject: Any from O1 alive today? Message-ID: <5224A775.902@garlic.com> Dear O1, Your managed modem service appears to not be authenticating users at this time. We have some grumpy dial-up users this morning. Our RADIUS is functioning normally (other services are able to authenticate against it successfully). Your support line (1-888-444-1111) rings fast-busy about 80% of the time I call it this morning (the other 20%, it works fine) Your on-call staff that I paged has yet to respond. Thanks, -Bobby From randy at psg.com Mon Sep 2 16:55:25 2013 From: randy at psg.com (Randy Bush) Date: Tue, 03 Sep 2013 01:55:25 +0900 Subject: nanog bug contact Message-ID: so i wrote to the old action at nanog.org and nanog-action at nanog.org and both bounced. i wrote to a friend at amsl and they said "nanog lists are handled by nanog." so here is the public whine. the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find recent (sept) messages in the archive so i can point to them as a url. randy From jmamodio at gmail.com Mon Sep 2 20:10:06 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 2 Sep 2013 15:10:06 -0500 Subject: Is this working ? Message-ID: Is the list just silent of something is not working ?? Not very common to see almost two days without messages. -J From jmamodio at gmail.com Tue Sep 3 02:19:21 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 2 Sep 2013 21:19:21 -0500 Subject: Akamai Edgekey issues ? In-Reply-To: References: Message-ID: Well it seems that the NANOG list is back alive !!! I sent that message two days ago (also reported via other channels that the list was not working) It is not a persistent problem but intermittent and it seems to affect only TWC customers that chose to use other public NS like Google's 8.8.8.8 and trying to reach sites served by Akamai's CDN. One popular one www.apple.comamong others. Now if you switch back to TWC suggested and controlled NSs 209.18.47.61 and 209.18.47.62, everything seems to "work" It is also a well known (imho) *bad* practice of TWC of tampering with DNS query replies, in theory you should be able to opt-out of it going to some obscure web page (http://www.dnsrsearch.com/prefs.php) which does not seem to always work. I spent almost two hours on the phone with TWC, unfortunately their basic levels of support have no clue at all, I went up to Level 3 but found out that I just escalated horizontally from India to Phillipines to Texas but at the same clue level and not able to reach any engineering minds with a clue. The Level 3 rep didn't know what Akamai is, and at all levels they got lost when I refused to go through the test your modem routine, and was based her assumption that something was not probably working because she was getting too many calls about the same issue. Quite effective monitoring system TWC !! I can't really identify if the problem is that TWC is tampering with akadns query replies and then breaking the CDN or just plain bad routing/peering or the NSA is running out of cycles/memory on the tap I've in my line :-) Cheers Jorge On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio wrote: > > Hi There, > > is anybody having any problems with sites that go through Akamai's CDN ? > > I'm having problems to connect to many served by them, just two examples. > > www.ti.com > www.newark.com > > Cheers > Jorge > > From randy at psg.com Tue Sep 3 02:27:12 2013 From: randy at psg.com (Randy Bush) Date: Tue, 03 Sep 2013 11:27:12 +0900 Subject: nanog bug contact In-Reply-To: References: Message-ID: > so i wrote to the old action at nanog.org and nanog-action at nanog.org and > both bounced. i wrote to a friend at amsl and they said "nanog lists > are handled by nanog." so here is the public whine. > > the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to > have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find > recent (sept) messages in the archive so i can point to them as a url. > > randy oh, and enjoy hitting the link "You can get more information about this list." at the top pf the archive page randy From luc at suryo.com Tue Sep 3 02:33:15 2013 From: luc at suryo.com (Luc I. Suryo) Date: Mon, 2 Sep 2013 19:33:15 -0700 Subject: Is this working ? In-Reply-To: References: Message-ID: <20130903023315.GA36974@wolkje.suryo.priv> ack, -ls Jorge Amodio wrote at Mon, Sep 02, 2013 at 03:10:06PM -0500: > Is the list just silent of something is not working ?? > > Not very common to see almost two days without messages. > > -J --- End of jmamodio at gmail.com's quote --- From jmamodio at gmail.com Tue Sep 3 02:33:42 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 2 Sep 2013 21:33:42 -0500 Subject: Akamai Edgekey issues ? In-Reply-To: References: Message-ID: Here is another bit of data... www.apple.com not reachable from a machine using Google's NS, reachable from an iPad using TWC NS IP addresses returned by each are different ... could be load balancing, or creative (broken) traffic engineering But for moments packets get lost at ae0.pr1.dfw10.tbone.rr.com this also could be TWC routing/peering issues but I don't know how many more levels of CS I have to go to reach somebody with a clue, after testing my modem zillion times ... pete at tango:~$ dig www.apple.com ; <<>> DiG 9.8.1-P1 <<>> www.apple.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46202 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 723 IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 49 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 408 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 9 IN A 184.86.141.15 ;; Query time: 42 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Sep 2 21:06:57 2013 ;; MSG SIZE rcvd: 161 pete at tango:~$ dig @209.18.47.61 www.apple.com ; <<>> DiG 9.8.1-P1 <<>> @209.18.47.61 www.apple.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20041 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 1135 IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 50 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 442 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 5 IN A 23.42.157.15 ;; Query time: 39 msec ;; SERVER: 209.18.47.61#53(209.18.47.61) ;; WHEN: Mon Sep 2 21:07:09 2013 ;; MSG SIZE rcvd: 161 On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio wrote: > > Hi There, > > is anybody having any problems with sites that go through Akamai's CDN ? > > I'm having problems to connect to many served by them, just two examples. > > www.ti.com > www.newark.com > > Cheers > Jorge > > From owen at delong.com Tue Sep 3 02:38:57 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Sep 2013 19:38:57 -0700 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <8C48B86A895913448548E6D15DA7553B9C755E@xmb-rcd-x09.cisco.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <8C48B86A895913448548E6D15DA7553B9C755E@xmb-rcd-x09.cisco.com> Message-ID: <166E0881-B09A-44BC-BD87-EF93F5ACCBF9@delong.com> On Sep 1, 2013, at 23:11 , "Fred Baker (fred)" wrote: > > On Aug 27, 2013, at 12:34 AM, Owen DeLong wrote: > >> If I send a packet out as a legitimate series of fragments, what is the chance >> that they will get dropped somewhere in the middle of the path between the >> emitting host and the receiving host? >> >> To my thinking, the answer to that question is basically "pretty close to 0 and >> if that changes in the core, very bad things will happen." > > I mostly agree. I will argue that the actual path of an IP datagram is end to end, so the question is not the core, but the end to end path. > > That said, with today's congestion control algorithms, TCP does pretty badly with an other-than-negligible loss rate, so end to end, fragmented messages have a negligible probability of being dropped, so the probability of sending a message that is fragmented and having it arrive at the intended destination is a negligibly small probability smaller than then probability of sending an unfragmented message and having it arrive. Yes, the path is end-to-end and things happening near the end-points can be bad for a particular conversation. My point is that if somewhere in the core starts doing bad things to fragments on a regular basis, it will be very bad for massive numbers of users and not just the localized damage one would expect from something closer to the edge. Otherwise, we are saying the same thing. > > The primary argument against that is firewall behavior, in which firewalls are programmed to drop fragments with high probability. > Which fortunately tend to be located at the edge and not in the core. > If we had a protocol that sat atop IP and did what fragmentation does that we could expect all non-TCP/SCTP protocols to use, I would have a very different viewpoint. But, playing the ball where it lies, the primary change I would recommend would be to support any firewall rule that permitted dropping the first fragment of a fragmented datagram in which the first fragment did NOT include the entire IP header and the entire subsequent header, and expecting a host to keep a fragment of a datagram no more than some stated number of seconds (I might pick "two") with express permission to drop it more rapidly should the need arise. I would *not* support a rule that simple dropped fragments, or a protocol change that disallowed them. I think I mostly agree, but I'd need to think it through a bit more than I can at the moment. Owen From shrdlu at deaddrop.org Tue Sep 3 03:12:59 2013 From: shrdlu at deaddrop.org (Shrdlu) Date: Mon, 02 Sep 2013 20:12:59 -0700 Subject: nanog bug contact In-Reply-To: References: Message-ID: <522553BB.3070506@deaddrop.org> On 9/2/2013 7:27 PM, Randy Bush wrote: >> so i wrote to the old action at nanog.org and nanog-action at nanog.org and >> both bounced. i wrote to a friend at amsl and they said "nanog lists >> are handled by nanog." so here is the public whine. >> >> the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to >> have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find >> recent (sept) messages in the archive so i can point to them as a url. >> >> randy > > oh, and enjoy hitting the link "You can get more information about this > list." at the top pf the archive page It may be that they've broken all sorts of things. I received an email earlier, entitled as follows: "mailman.nanog.org mailing list memberships reminder" Ugh. I would never, ever, keep a setting on mailman that sent out those annoying reminder things, where (among other things) it tells you your "password" (such as it is). Then I noticed that something must have been resent, since the password showing was not one I would have chosen. Oh, but wait, there's more. Upon using the link provided: http://mailman.nanog.org/mailman/options/members/shrdlu%40deaddrop.org I encounter the following error: > Bug in Mailman version 2.1.15 > > We're sorry, we hit a bug! > Please inform the webmaster for this site of this problem. Printing > of traceback and other system information has been explicitly > inhibited, but the webmaster can find this information in the Mailman > error logs. Oh, be still my beating heart. I received this for the "members" mailing list, but I suspect that if they broke one thing, they broke multiples. BTW, I checked on the regular link for all nanog lists: http://mailman.nanog.org/mailman/options/nanog Same error. Please fix this. Consider not making updates without tests. Thanks ever so. -- http://www.groklaw.net/article.php?story=20130818120421175 (Time to read True Names again, I suppose.) True Names...and Other Dangers by Vernor Vinge ISBN-10: 0312862075 or ISBN-13: 978-0312862077 From mpetach at netflight.com Tue Sep 3 04:50:50 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 Sep 2013 21:50:50 -0700 Subject: Any from O1 alive today? In-Reply-To: <5224A775.902@garlic.com> References: <5224A775.902@garlic.com> Message-ID: On Mon, Sep 2, 2013 at 7:57 AM, Robert Glover wrote: > Dear O1, > > Your managed modem service appears to not be authenticating users at > this time. We have some grumpy dial-up users this morning. Our RADIUS > is functioning normally (other services are able to authenticate against > it successfully). > > Your support line (1-888-444-1111) rings fast-busy about 80% of the time > I call it this morning (the other 20%, it works fine) > > Your on-call staff that I paged has yet to respond. > > Thanks, > -Bobby > > Dear Bobby, Thank you for contacting the Infernal Referral Service for the Internet. All of our demon...er, agents are busy at the moment telling other users where to go, but if you'd like to stay on the line, your question will be answered in the order it was received. Currently, there is a 314 year, 1 month, 5 day, 9 hour and 26 minute hold time. If you would like to continue waiting, please press '?' on your rotary phone now. Thank you for your continue patronage of the Internet. The LOLcats know you have a choice, and appreciate your Have a nice day, and thank you for flying Internet Express! Matt PS--perhaps you were thinking of someone else as the recipient of your mail? From mpetach at netflight.com Tue Sep 3 06:26:26 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 Sep 2013 23:26:26 -0700 Subject: Akamai Edgekey issues ? In-Reply-To: References: Message-ID: On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio wrote: > Here is another bit of data... www.apple.com not reachable from a machine > using Google's NS, reachable from an iPad using TWC NS > > IP addresses returned by each are different ... could be load balancing, or > creative (broken) traffic engineering > > Far more likely to be simply due to Akamai localizing the IP addresses to be as "close" to the resolving nameserver as possible; so, when using Google DNS, you end up at an Akamai node "close" to the Google DNS server; when using the TWC nameservers, you end up pointing to an Akamai node closer to those TWC nameservers. Not a case of "broken" traffic engineering at all. > But for moments packets get lost at ae0.pr1.dfw10.tbone.rr.com this also > could be TWC routing/peering issues but I don't know how many more levels > of CS I have to go to reach somebody with a clue, after testing my modem > zillion times ... > > Why not just use the TWC nameservers, if thiings work when you use them instead of the Google nameservers? Matt > pete at tango:~$ dig www.apple.com > > ; <<>> DiG 9.8.1-P1 <<>> www.apple.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46202 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.apple.com. IN A > > ;; ANSWER SECTION: > www.apple.com. 723 IN CNAME > www.isg-apple.com.akadns.net > . > www.isg-apple.com.akadns.net. 49 IN CNAME www.apple.com.edgekey.net. > www.apple.com.edgekey.net. 408 IN CNAME e3191.dscc.akamaiedge.net. > e3191.dscc.akamaiedge.net. 9 IN A 184.86.141.15 > > ;; Query time: 42 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Mon Sep 2 21:06:57 2013 > ;; MSG SIZE rcvd: 161 > > pete at tango:~$ dig @209.18.47.61 www.apple.com > > ; <<>> DiG 9.8.1-P1 <<>> @209.18.47.61 www.apple.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20041 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.apple.com. IN A > > ;; ANSWER SECTION: > www.apple.com. 1135 IN CNAME > www.isg-apple.com.akadns.net > . > www.isg-apple.com.akadns.net. 50 IN CNAME www.apple.com.edgekey.net. > www.apple.com.edgekey.net. 442 IN CNAME e3191.dscc.akamaiedge.net. > e3191.dscc.akamaiedge.net. 5 IN A 23.42.157.15 > > ;; Query time: 39 msec > ;; SERVER: 209.18.47.61#53(209.18.47.61) > ;; WHEN: Mon Sep 2 21:07:09 2013 > ;; MSG SIZE rcvd: 161 > > > > On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio wrote: > > > > > Hi There, > > > > is anybody having any problems with sites that go through Akamai's CDN ? > > > > I'm having problems to connect to many served by them, just two examples. > > > > www.ti.com > > www.newark.com > > > > Cheers > > Jorge > > > > > > From contact at nullivex.com Tue Sep 3 09:18:01 2013 From: contact at nullivex.com (Bryan Tong) Date: Tue, 3 Sep 2013 03:18:01 -0600 Subject: TCP Performance In-Reply-To: <3025777$513803ab$2b2678fd$@flhsi.com> References: <3025777$513803ab$2b2678fd$@flhsi.com> Message-ID: Try your iperf over port 80 and see if your hitting any website related filters. At least rule it out. Or try HTTP on a different port. If your iperf test is getting link speed then you can rule most things connection related. I really think some device is QoS'ing packets bound to<>from port 80. On Tue, Aug 27, 2013 at 12:22 PM, Nick Olsen wrote: > I have indeed tried that. And it didn't make any difference. Functionally > limiting each router port to is connected microwave links capacity. And > queuing the overflow. However the queue never really fills as the traffic > rate never goes higher then the allocated bandwidth. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Blake Dunlap" > Sent: Tuesday, August 27, 2013 1:32 PM > To: nick at flhsi.com > Cc: "Tim Warnock" , "nanog at nanog.org" > Subject: Re: TCP Performance > > If you have a router, you can turn on shaping to the bandwidth the link > will support. > > -Blake > > On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen wrote: > I do indeed have stats for "TX Pause Frames" And they do increment. > However, Our router is ignoring them since it doesn't support flow control. > > I guess my next question would be. In the scenario where we insert a switch > between the radio and the router that does support flow control. Are we not > only moving where the overflow is going to occur? Will we not see the > router still burst traffic at line rate toward the switch, Which then > buffer overflows sending to the radio on account of it receiving pause > frames? > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Tim Warnock" > Sent: Tuesday, August 27, 2013 1:08 PM > To: "Blake Dunlap" , "nick at flhsi.com" > Cc: "nanog at nanog.org" > Subject: RE: TCP Performance > > > Regardless, your problem looks like either tail drops or packet loss, > which > > you showed originally. The task is to find out where this is occurring, > and > > which of the two it is. If you want to confirm what is going on, there > are > > some great bandwidth calculators on the internet which will show you > what > > bandwidth you can get with a given ms delay and % packet loss. > > > > As far as flow control, its really outside the scope. If you ever need > flow > > control, there is usually a specific reason like FCoE, and if not, it's > > generally better to just fix the backplane congestion issue if you can, > > than ever worry about using FC. The problem with FC isn't node to node, > its > > when you have node to node to node with additional devices, it isn't > smart > > enough to discriminate, and can crater your network 3 devices over when > it > > would be much better to just lose a few packets. > > > > -Blake > > In my experience - if you're traversing licenced microwave links as > indicated flow control will definitely need to be ON. > > Check the radio modem stats to confirm but - if you're seeing lots of drops > there you're overflowing the buffers on the radio modem. > > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From contact at nullivex.com Tue Sep 3 09:24:09 2013 From: contact at nullivex.com (Bryan Tong) Date: Tue, 3 Sep 2013 03:24:09 -0600 Subject: TCP Performance In-Reply-To: References: <3025777$513803ab$2b2678fd$@flhsi.com> Message-ID: I mean programatically speaking your network equipment generally knows no difference between and HTTP packet and an IPerf packet. (Layer 3 packet forwarding only breaks the first 84 bits off the header, Layer 2 gets 52 bits (with a vlan tag)) So, unless QoS of some kind gets brought into the picture the protocol shouldnt make a difference, however, if something is examining the packets further than that it could also be causing your throughput issues. Also, keep in mind some switches ship with QoS enabled for VoIP etc. Might be something to check into further. On Tue, Sep 3, 2013 at 3:18 AM, Bryan Tong wrote: > Try your iperf over port 80 and see if your hitting any website related > filters. At least rule it out. > > Or try HTTP on a different port. > > If your iperf test is getting link speed then you can rule most things > connection related. I really think some device is QoS'ing packets bound > to<>from port 80. > > > On Tue, Aug 27, 2013 at 12:22 PM, Nick Olsen wrote: > >> I have indeed tried that. And it didn't make any difference. Functionally >> limiting each router port to is connected microwave links capacity. And >> queuing the overflow. However the queue never really fills as the traffic >> rate never goes higher then the allocated bandwidth. >> >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Blake Dunlap" >> Sent: Tuesday, August 27, 2013 1:32 PM >> To: nick at flhsi.com >> Cc: "Tim Warnock" , "nanog at nanog.org" > > >> Subject: Re: TCP Performance >> >> If you have a router, you can turn on shaping to the bandwidth the link >> will support. >> >> -Blake >> >> On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen wrote: >> I do indeed have stats for "TX Pause Frames" And they do increment. >> However, Our router is ignoring them since it doesn't support flow >> control. >> >> I guess my next question would be. In the scenario where we insert a >> switch >> between the radio and the router that does support flow control. Are we >> not >> only moving where the overflow is going to occur? Will we not see the >> router still burst traffic at line rate toward the switch, Which then >> buffer overflows sending to the radio on account of it receiving pause >> frames? >> >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Tim Warnock" >> Sent: Tuesday, August 27, 2013 1:08 PM >> To: "Blake Dunlap" , "nick at flhsi.com" >> Cc: "nanog at nanog.org" >> Subject: RE: TCP Performance >> >> > Regardless, your problem looks like either tail drops or packet loss, >> which >> > you showed originally. The task is to find out where this is occurring, >> and >> > which of the two it is. If you want to confirm what is going on, there >> are >> > some great bandwidth calculators on the internet which will show you >> what >> > bandwidth you can get with a given ms delay and % packet loss. >> > >> > As far as flow control, its really outside the scope. If you ever need >> flow >> > control, there is usually a specific reason like FCoE, and if not, it's >> > generally better to just fix the backplane congestion issue if you can, >> > than ever worry about using FC. The problem with FC isn't node to node, >> its >> > when you have node to node to node with additional devices, it isn't >> smart >> > enough to discriminate, and can crater your network 3 devices over when >> it >> > would be much better to just lose a few packets. >> > >> > -Blake >> >> In my experience - if you're traversing licenced microwave links as >> indicated flow control will definitely need to be ON. >> >> Check the radio modem stats to confirm but - if you're seeing lots of >> drops >> there you're overflowing the buffers on the radio modem. >> >> >> > > > -- > -------------------- > Bryan Tong > Nullivex LLC | eSited LLC > (507) 298-1624 > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From jra at baylink.com Tue Sep 3 13:58:20 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 3 Sep 2013 09:58:20 -0400 (EDT) Subject: Akamai Edgekey issues ? In-Reply-To: Message-ID: <31899578.5997.1378216700314.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio > wrote: > > > Here is another bit of data... www.apple.com not reachable from a > > machine > > using Google's NS, reachable from an iPad using TWC NS > > > > IP addresses returned by each are different ... could be load > > balancing, or > > creative (broken) traffic engineering > Far more likely to be simply due to Akamai > localizing the IP addresses to be as "close" > to the resolving nameserver as possible; > so, when using Google DNS, you end up > at an Akamai node "close" to the Google > DNS server; when using the TWC nameservers, > you end up pointing to an Akamai node closer > to those TWC nameservers. > > Not a case of "broken" traffic engineering at all. Sure it is. It's assuming that the geographic location of a customer resolver server has anything whatever to do with the geographic location of the end node, which it's not in fact a valid proxy for. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From patrick at ianai.net Tue Sep 3 14:37:48 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Sep 2013 10:37:48 -0400 Subject: Akamai Edgekey issues ? In-Reply-To: <31899578.5997.1378216700314.JavaMail.root@benjamin.baylink.com> References: <31899578.5997.1378216700314.JavaMail.root@benjamin.baylink.com> Message-ID: <75C9D35B-C9FF-4458-ADD6-B2E8929E498F@ianai.net> On Sep 03, 2013, at 09:58 , Jay Ashworth wrote: >> From: "Matthew Petach" >> On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio wrote: >> >>> Here is another bit of data... www.apple.com not reachable from a >>> machine >>> using Google's NS, reachable from an iPad using TWC NS >>> >>> IP addresses returned by each are different ... could be load >>> balancing, or >>> creative (broken) traffic engineering > >> Far more likely to be simply due to Akamai >> localizing the IP addresses to be as "close" >> to the resolving nameserver as possible; >> so, when using Google DNS, you end up >> at an Akamai node "close" to the Google >> DNS server; when using the TWC nameservers, >> you end up pointing to an Akamai node closer >> to those TWC nameservers. >> >> Not a case of "broken" traffic engineering at all. > > Sure it is. > > It's assuming that the geographic location of a customer resolver server > has anything whatever to do with the geographic location of the end node, > which it's not in fact a valid proxy for. It isn't? How wrong is this assumption? Be specific. How far off is it, for how many users? Perhaps look at the other side. Assumptions must be made. What assumptions would be better in the real world? What percentage of users are "closer" to anycast nodes? What are the real-world performance differences using this method vs. other methods? Saying "not in fact a valid proxy" without hard data is not useful. What data do you have to prove your thesis? Akamai seems to perform well for the vast majority of users. Or so I believe, but I fully admit I am biased. :) That said, always happy to be educated. If you have data, let us know. -- TTFN, patrick -------------- 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: From jra at baylink.com Tue Sep 3 15:07:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 3 Sep 2013 11:07:38 -0400 (EDT) Subject: Akamai Edgekey issues ? In-Reply-To: <75C9D35B-C9FF-4458-ADD6-B2E8929E498F@ianai.net> Message-ID: <12425897.6003.1378220858229.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > >> Not a case of "broken" traffic engineering at all. > > > > Sure it is. > > > > It's assuming that the geographic location of a customer resolver > > server > > has anything whatever to do with the geographic location of the end > > node, > > which it's not in fact a valid proxy for. > > It isn't? How wrong is this assumption? Be specific. How far off is > it, for how many users? Well, the vast majority of wireless users, for one: Sprint can't decide whether I'm in Miami, Orlando, or Lenexa, Kansas on any given day. More properly: people whose websites geolocate and whom I access over Sprint 3g/Wimax/LTE. They're probably geolocating by the actual assigned IP address, but it's roughly the same thing. > Perhaps look at the other side. Assumptions must be made. What > assumptions would be better in the real world? What percentage of > users are "closer" to anycast nodes? What are the real-world > performance differences using this method vs. other methods? I didn't say there was a *good* answer to this, and in fact, I don't think there is. > Saying "not in fact a valid proxy" without hard data is not useful. > What data do you have to prove your thesis? > > Akamai seems to perform well for the vast majority of users. Or so I > believe, but I fully admit I am biased. :) Heh. :-) > That said, always happy to be educated. If you have data, let us know. Well played, Patrick. No, it's anecdotal. But the percentage of wireless users who are of necessity often nowhere near their DNS resolvers certainly contributes to the percentages. There are people who are manually stuck on the wrong network's servers, or those who are configured to 4.4.4.4/8.8.8.8/4.2.2.1 by IT people (or themselves) or to OpenDNS or the like, but I'd be surprised if those were more than 5% overall. It's mostly wireless. And that's a lot. Is it relevant to Akamai? Possibly not. For Akamai, the proxy may be Good Enough. Just so we remember that not everyone is Akamai. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From scott at scotthulbert.com Tue Sep 3 06:41:07 2013 From: scott at scotthulbert.com (Scott Hulbert) Date: Mon, 2 Sep 2013 23:41:07 -0700 Subject: Akamai Edgekey issues ? In-Reply-To: References: Message-ID: Matthew Petach wrote: > Why not just use the TWC nameservers, > if thiings work when you use them instead > of the Google nameservers? > One reason would be that TWC used to hijack failed DNS requests and show advertisements ( http://netcodger.wordpress.com/2010/09/14/roadrunner-returns-to-dns-hijack-tactics/ ). Also, Google DNS and OpenDNS helped manually clean up bad records after the NYTimes had their nameservers changed at the TLD registry ( http://blog.cloudflare.com/details-behind-todays-internet-hacks). ?Scott From jjones at danrj.com Tue Sep 3 15:58:19 2013 From: jjones at danrj.com (Jerry Jones) Date: Tue, 3 Sep 2013 10:58:19 -0500 Subject: 10G Router In-Reply-To: References: Message-ID: If you require full redundancy, checkout the MX104. It also has a slightly better RE. On Aug 31, 2013, at 6:44 AM, sten rulz wrote: Hello, I am currently looking into a 10G router that will support the below requirements and hopefully not be too costly. Do you know of any models to stay away due to issues or that you would recommend? - 4x+ 10GBE ports - BGPv4/v6 - Small number of RU preferred - Support for 2-4 full routing tables - 2 10GBE ports down to switches - 2 10GBE for up-streams but would prefer more to support IXs. I have been looking into a few options including; Brocade CER 2024C-4X, Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. Some quick notes: - 4x 10GBE ports is a bit low for the Brocade CER - Not sure how the CER will handle a few routing tables and 10G+ traffic - The MLX and MX80 is very high costs from what I have seen - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC - Decent number of real use case reviews for the MX80 - Possibly use cumulus networks if there are any systems that meet the requirements Thanks Steven From bryan at serverstack.com Tue Sep 3 16:00:40 2013 From: bryan at serverstack.com (Bryan Socha) Date: Tue, 3 Sep 2013 12:00:40 -0400 Subject: 10G Router In-Reply-To: References: Message-ID: I recently did a search for similar. The full routing table is where you can factor out a lot of devices and specific line cards for others because they can't handle it. That's where you want to make sure your clear with the vendors as you talk to them. I ultimately went with different mx models myself because I couldn't find anyone using something else. *Bryan Socha* Network Engineer 646.450.0472 | *bryan at serverstack.com* *ServerStack* | Scale Big On Sat, Aug 31, 2013 at 7:44 AM, sten rulz wrote: > Hello, > > I am currently looking into a 10G router that will support the below > requirements and hopefully not be too costly. Do you know of any models to > stay away due to issues or that you would recommend? > - 4x+ 10GBE ports > - BGPv4/v6 > - Small number of RU preferred > - Support for 2-4 full routing tables > - 2 10GBE ports down to switches > - 2 10GBE for up-streams but would prefer more to support IXs. > > I have been looking into a few options including; Brocade CER 2024C-4X, > Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. > Some quick notes: > - 4x 10GBE ports is a bit low for the Brocade CER > - Not sure how the CER will handle a few routing tables and 10G+ traffic > - The MLX and MX80 is very high costs from what I have seen > - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC > - Decent number of real use case reviews for the MX80 > - Possibly use cumulus networks if there are any systems that meet the > requirements > > Thanks > Steven > From james at towardex.com Tue Sep 3 16:59:41 2013 From: james at towardex.com (james at towardex.com) Date: Tue, 3 Sep 2013 12:59:41 -0400 Subject: 10G Router In-Reply-To: References: Message-ID: <06e601cea8c6$fbbc5da0$f33518e0$@towardex.com> MX80 is a good box. Go for MX104 if you want 2xRE redundancy and ability to oversubscribe MIC slots with 2x10G cards. Do note however: MX80-48T (cheaper variant with 48x tri-rate copper) uses the old MS-DPC and does not scale very well when things like Netflow/IPFix accounting. You should stick to MX80-T variant or MX5-40 mid-range as they are newer Trio architectures and can do more stuff in hardware. james From patrick at ianai.net Tue Sep 3 17:03:12 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Sep 2013 13:03:12 -0400 Subject: Akamai Edgekey issues ? In-Reply-To: References: Message-ID: <05EE2123-A9A7-438A-BC1C-EA02DC25A7E6@ianai.net> On Sep 03, 2013, at 02:41 , Scott Hulbert wrote: > Matthew Petach wrote: >> Why not just use the TWC nameservers, >> if thiings work when you use them instead >> of the Google nameservers? >> > > One reason would be that TWC used to hijack failed DNS requests and show > advertisements ( > http://netcodger.wordpress.com/2010/09/14/roadrunner-returns-to-dns-hijack-tactics/ > ). Without condoning or decrying this practice, I believe TWC allows you to opt-out of that. (Whether they should require you to "opt-out", or do it at all, is intentionally not discussed.) > Also, Google DNS and OpenDNS helped manually clean up bad records after the > NYTimes had their nameservers changed at the TLD registry ( > http://blog.cloudflare.com/details-behind-todays-internet-hacks). What makes you think TWC did not do the same? And it was a lot more than the New York Times that had issues, and there was a lot more than a single instance of this. To be clear, Google is Johnny On The Spot when these things happen, and kudos to them for it. But so are lots of other providers (e.g. OpenDNS, who has been doing this a lot longer than Google), they just might not have "teh GOOG" name to get them in the press & blogs. -- TTFN, patrick -------------- 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: From saku at ytti.fi Tue Sep 3 18:24:56 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 3 Sep 2013 21:24:56 +0300 Subject: 10G Router In-Reply-To: <06e601cea8c6$fbbc5da0$f33518e0$@towardex.com> References: <06e601cea8c6$fbbc5da0$f33518e0$@towardex.com> Message-ID: <20130903182456.GA32397@pob.ytti.fi> On (2013-09-03 12:59 -0400), james at towardex.com wrote: > Do note however: MX80-48T (cheaper variant with 48x tri-rate copper) uses > the old MS-DPC and does not scale very well when things like Netflow/IPFix No it does not, it uses trio just no QX chip for per-vlan QoS. -- ++ytti From jpatallah at gmail.com Tue Sep 3 18:46:21 2013 From: jpatallah at gmail.com (John-Pierre Atallah) Date: Tue, 3 Sep 2013 11:46:21 -0700 Subject: Having dropped packets when reaching Cogent Network Message-ID: Hello, If anyone is from Cogent, can you email me off list. I'm having a problem reaching a website when going through Cogent hops. Looking for any help, thank you! -John-Pierre From vwittkop at gmail.com Tue Sep 3 19:42:47 2013 From: vwittkop at gmail.com (Valerie Wittkop) Date: Tue, 03 Sep 2013 15:42:47 -0400 Subject: Update on Mailman Outage from the NANOG Communications Committee Message-ID: <52263BB7.3000209@gmail.com> Hello All, Just wanted to send you all a quick note regarding the mailman outage NANOG experienced this weekend... A couple of changes made in August on the server resulted in an issue when the new month arrived. We have found the issue, fixed, and now have everything up and running properly again. Lists are working as they should and the web user interface is available should you wish to make any changes to your subscription. We apologize for the interruption, and should you experience any other problems/issues, please let us know by sending a message to admins at nanog.org. Cheers, Valerie Wittkop On behalf of the NANOG Communications Committee From johnl at iecc.com Tue Sep 3 21:28:13 2013 From: johnl at iecc.com (John Levine) Date: 3 Sep 2013 21:28:13 -0000 Subject: Is the FBI's DNSSEC broken? In-Reply-To: <20130830230249.4546C390797D@drugs.dv.isc.org> Message-ID: <20130903212813.4637.qmail@joyce.lan> >> On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: >> > I don't claim to be a big DNSSEC expert, but this looks just plain >> > wrong to me, and unbound agrees, turning it into a SERVFAIL. I heard back, seems like I found someone at the FBI who was able to explain the problem to Neustar (DNS software provider) who say they will fix it. R's, John From m.hallgren at free.fr Tue Sep 3 21:54:44 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 03 Sep 2013 23:54:44 +0200 Subject: Is the FBI's DNSSEC broken? In-Reply-To: <20130903212813.4637.qmail@joyce.lan> References: <20130903212813.4637.qmail@joyce.lan> Message-ID: <52265AA4.6000404@free.fr> Le 03/09/2013 23:28, John Levine a ?crit : >>> On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: >>>> I don't claim to be a big DNSSEC expert, but this looks just plain >>>> wrong to me, and unbound agrees, turning it into a SERVFAIL. > I heard back, seems like I found someone at the FBI who was able to > explain the problem to Neustar (DNS software provider) who say they > will fix it. So, what was the problem then? Cheers, mh > > R's, > John > From deepak at ai.net Tue Sep 3 21:58:25 2013 From: deepak at ai.net (Deepak Jain) Date: Tue, 3 Sep 2013 17:58:25 -0400 Subject: Mail best practices? Message-ID: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> Without going to a dedicated list for something like this, I'm looking for a common sense approach. Sep 3 17:55:20 XXX sendmail[155]: r83Lse37000155: rejecting commands from outmail016.ash2.facebook.com [66.220.155.150] due to pre-greeting traffic Sep 3 17:55:22 XXX sendmail[156]: r83Lsg6N000156: rejecting commands from outmail015.ash2.facebook.com [66.220.155.149] due to pre-greeting traffic Isn't this sort of thing supposed to be frowned upon still? I am not trying to name & shame here, but I figured this is a pretty big/respectable email sender. Thoughts for balancing sensible network spam management with sensible best practices that affect lots of users? Thanks in advance, Deepak From marka at isc.org Tue Sep 3 22:02:20 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 04 Sep 2013 08:02:20 +1000 Subject: Is the FBI's DNSSEC broken? In-Reply-To: Your message of "Tue, 03 Sep 2013 23:54:44 +0200." <52265AA4.6000404@free.fr> References: <20130903212813.4637.qmail@joyce.lan> <52265AA4.6000404@free.fr> Message-ID: <20130903220220.14556392DB10@drugs.dv.isc.org> In message <52265AA4.6000404 at free.fr>, Michael Hallgren writes: > Le 03/09/2013 23:28, John Levine a ??crit : > >>> On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: > >>>> I don't claim to be a big DNSSEC expert, but this looks just plain > >>>> wrong to me, and unbound agrees, turning it into a SERVFAIL. > > I heard back, seems like I found someone at the FBI who was able to > > explain the problem to Neustar (DNS software provider) who say they > > will fix it. > > So, what was the problem then? The main problem is that no one is reading / following up email sent to the advertised contact address for fbi.gov (dns-admin at fbi.gov). This ultimately is a management problem within the FBI. > Cheers, > > mh > > > > R's, > > John > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ted at io-tx.com Tue Sep 3 22:04:17 2013 From: ted at io-tx.com (Ted Hatfield) Date: Tue, 3 Sep 2013 17:04:17 -0500 (CDT) Subject: Mail best practices? In-Reply-To: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> References: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> Message-ID: What's your greet pause set to? Ted On Tue, 3 Sep 2013, Deepak Jain wrote: > > > > > Without going to a dedicated list for something like this, I'm looking for a > common sense approach. > > > > Sep 3 17:55:20 XXX sendmail[155]: r83Lse37000155: rejecting commands from > outmail016.ash2.facebook.com [66.220.155.150] due to pre-greeting traffic > > > > Sep 3 17:55:22 XXX sendmail[156]: r83Lsg6N000156: rejecting commands from > outmail015.ash2.facebook.com [66.220.155.149] due to pre-greeting traffic > > > > Isn't this sort of thing supposed to be frowned upon still? I am not trying > to name & shame here, but I figured this is a pretty big/respectable email > sender. > > > > Thoughts for balancing sensible network spam management with sensible best > practices that affect lots of users? > > > > Thanks in advance, > > > > Deepak > > From jra at baylink.com Wed Sep 4 03:09:59 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 3 Sep 2013 23:09:59 -0400 (EDT) Subject: Yahoo is now recycling handles Message-ID: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Whackiness, predictably, ensues: https://medium.com/editors-picks/46b47d95b957 You can do the math how this might affect you, your services, and your users, if you have those. Will people *ever* start listening when we tell them how Bad an Idea something is? The RISKS are endless... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From alter3d at alter3d.ca Wed Sep 4 03:47:40 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 03 Sep 2013 23:47:40 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: <5226AD5C.8030407@alter3d.ca> The issue was studied thoroughly by a committee of MBAs who, after extensive thought (read: 19 bottles of scotch), determined that there was money to be made. whatcouldpossiblygowrong? - Pete On 9/3/2013 11:09 PM, Jay Ashworth wrote: > Whackiness, predictably, ensues: > > https://medium.com/editors-picks/46b47d95b957 > > You can do the math how this might affect you, your services, and your users, > if you have those. > > Will people *ever* start listening when we tell them how Bad an Idea > something is? The RISKS are endless... > > Cheers, > -- jra -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4246 bytes Desc: S/MIME Cryptographic Signature URL: From scott at doc.net.au Wed Sep 4 03:57:16 2013 From: scott at doc.net.au (Scott Howard) Date: Tue, 3 Sep 2013 20:57:16 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: To their (partial) credit they are also supporting a new email header : Require-Recipient-Valid-Since: via draft-ietf-appsawg-rrvs-header-field The idea of this header is that it will allow a sender to control that a user will only receive an email if that email address was valid before a specific date, thus at least stopping someone from using a recycled account to carry out a password reset on another service. Facebook at least is already sending this header on all emails. Overall this is nothing new - Hotmail has been doing the same thing for years. Scott On Tue, Sep 3, 2013 at 8:09 PM, Jay Ashworth wrote: > Whackiness, predictably, ensues: > > https://medium.com/editors-picks/46b47d95b957 > > You can do the math how this might affect you, your services, and your > users, > if you have those. > > Will people *ever* start listening when we tell them how Bad an Idea > something is? The RISKS are endless... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From ml at kenweb.org Wed Sep 4 04:12:14 2013 From: ml at kenweb.org (ML) Date: Wed, 04 Sep 2013 00:12:14 -0400 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: <5226B31E.4080903@kenweb.org> On 9/3/2013 11:57 PM, Scott Howard wrote: > Overall this is nothing new - Hotmail has been doing the same thing for > years. > > Scott > When I used to use Hotmail - Your account was dropped after 30-60 days of non-use. Whereas Yahoo kept accounts active forever until recently. Granted it's been >15 years since I've used a Hotmail account regularly. Microsoft *may* change their policies more often than that. From mis at seiden.com Wed Sep 4 04:48:24 2013 From: mis at seiden.com (Mark Seiden) Date: Tue, 3 Sep 2013 21:48:24 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <5226B31E.4080903@kenweb.org> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226B31E.4080903@kenweb.org> Message-ID: <2E7FF048-65AA-451C-A8E3-9DB911C5DC30@seiden.com> On Sep 3, 2013, at 9:12 PM, ML wrote: > On 9/3/2013 11:57 PM, Scott Howard wrote: >> Overall this is nothing new - Hotmail has been doing the same thing for >> years. >> >> Scott >> > > > When I used to use Hotmail - Your account was dropped after 30-60 days > of non-use. > > Whereas Yahoo kept accounts active forever until recently. > as an ex yahoo security guy for many years, my recollection is this isn't the case. starting 8-10 years ago accounts which went dormant for extended times had actions taken on them. e.g. free accounts not logged into for a while (order of a year) had their old email archived, or maybe even erased, i am not recalling exactly which... accounts already in that inactive state could at any point have their names reclaimed, but the process of doing that was (as i recall) a manual and infrequent one. i remember it happening two or three times over about 8 years, so that would make it a big batch about every year or two. (several kinds of accounts, such as paid accounts, accounts managed for partners such as sbc and rogers, and those deactivated for abuse were kept around forever in the deactivated state so they couldn't be ever reregistered and reused for similar abuse.) (yahoo internally understands the difference between the old account and the newly registered eponymous account because account registration date (at the granularity of a week) is logically part of the yahoo id whenever ids are used, exported, compared with other ids, looked up or stored in databases, etc..) (it was a fairly common bug we would find in our security reviews for programmers to ignore the regweek, for example, when exporting lists of ids for some purpose). btw: i don't think it's so unreasonable to treat a free account that hasn't been logged into for 2-3 years as abandoned. i agree it can have unfortunate side effects (particularly domain name takeover of long-registered names). in its early days, one of the reasons people switched to gmail was that they could get a better name there than e.g. blah32975 at yahoo.com. (this was slightly exacerbated because for a number of years if someone had mis at yahoo.com, the cohort address in other ccTlds such as blah32975 at yahoo.co.uk was also not available to be registered.) approximately 5 years ago, yahoo split out some populous countries into their own name spaces, which made a lot more names available to be registered. there was a land rush, in fact, to register "good names", and some people were not-so-amusingly trying to sell them. > > Granted it's been >15 years since I've used a Hotmail account > regularly. Microsoft *may* change their policies more often than that. > > From randy at psg.com Wed Sep 4 06:45:55 2013 From: randy at psg.com (Randy Bush) Date: Wed, 04 Sep 2013 15:45:55 +0900 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: > To their (partial) credit they are also supporting a new email header : > Require-Recipient-Valid-Since: with no X- before it? randy From shopik at inblock.ru Wed Sep 4 08:00:17 2013 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 04 Sep 2013 12:00:17 +0400 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: <5226E891.7040106@inblock.ru> On 04/09/13 10:45, Randy Bush wrote: > with no X- before it? http://tools.ietf.org/html/rfc6648 From mohta at necom830.hpcl.titech.ac.jp Wed Sep 4 08:50:20 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 04 Sep 2013 17:50:20 +0900 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> Message-ID: <5226F44C.7010108@necom830.hpcl.titech.ac.jp> Scott Howard wrote: > The idea of this header is that it will allow a sender to control that a Sender has no control and asks a receiver perform some control, which may be ignored by the receiver. > user will only receive an email if that email address was valid before a > specific date, thus at least stopping someone from using a recycled account > to carry out a password reset on another service. It does not work as protection against transferred domain. > Facebook at least is already sending this header on all emails. Someone might want people keep using mail services monitored by USG. Masataka Ohta From johnl at iecc.com Wed Sep 4 08:55:32 2013 From: johnl at iecc.com (John Levine) Date: 4 Sep 2013 08:55:32 -0000 Subject: Yahoo is now recycling handles In-Reply-To: Message-ID: <20130904085532.9840.qmail@joyce.lan> In article you write: >> To their (partial) credit they are also supporting a new email header : >> Require-Recipient-Valid-Since: > >with no X- before it? Well, yes: draft-wmills-rrvs-header-field-01.txt R's, John From johnl at iecc.com Wed Sep 4 09:04:41 2013 From: johnl at iecc.com (John Levine) Date: 4 Sep 2013 09:04:41 -0000 Subject: Is the FBI's DNSSEC broken? In-Reply-To: <52265AA4.6000404@free.fr> Message-ID: <20130904090441.9927.qmail@joyce.lan> In article <52265AA4.6000404 at free.fr> you write: >Le 03/09/2013 23:28, John Levine a ?crit : >>>> On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: >>>>> I don't claim to be a big DNSSEC expert, but this looks just plain >>>>> wrong to me, and unbound agrees, turning it into a SERVFAIL. >> I heard back, seems like I found someone at the FBI who was able to >> explain the problem to Neustar (DNS software provider) who say they >> will fix it. > >So, what was the problem then? What we said it was, missing signatures on some NODATA results. From jared at puck.nether.net Wed Sep 4 10:25:50 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Sep 2013 06:25:50 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <5226B31E.4080903@kenweb.org> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226B31E.4080903@kenweb.org> Message-ID: <57BF3E52-B7D2-4DD2-B90B-F6EBD3FD8FC1@puck.nether.net> On Sep 4, 2013, at 12:12 AM, ML wrote: > On 9/3/2013 11:57 PM, Scott Howard wrote: >> Overall this is nothing new - Hotmail has been doing the same thing for >> years. >> >> Scott > > > When I used to use Hotmail - Your account was dropped after 30-60 days > of non-use. > > Whereas Yahoo kept accounts active forever until recently. > > > Granted it's been >15 years since I've used a Hotmail account > regularly. Microsoft *may* change their policies more often than that. Back when I ran nether.net as full scale public access, I would reap unused accounts after some period of time..l don't recall anymore as that was almost 15+ years ago now. But one month seemed like the right number. I had almost 100k accounts at most points... Was fairly crazy. A least the Internet archive captured some of the cool stuff the users did back then. - Jared From bicknell at ufp.org Wed Sep 4 13:36:37 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 4 Sep 2013 08:36:37 -0500 Subject: Yahoo is now recycling handles In-Reply-To: <5226AD5C.8030407@alter3d.ca> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> Message-ID: On Sep 3, 2013, at 10:47 PM, Peter Kristolaitis wrote: > The issue was studied thoroughly by a committee of MBAs who, after extensive thought (read: 19 bottles of scotch), determined that there was money to be made. > > whatcouldpossiblygowrong? Apparently it was implemented by a group of low-bid programmers in a far off land. I have, err, had, a Yahoo! account I used for two things, getting e-mail from Yahoo! groups and accessing Flickr. I was on Flickr not a two or three months ago to fix a picture someone noticed was in the wrong album. When I saw this I thought I should log in again to reset my one year ticker. Off to www.yahoo.com and click sign in. Enter userid, enter password. Drops me to a CAPTCHA screen, that's odd, never seen that before, but ok. Enter CAPTCHA and it redirects me to "https://edit.yahoo.com/forgot", which when reached from said CAPTCHA screen renders as a 100% blank page. That's some fine web coding. I went to the flickr site, tried to log in. At least there it tells me my userid is in the process of being recycled. No option to recover. Try creating a new account with the same userid, sorry, it's in use. So as far as I can tell: - The must be inactive for one year is BS, and/or logging into Flickr didn't count in my case. - No notifications are sent, so if you're a person who is there for things like Yahoo groups and forwards your e-mail elsewhere you may be using the service in a way that generates no logs. - There is no way to get an account back that is in the recycling phase, which is frankly stupid. As a result Yahoo! has lost a Flickr and Groups member, and I'm not sure I see any reason to sign up again at this point. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blair.trosper at gmail.com Wed Sep 4 14:19:49 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 4 Sep 2013 09:19:49 -0500 Subject: Facebook over IPv6 Message-ID: Could someone @ Facebook kindly drop me a line? Your site appears to be riddled with problems on the IPv6 side (whereas it's demonstrably fine on v4). Much of the static JavaScript content being served off your IPv6 CDN is corrupt, missing, or perhaps just outdated. It's preventing the page from doing anything but rendering...it has no interactivity. It's been this way about 24 hours now. Blair From jhellenthal at dataix.net Wed Sep 4 14:56:31 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 4 Sep 2013 10:56:31 -0400 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> Message-ID: Alec . . . I'll take "I don"t use Yahoo because of Yahoo 's" for a 100 please. -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN > On Sep 4, 2013, at 9:36, Leo Bicknell wrote: > > >> On Sep 3, 2013, at 10:47 PM, Peter Kristolaitis wrote: >> >> The issue was studied thoroughly by a committee of MBAs who, after extensive thought (read: 19 bottles of scotch), determined that there was money to be made. >> >> whatcouldpossiblygowrong? > > Apparently it was implemented by a group of low-bid programmers in a far off land. > > I have, err, had, a Yahoo! account I used for two things, getting e-mail from Yahoo! groups and accessing Flickr. I was on Flickr not a two or three months ago to fix a picture someone noticed was in the wrong album. > > When I saw this I thought I should log in again to reset my one year ticker. Off to www.yahoo.com and click sign in. > > Enter userid, enter password. > > Drops me to a CAPTCHA screen, that's odd, never seen that before, but ok. > > Enter CAPTCHA and it redirects me to "https://edit.yahoo.com/forgot", which when reached from said CAPTCHA screen renders as a 100% blank page. > > That's some fine web coding. > > I went to the flickr site, tried to log in. At least there it tells me my userid is in the process of being recycled. No option to recover. > > Try creating a new account with the same userid, sorry, it's in use. > > So as far as I can tell: > - The must be inactive for one year is BS, and/or logging into Flickr didn't count in my case. > - No notifications are sent, so if you're a person who is there for things like Yahoo groups and forwards your e-mail elsewhere you may be using the service in a way that generates no logs. > - There is no way to get an account back that is in the recycling phase, which is frankly stupid. > > As a result Yahoo! has lost a Flickr and Groups member, and I'm not sure I see any reason to sign up again at this point. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From andree+nanog at toonk.nl Wed Sep 4 17:56:04 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 04 Sep 2013 10:56:04 -0700 Subject: Akamai Edgekey issues ? In-Reply-To: <12425897.6003.1378220858229.JavaMail.root@benjamin.baylink.com> References: <12425897.6003.1378220858229.JavaMail.root@benjamin.baylink.com> Message-ID: <52277434.3010206@toonk.nl> .-- My secret spy satellite informs me that at 2013-09-03 8:07 AM Jay Ashworth wrote: > There are people who are manually stuck on the wrong network's servers, or > those who are configured to 4.4.4.4/8.8.8.8/4.2.2.1 by IT people (or themselves) > or to OpenDNS or the like, but I'd be surprised if those were more than 5% > overall. This can be improved by implementing support for the edns-client-subnet feature ( http://www.afasterinternet.com/ ). Both OpenDNS and Google support this, as well as numerous CDN's. Would be great to have Akamai supporting this as well :) Cheers, Andree From chris at nmedia.net Wed Sep 4 18:06:02 2013 From: chris at nmedia.net (Chris Cappuccio) Date: Wed, 4 Sep 2013 11:06:02 -0700 Subject: 10G Router In-Reply-To: References: Message-ID: <20130904180602.GD6912@ref.nmedia.net> sten rulz [stenrulz at gmail.com] wrote: > Hello, > > I am currently looking into a 10G router that will support the below > requirements and hopefully not be too costly. Do you know of any models to > stay away due to issues or that you would recommend? > - 4x+ 10GBE ports > - BGPv4/v6 > - Small number of RU preferred > - Support for 2-4 full routing tables > - 2 10GBE ports down to switches > - 2 10GBE for up-streams but would prefer more to support IXs. > If you have the rack space, just buy an old Juniper T320 and save your money for beer. From mehmet at akcin.net Wed Sep 4 18:27:23 2013 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 4 Sep 2013 11:27:23 -0700 Subject: 10G Router In-Reply-To: References: Message-ID: On Aug 31, 2013, at 4:44 AM, sten rulz wrote: > Hello, > > I am currently looking into a 10G router that will support the below > requirements and hopefully not be too costly. Do you know of any models to > stay away due to issues or that you would recommend? > - 4x+ 10GBE ports > - BGPv4/v6 > - Small number of RU preferred > - Support for 2-4 full routing tables > - 2 10GBE ports down to switches > - 2 10GBE for up-streams but would prefer more to support IXs. > > I have been looking into a few options including; Brocade CER 2024C-4X, > Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. > Some quick notes: > - 4x 10GBE ports is a bit low for the Brocade CER > - Not sure how the CER will handle a few routing tables and 10G+ traffic > - The MLX and MX80 is very high costs from what I have seen > - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC > - Decent number of real use case reviews for the MX80 > - Possibly use cumulus networks if there are any systems that meet the > requirements Juniper MX hands down. http://www.juniper.net/us/en/products-services/routing/mx-series Visit the link and see different versions. I have MX240s fully populated ones(Dual RE/DPC-R etc). They rock. > > Thanks > Steven From netfortius at gmail.com Wed Sep 4 19:01:01 2013 From: netfortius at gmail.com (Stefan) Date: Wed, 4 Sep 2013 14:01:01 -0500 Subject: [Q] Any good resource of info ref LECs, in different US areas? Message-ID: Trying to build diversity in some very odd places, about which the big names tell me exclusively about other bug names, but cannot easily verify. Thank you, ***Stefan From jared at puck.nether.net Wed Sep 4 19:27:23 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Sep 2013 15:27:23 -0400 Subject: [Q] Any good resource of info ref LECs, in different US areas? In-Reply-To: References: Message-ID: <488D9AD6-D3EE-4988-9FF1-1CF696BB91E4@puck.nether.net> On Sep 4, 2013, at 3:01 PM, Stefan wrote: > Trying to build diversity in some very odd places, about which the big > names tell me exclusively about other bug names, but cannot easily verify. I think if you are specific about what markets (or addresses) it would be helpful. eg: Here in Michigan there are a lot of small fixed wireless providers, local fiber in addition to the big name folks. If you talk about the market, city, etc.. it might be helpful. I could say try "smaller" folks like US Signal. There's also places like this: http://www.indatelgroup.org/ I've almost thought there should be a nanog-type list for posting these types of inquiries to help folks dig up access... - Jared From eugen at leitl.org Wed Sep 4 20:12:40 2013 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 4 Sep 2013 22:12:40 +0200 Subject: NSA Laughs at PCs, Prefers Hacking Routers and Switches Message-ID: <20130904201240.GE29404@leitl.org> http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/ NSA Laughs at PCs, Prefers Hacking Routers and Switches BY KIM ZETTER09.04.136:30 AM Photo: Santiago Cabezas/Flickr The NSA runs a massive, full-time hacking operation targeting foreign systems, the latest leaks from Edward Snowden show. But unlike conventional cybercriminals, the agency is less interested in hacking PCs and Macs. Instead, America?s spooks have their eyes on the internet routers and switches that form the basic infrastructure of the net, and are largely overlooked as security vulnerabilities. Under a $652-million program codenamed ?Genie,? U.S. intel agencies have hacked into foreign computers and networks to monitor communications crossing them and to establish control over them, according to a secret black budget document leaked to the Washington Post. U.S. intelligence agencies conducted 231 offensive cyber operations in 2011 to penetrate the computer networks of targets abroad. This included not only installing covert ?implants? in foreign desktop computers but also on routers and firewalls ? tens of thousands of machines every year in all. According to the Post, the government planned to expand the program to cover millions of additional foreign machines in the future and preferred hacking routers to individual PCs because it gave agencies access to data from entire networks of computers instead of just individual machines. Most of the hacks targeted the systems and communications of top adversaries like China, Russia, Iran and North Korea and included activities around nuclear proliferation. The NSA?s focus on routers highlights an often-overlooked attack vector with huge advantages for the intruder, says Marc Maiffret, chief technology officer at security firm Beyond Trust. Hacking routers is an ideal way for an intelligence or military agency to maintain a persistent hold on network traffic because the systems aren?t updated with new software very often or patched in the way that Windows and Linux systems are. ?No one updates their routers,? he says. ?If you think people are bad about patching Windows and Linux (which they are) then they are ? horrible about updating their networking gear because it is too critical, and usually they don?t have redundancy to be able to do it properly.? He also notes that routers don?t have security software that can help detect a breach. ?The challenge [with desktop systems] is that while antivirus don?t work well on your desktop, they at least do something [to detect attacks],? he says. ?But you don?t even have an integrity check for the most part on routers and other such devices like IP cameras.? Hijacking routers and switches could allow the NSA to do more than just eavesdrop on all the communications crossing that equipment. It would also let them bring down networks or prevent certain communication, such as military orders, from getting through, though the Post story doesn?t report any such activities. With control of routers, the NSA could re-route traffic to a different location, or intelligence agencies could alter it for disinformation campaigns, such as planting information that would have a detrimental political effect or altering orders to re-route troops or supplies in a military operation. According to the budget document, the CIA?s Tailored Access Programs and NSA?s software engineers possess ?templates? for breaking into common brands and models of routers, switches and firewalls. The article doesn?t say it, but this would likely involve pre-written scripts or backdoor tools and root kits for attacking known but unpatched vulnerabilities in these systems, as well as for attacking zero-day vulnerabilities that are yet unknown to the vendor and customers. ?[Router software is] just an operating system and can be hacked just as Windows or Linux would be hacked,? Maiffret says. ?They?ve tried to harden them a little bit more [than these other systems], but for folks at a place like the NSA or any other major government intelligence agency, it?s pretty standard fare of having a ready-to-go backdoor for your [off-the-shelf] Cisco or Juniper models.? Not all of the activity mentioned in the budget document involved remote hacking. In some cases, according to the document, the operations involved clandestine activity by the CIA or military intelligence units to ?physically place hardware implants or software modifications? to aid the spying. ?Much more often, an implant is coded entirely in software by an NSA group called Tailored Access Operations (TAO),? the Post writes in its story about the document. ?As its name suggests, TAO builds attack tools that are custom-fitted to their targets.? A handful of security researchers have uncovered vulnerabilities in routers in recent years that could be used to do the kind of hacking described in the budget document. In 2005, security researcher Mike Lynn found a serious vulnerability in Cisco IOS, the operating system running on millions of Cisco routers around the world. Lynn discovered the vulnerability after his employer, Internet Security Systems, asked him to reverse-engineer the Cisco operating system to see if he could find security problems with it. Cisco makes the majority of the routers that operate the backbone of the internet as well as many company networks and critical infrastructure systems. The Cisco IOS is as ubiquitous in the backbone as the Windows operating system is on desktops. The vulnerability Lynn found, in a new version of the operation system that Cisco planned to release at the time, would have allowed someone to create a router worm that would shut down every Cisco router through which it passed, bringing down a nation?s critical infrastructure. It also would have allowed an attacker to gain complete control of the router to sniff all traffic passing through a network in order to read, record or alter it, or simply prevent traffic from reaching its recipient. Once Lynn found the vulnerability, it took him six months to develop a working exploit to attack it. Lynn had planned to discuss the vulnerability at the Black Hat security conference in Las Vegas, until Cisco intervened and forced him to pull the talk under threat of a lawsuit. But if Lynn knew about the vulnerability, there were likely others who did as well ? including intelligence agencies and criminal hackers. Source code for Cisco?s IOS has been stolen at least twice, either by entities who were interested in studying the software to gain a competitive advantage or to uncover vulnerabilities that would allow someone to hack or control them. Other researchers have uncovered different vulnerabilities in other Cisco routers that are commonly used in small businesses and home offices. Every year at computer security conferences ? including the Black Hat conference where NSA Director Keith Alexander presented a keynote this year ? U.S. intelligence agencies and contractors from around the world attend to discover information about new vulnerabilities that might be exploited and to hire talented researchers and hackers capable of finding more vulnerabilities in systems. In 2008, a researcher at Core Security Technologies developed a root kit for the Cisco IOS that was designed to give an attacker a persistent foothold on a Cisco router while remaining undetected. According to the Post story, the NSA designs most of the offensive tools it uses in its Genie operation, but it spent $25.1 million in one year for ?additional covert purchases of software vulnerabilities? from private malware vendors who operate on the grey market ? closed markets that peddle vulnerabilities and exploits to law enforcement and intelligence agencies, as opposed to the black market that sells them to cyber criminals. The price of vulnerabilities and exploits varies, depending on a number of factors. Vulnerabilities and exploits can sell for anywhere from $50,000 to more than a million, depending on the exclusivity of the purchase ? some vulnerabilities are sold to multiple parties with the understanding that others are using it as well ? and their ubiquity. A vulnerability that exists in multiple versions of an operating system is more valuable than a vulnerability that exists in just one version. A class of vulnerability that crosses multiple browser brands is also more valuable than a single vulnerability that just affects the Safari browser or Chrome. The Stuxnet cyber weapon that was reportedly created by the U.S. and Israel to sabotage centrifuges used in Iran?s uranium enrichment program, used five zero-day exploits to spread itself among systems in Iran, including a rare exploit that attacked the .LNK function in multiple versions of the Windows operating system in order to spread the worm silently via infected USB sticks. Ubiquitous router vulnerabilities are difficult to find since there are so many different configurations for routers, and an attack that works against one router configuration might not work for another. But a vulnerability that affects the core operating system is much more valuable since it is less likely to be dependent on the configuration. Maiffret says there hasn?t been a lot of public research on router vulnerabilities, but whenever someone has taken a look at them, they have found security holes in them. ?They?re always successful in finding something,? he says. Once a vulnerability becomes known to the software maker and is patched, it loses a lot of its value. But because many users and administrators do not patch their systems, some vulnerabilities can be used effectively for years, even after a patch is available. The Conficker worm, for example, continued to infect millions of computers long after Microsoft released a patch that should have stopped the worm from spreading. Routers in particular often remain unpatched because system administrators don?t think they will be targeted and because administrators are concerned about network outages that could occur while the patch is applied or if the patch is faulty. Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. Read more by Kim Zetter Follow @KimZetter and @ThreatLevel on Twitter. From surfer at mauigateway.com Wed Sep 4 21:05:04 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 4 Sep 2013 14:05:04 -0700 Subject: NSA Laughs at PCs, Prefers Hacking Routers and Switches Message-ID: <20130904140504.7B2D3D93@resin03.mta.everyone.net> --- eugen at leitl.org wrote: From: Eugen Leitl ?No one updates their routers,? he says. ?If you think people are bad about patching Windows and Linux (which they are) then they are ? horrible about updating their networking gear because it is too critical, and usually they don?t have redundancy to be able to do it properly.? ------------------------------------------------------ So, they're saying upgrade to every new OS that comes out? Plus, isn't spelling a requirement for journalists these days??? "...patching Windows and Linux (which they are) then they are..." ------------------------------------------------------ Hijacking routers and switches could allow the NSA to do more than just eavesdrop on all the communications crossing that equipment. It would also let them bring down networks or prevent certain communication, such as military orders, from getting through, though the Post story doesn?t report any such activities. With control of routers, the NSA could re-route traffic to a different location, or intelligence agencies could alter it for disinformation campaigns, such as planting information that would have a detrimental political effect or altering orders to re-route troops or supplies in a military operation. ------------------------------------------ This is just confused, like much of the rest of the article. Mostly FUD with a small kernel of fact inside the FUD wrapper. scott From wbailey at satelliteintelligencegroup.com Wed Sep 4 21:25:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 4 Sep 2013 21:25:33 +0000 Subject: NSA Laughs at PCs, Prefers Hacking Routers and Switches In-Reply-To: <20130904140504.7B2D3D93@resin03.mta.everyone.net> References: <20130904140504.7B2D3D93@resin03.mta.everyone.net> Message-ID: <1joyh5mwivttcbge0k33cuy1.1378329927686@email.android.com> Spelling requirements for journalists were lifted when blogs came on the scene. Sent from my Mobile Device. -------- Original message -------- From: Scott Weeks Date: 09/04/2013 2:06 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: NSA Laughs at PCs, Prefers Hacking Routers and Switches --- eugen at leitl.org wrote: From: Eugen Leitl ?No one updates their routers,? he says. ?If you think people are bad about patching Windows and Linux (which they are) then they are ? horrible about updating their networking gear because it is too critical, and usually they don?t have redundancy to be able to do it properly.? ------------------------------------------------------ So, they're saying upgrade to every new OS that comes out? Plus, isn't spelling a requirement for journalists these days??? "...patching Windows and Linux (which they are) then they are..." ------------------------------------------------------ Hijacking routers and switches could allow the NSA to do more than just eavesdrop on all the communications crossing that equipment. It would also let them bring down networks or prevent certain communication, such as military orders, from getting through, though the Post story doesn?t report any such activities. With control of routers, the NSA could re-route traffic to a different location, or intelligence agencies could alter it for disinformation campaigns, such as planting information that would have a detrimental political effect or altering orders to re-route troops or supplies in a military operation. ------------------------------------------ This is just confused, like much of the rest of the article. Mostly FUD with a small kernel of fact inside the FUD wrapper. scott From frnkblk at iname.com Thu Sep 5 01:39:02 2013 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 4 Sep 2013 20:39:02 -0500 Subject: [Q] Any good resource of info ref LECs, in different US areas? In-Reply-To: <488D9AD6-D3EE-4988-9FF1-1CF696BB91E4@puck.nether.net> References: <488D9AD6-D3EE-4988-9FF1-1CF696BB91E4@puck.nether.net> Message-ID: <005a01cea9d8$b33750e0$19a5f2a0$@iname.com> There used to isp-bandwidth (hosted by isp-planet), but that closed several years ago. -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, September 04, 2013 2:27 PM To: Stefan Cc: nanog at nanog.org Subject: Re: [Q] Any good resource of info ref LECs, in different US areas? I've almost thought there should be a nanog-type list for posting these types of inquiries to help folks dig up access... - Jared From bicknell at ufp.org Thu Sep 5 01:47:40 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 4 Sep 2013 20:47:40 -0500 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> Message-ID: <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> I've got to apologize publicly to Yahoo! here as part of my issue was my own stupidity. It appears in the past I've had multiple Yahoo! ID's and I was trying to use the wrong one, one that may have gone away a long time ago, rather than my still active ID. Some helpful people at Yahoo got me straightened out on that point. My apologies for disparaging Yahoo! when it was my own fault. There's still the much more minor point that when I tried to "self serve" I ended up at a blank page on the Yahoo! web site, hopefully they will figure that out as well. On Sep 4, 2013, at 8:36 AM, Leo Bicknell wrote: > Apparently it was implemented by a group of low-bid programmers in a far off land. > > I have, err, had, a Yahoo! account I used for two things, getting e-mail from Yahoo! groups and accessing Flickr. I was on Flickr not a two or three months ago to fix a picture someone noticed was in the wrong album. > > When I saw this I thought I should log in again to reset my one year ticker. Off to www.yahoo.com and click sign in. > > Enter userid, enter password. > > Drops me to a CAPTCHA screen, that's odd, never seen that before, but ok. > > Enter CAPTCHA and it redirects me to "https://edit.yahoo.com/forgot", which when reached from said CAPTCHA screen renders as a 100% blank page. > > That's some fine web coding. > > I went to the flickr site, tried to log in. At least there it tells me my userid is in the process of being recycled. No option to recover. > > Try creating a new account with the same userid, sorry, it's in use. > > So as far as I can tell: > - The must be inactive for one year is BS, and/or logging into Flickr didn't count in my case. > - No notifications are sent, so if you're a person who is there for things like Yahoo groups and forwards your e-mail elsewhere you may be using the service in a way that generates no logs. > - There is no way to get an account back that is in the recycling phase, which is frankly stupid. > > As a result Yahoo! has lost a Flickr and Groups member, and I'm not sure I see any reason to sign up again at this point. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Thu Sep 5 04:17:28 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Sep 2013 00:17:28 -0400 Subject: Yahoo is now recycling handles In-Reply-To: Your message of "Wed, 04 Sep 2013 20:47:40 -0500." <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> Message-ID: <11481.1378354648@turing-police.cc.vt.edu> On Wed, 04 Sep 2013 20:47:40 -0500, Leo Bicknell said: > There's still the much more minor point that when I tried to "self > serve" I ended up at a blank page on the Yahoo! web site, hopefully they > will figure that out as well. I'm continually amazed at the number of web designers that don't test their pages with NoScript enabled. Just sayin'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From alter3d at alter3d.ca Thu Sep 5 04:56:02 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 05 Sep 2013 00:56:02 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <11481.1378354648@turing-police.cc.vt.edu> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <11481.1378354648@turing-police.cc.vt.edu> Message-ID: <52280EE2.4060303@alter3d.ca> On 9/5/2013 12:17 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 04 Sep 2013 20:47:40 -0500, Leo Bicknell said: >> There's still the much more minor point that when I tried to "self >> serve" I ended up at a blank page on the Yahoo! web site, hopefully they >> will figure that out as well. > I'm continually amazed at the number of web designers that don't test > their pages with NoScript enabled. Just sayin'. NoScript? That's some kind of antimalvirus thingy for Internet Explorer, right? I think I read something about that in the Website Design For Dimwits in 24 Hours book... ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4246 bytes Desc: S/MIME Cryptographic Signature URL: From jgreco at ns.sol.net Thu Sep 5 04:47:28 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Sep 2013 23:47:28 -0500 (CDT) Subject: Yahoo is now recycling handles In-Reply-To: <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> Message-ID: <201309050447.r854lSXr069122@aurora.sol.net> > I've got to apologize publicly to Yahoo! here as part of my issue was my = > own stupidity. It appears in the past I've had multiple Yahoo! ID's and = > I was trying to use the wrong one, one that may have gone away a long = > time ago, rather than my still active ID. Some helpful people at Yahoo = > got me straightened out on that point. My apologies for disparaging = > Yahoo! when it was my own fault. Error or not, the recycling problem's real. I find myself having received some sales figures for a Jiffy Lube chain somewhere, and I have to assume that there will be a lot of instances where set-and-forget users have supplied their Yahoo address to business partners, financial institutions, etc. and who will continue to send confidential mail to the recycled address. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From alter3d at alter3d.ca Thu Sep 5 05:38:27 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 05 Sep 2013 01:38:27 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <522814AE.4090704@cox.net> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <11481.1378354648@turing-police.cc.vt.edu> <522814AE.4090704@cox.net> Message-ID: <522818D3.8090005@alter3d.ca> On 9/5/2013 1:20 AM, Larry Sheldon wrote: > On 9/4/2013 11:56 PM, Peter Kristolaitis wrote: >> On 9/5/2013 12:17 AM, Valdis.Kletnieks at vt.edu wrote: >>> On Wed, 04 Sep 2013 20:47:40 -0500, Leo Bicknell said: >>>> There's still the much more minor point that when I tried to "self >>>> serve" I ended up at a blank page on the Yahoo! web site, hopefully >>>> they >>>> will figure that out as well. >>> I'm continually amazed at the number of web designers that don't test >>> their pages with NoScript enabled. Just sayin'. >> >> NoScript? That's some kind of antimalvirus thingy for Internet >> Explorer, right? I think I read something about that in the Website >> Design For Dimwits in 24 Hours book... ;) > > I would not use IE on a bet, but I do use NoScript as well as several > other defensive weapons. > > I probably do not give a big rats patotie what your site offers--I > know it won't be good. > I assume that you intended this for the list and not me directly, and that you haven't yet got around to reading "Things To Experience On The Internet, Volume 1: Sarcasm". :) In case it wasn't abundantly clear, my post was a shot at what often passes for "web developer" these days. I had hoped that "antimalvirus" would have been an indication that it was a joke, but I guess my sarcasm is rusty... I would hope that no one on this list is ignorant of both the failings of IE and of the existence of NoScript. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4246 bytes Desc: S/MIME Cryptographic Signature URL: From eugen at leitl.org Thu Sep 5 11:20:12 2013 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 5 Sep 2013 13:20:12 +0200 Subject: [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers and Switches Message-ID: <20130905112012.GD29404@leitl.org> ----- Forwarded message from liberationtech at lewman.us ----- Date: Wed, 4 Sep 2013 22:27:46 -0400 From: liberationtech at lewman.us To: liberationtech at lists.stanford.edu Subject: Re: [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers and Switches Organization: The Tor Project, Inc. X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Reply-To: liberationtech On Wed, 4 Sep 2013 20:33:09 -0400 Robert Guerra wrote: > > Curious on people's comments on types of routers, firewalls and > other appliances that might be affected as well as mitigation > strategies. Would installing a pfsense and/or other open source > firewall be helpful in anyway at a home net location? When I read this article, I read core routers and switches at ISPs, like Cisco, Juniper, F5, etc. I don't read this as linksys, dlink, netgear, etc. I'm sure NSA could crack into anything consumer level with ease, it's likely any 4-bit criminal could do it too. However, it makes more sense for NSA to watch the core connectivity points on the Internet, rather than watching individuals, solely from an economic effort versus benefit point of view. When I ran global networks, one can record everything and sort out the individual streams later to find employees doing various layers of fraud or not. There was no point in watching the end points because it was too resource intensive. I'm sure the NSA has analyzed this and come to the same conclusion. There's no point in going after tens of millions of endpoints, when you can own them all with a handful of switches. A counterpoint is that most core Internet routers and switches are running at capacity and any monitoring affects quality of service and gets customers complaining. -- Andrew http://tpo.is/contact pgp 0x6B4D6475 -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 From khelms at zcorum.com Thu Sep 5 14:02:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 5 Sep 2013 10:02:39 -0400 Subject: [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers and Switches In-Reply-To: <20130905112012.GD29404@leitl.org> References: <20130905112012.GD29404@leitl.org> Message-ID: The last paragraph in the post is the most important, but it invalidates the rest of the post. Core routers are a terrible intercept point because of load and the sheer amount of packets they process and they are also MUCH more likely to be running up to date firmware than a router in an edge network where the main technical person is primarily a Windows/Exchange admin. The problem with recording "everything" is that its not feasible and the idea that all/most/many core routers are merrily sending a copy of all packets to some external storage facility is demonstrably false. If you want to record flows that's a bit more technically (and legally in the US since its meta-data) feasible, but again netflow traffic from all/most/many core routers is extremely hard to hide on a 24/7 basis and again is demonstrably false. Its far easier (technically and legally) for the NSA to have a directory of devices they can tap on demand without the knowledge of the owners either through unpatched security flaws, cooperation from the carrier, or intentionally built back doors. Its also more feasibly for them (and we have good evidence this has happened) to directly mirror the layer 2 traffic on some of the largest backbone networks. This of course allows them to passively listen without impacting the core router, but that approach is quite difficult to leverage when you're trying to target a specific person or organization since the volume of unimportant information so greatly exceeds the targeted information. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 5, 2013 at 7:20 AM, Eugen Leitl wrote: > ----- Forwarded message from liberationtech at lewman.us ----- > > Date: Wed, 4 Sep 2013 22:27:46 -0400 > From: liberationtech at lewman.us > To: liberationtech at lists.stanford.edu > Subject: Re: [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers > and Switches > Organization: The Tor Project, Inc. > X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-pc-linux-gnu) > Reply-To: liberationtech > > On Wed, 4 Sep 2013 20:33:09 -0400 > Robert Guerra wrote: > > > > > Curious on people's comments on types of routers, firewalls and > > other appliances that might be affected as well as mitigation > > strategies. Would installing a pfsense and/or other open source > > firewall be helpful in anyway at a home net location? > > When I read this article, I read core routers and switches at ISPs, > like Cisco, Juniper, F5, etc. I don't read this as linksys, dlink, > netgear, etc. I'm sure NSA could crack into anything consumer > level with ease, it's likely any 4-bit criminal could do it too. > However, it makes more sense for NSA to watch the core connectivity > points on the Internet, rather than watching individuals, solely from > an economic effort versus benefit point of view. > > When I ran global networks, one can record everything and sort out the > individual streams later to find employees doing various layers of > fraud or not. There was no point in watching the end points because it > was too resource intensive. > > I'm sure the NSA has analyzed this and come to the same conclusion. > There's no point in going after tens of millions of endpoints, when you > can own them all with a handful of switches. > > A counterpoint is that most core Internet routers and switches are > running at capacity and any monitoring affects quality of service and > gets customers complaining. > > -- > Andrew > http://tpo.is/contact > pgp 0x6B4D6475 > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > companys at stanford.edu. > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 > > From mike at mtcc.com Thu Sep 5 14:29:31 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 05 Sep 2013 07:29:31 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <11481.1378354648@turing-police.cc.vt.edu> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <11481.1378354648@turing-police.cc.vt.edu> Message-ID: <5228954B.9040805@mtcc.com> On 09/04/2013 09:17 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 04 Sep 2013 20:47:40 -0500, Leo Bicknell said: >> There's still the much more minor point that when I tried to "self >> serve" I ended up at a blank page on the Yahoo! web site, hopefully they >> will figure that out as well. > I'm continually amazed at the number of web designers that don't test > their pages with NoScript enabled. Just sayin'. > Noscript users are even less important than ie6 users. Welcome to the long tail of irrelevance. Mike From bicknell at ufp.org Thu Sep 5 14:34:01 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 5 Sep 2013 07:34:01 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <11481.1378354648@turing-police.cc.vt.edu> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <11481.1378354648@turing-police.cc.vt.edu> Message-ID: <20130905143401.GA78217@ussenterprise.ufp.org> In a message written on Thu, Sep 05, 2013 at 12:17:28AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 04 Sep 2013 20:47:40 -0500, Leo Bicknell said: > > There's still the much more minor point that when I tried to "self > > serve" I ended up at a blank page on the Yahoo! web site, hopefully they > > will figure that out as well. > > I'm continually amazed at the number of web designers that don't test > their pages with NoScript enabled. Just sayin'. While perhaps likely I would use NoScript, the failure in question happened with a bone stock, up to date Safari client with JavaScript enabled. No ad-block or other software to interfear. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From lixia at cs.ucla.edu Thu Sep 5 16:25:39 2013 From: lixia at cs.ucla.edu (Lixia Zhang) Date: Thu, 5 Sep 2013 09:25:39 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> Message-ID: <8766C416-BB65-4E97-802B-BB6D16638B18@cs.ucla.edu> On Sep 4, 2013, at 6:47 PM, Leo Bicknell wrote: > > I've got to apologize publicly to Yahoo! here as part of my issue was my own stupidity. It appears in the past I've had multiple Yahoo! ID's and I was trying to use the wrong one, one that may have gone away a long time ago, rather than my still active ID. Some helpful people at Yahoo got me straightened out on that point. My apologies for disparaging Yahoo! when it was my own fault. > > There's still the much more minor point that when I tried to "self serve" I ended up at a blank page on the Yahoo! web site, hopefully they will figure that out as well. I surely hope so too. When I tried to get my old yahoo email account back (I have only ONE), and ended with the same empty page. Hope some yahoo people on this list listening. It is important to me I can get that email address back; some friends only know me by that address. Lixia > On Sep 4, 2013, at 8:36 AM, Leo Bicknell wrote: > >> Apparently it was implemented by a group of low-bid programmers in a far off land. >> >> I have, err, had, a Yahoo! account I used for two things, getting e-mail from Yahoo! groups and accessing Flickr. I was on Flickr not a two or three months ago to fix a picture someone noticed was in the wrong album. >> >> When I saw this I thought I should log in again to reset my one year ticker. Off to www.yahoo.com and click sign in. >> >> Enter userid, enter password. >> >> Drops me to a CAPTCHA screen, that's odd, never seen that before, but ok. >> >> Enter CAPTCHA and it redirects me to "https://edit.yahoo.com/forgot", which when reached from said CAPTCHA screen renders as a 100% blank page. >> >> That's some fine web coding. >> >> I went to the flickr site, tried to log in. At least there it tells me my userid is in the process of being recycled. No option to recover. >> >> Try creating a new account with the same userid, sorry, it's in use. >> >> So as far as I can tell: >> - The must be inactive for one year is BS, and/or logging into Flickr didn't count in my case. >> - No notifications are sent, so if you're a person who is there for things like Yahoo groups and forwards your e-mail elsewhere you may be using the service in a way that generates no logs. >> - There is no way to get an account back that is in the recycling phase, which is frankly stupid. >> >> As a result Yahoo! has lost a Flickr and Groups member, and I'm not sure I see any reason to sign up again at this point. > > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From nazgul at marrowbones.com Thu Sep 5 17:28:07 2013 From: nazgul at marrowbones.com (Kee Hinckley) Date: Thu, 5 Sep 2013 13:28:07 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> Message-ID: <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: > > I've got to apologize publicly to Yahoo! here as part of my issue was my own stupidity. It appears in the past I've had multiple Yahoo! ID's and I was I, on the other hand, need someone from Yahoo! to contact me, because I decided to test their "email wishlist" feature. Repeated attempts got me nothing but a message saying that my credit card information was incorrect. But when I checked my bill this morning, I have three fifty cent charges against my account (one for each time I revalidated my email address while attempting to use their form). There's no contact page on http://wishlist.yahoo.com, despite the fact that it's an ecommerce page that takes credit cards, and there's no apparent way to contact a human from the main yahoo page. I can always ask my credit card company to refuse the charges, but if Yahoo! is charging credit cards and not providing services, I think someone there needs to know there's a problem. Never mind taking credit card numbers and providing no customer support. From karim.adel at gmail.com Thu Sep 5 18:22:09 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Thu, 5 Sep 2013 20:22:09 +0200 Subject: Data Mining/Crawling through a Mailing List Message-ID: Hello, A bit off topic but i was looking for a way/tool that could crawl through nanog(or other) archives and try to filter most common discussions and things like that, if anyone is aware of such a tool, pls let me know. Thanks, Kim From wbailey at satelliteintelligencegroup.com Thu Sep 5 18:24:51 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 5 Sep 2013 18:24:51 +0000 Subject: Data Mining/Crawling through a Mailing List In-Reply-To: References: Message-ID: That tool will have its work cut out for it... ;) Sent from my Mobile Device. -------- Original message -------- From: Kasper Adel Date: 09/05/2013 11:23 AM (GMT-08:00) To: NANOG list Subject: Data Mining/Crawling through a Mailing List Hello, A bit off topic but i was looking for a way/tool that could crawl through nanog(or other) archives and try to filter most common discussions and things like that, if anyone is aware of such a tool, pls let me know. Thanks, Kim From j at 2600hz.com Thu Sep 5 18:26:56 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 5 Sep 2013 18:26:56 +0000 Subject: Data Mining/Crawling through a Mailing List In-Reply-To: References: Message-ID: <63D0DAAD-F529-42B5-B06C-BCB689F24856@2600hz.com> Dump it all into Hadoop and run a word cloud analysis :3. Honestly it sounds like a cool idea, and I'm sure someone has worked on it before but I don't know anything off the top of my head. Cheers, Joshua Sent from my iPad On Sep 5, 2013, at 11:23 AM, "Kasper Adel" wrote: > Hello, > > A bit off topic but i was looking for a way/tool that could crawl through > nanog(or other) archives and try to filter most common discussions and > things like that, if anyone is aware of such a tool, pls let me know. > > Thanks, > Kim From mark at bernoullinetworks.com Thu Sep 5 18:27:26 2013 From: mark at bernoullinetworks.com (Mark Leonard) Date: Thu, 5 Sep 2013 12:27:26 -0600 Subject: AlbertaIX - no longer a Cybera project? Message-ID: It seems that AlbertaIX is no longer listed on Cybera's list of projects: http://www.cybera.ca/strategic-projects/ In fact, doing a search on Cybera's site yields a whole bunch of dead links: http://www.cybera.ca/search?q=albertaix Is AlbertaIX no longer part of the Cybera project inventory? Has Cybera pulled official support for AlbertaIX? Are AlbertaIX and Cybera still sharing an address? [1,2] Just curious. [1] http://www.cybera.ca/contact-us/locations/ [2] http://www.canada-companies-info.com/albertaix-6sh9/ From tony at swalter.com Thu Sep 5 19:09:54 2013 From: tony at swalter.com (Tony Patti) Date: Thu, 5 Sep 2013 15:09:54 -0400 Subject: Data Mining/Crawling through a Mailing List In-Reply-To: References: Message-ID: <0bbe01ceaa6b$813a3060$83ae9120$@swalter.com> Were you thinking about parsing NANOG and creating a word-based streamgraph like this? http://www.benfarahmand.com/2012/12/psl-listserv-streamgraph.html The author of that streamgraph did provide some additional information on the steps he took to create it, but may be too long (including attachments) to post directly to NANOG. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Thursday, September 05, 2013 2:22 PM To: NANOG list Subject: Data Mining/Crawling through a Mailing List Hello, A bit off topic but i was looking for a way/tool that could crawl through nanog(or other) archives and try to filter most common discussions and things like that, if anyone is aware of such a tool, pls let me know. Thanks, Kim From wbailey at satelliteintelligencegroup.com Thu Sep 5 19:12:36 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 5 Sep 2013 19:12:36 +0000 Subject: US and UK spy agencies defeat privacy and security on the internet Message-ID: Anyone else see this coming? US and UK spy agencies defeat privacy and security on the internet http://gu.com/p/3thvv Sent from my Mobile Device. From chris at nmedia.net Thu Sep 5 19:22:03 2013 From: chris at nmedia.net (Chris Cappuccio) Date: Thu, 5 Sep 2013 12:22:03 -0700 Subject: AlbertaIX - no longer a Cybera project? In-Reply-To: References: Message-ID: <20130905192203.GH25464@ref.nmedia.net> Mark Leonard [mark at bernoullinetworks.com] wrote: > It seems that AlbertaIX is no longer listed on Cybera's list of projects: > > http://www.cybera.ca/strategic-projects/ > > In fact, doing a search on Cybera's site yields a whole bunch of dead links: > > http://www.cybera.ca/search?q=albertaix > > Is AlbertaIX no longer part of the Cybera project inventory? Has Cybera > pulled official support for AlbertaIX? > > Are AlbertaIX and Cybera still sharing an address? [1,2] > I can't answer these questions, but it seems that the AlbertaIX chair, Bernard Parkinson (Platinum Communications) resigned yesterday, and the AlbertaIX co-chair, Charles Taylor (City of Calgary) followed him by resigning too. I guess that leaves Bill Sandiford (CIRA) and Jean-Francois Amiot (Cybera) running the show?? -- scio me nihil scire or scio me nescire From leekwas at yahoo.com Thu Sep 5 19:48:30 2013 From: leekwas at yahoo.com (Kwas Lee) Date: Thu, 5 Sep 2013 12:48:30 -0700 (PDT) Subject: SMTP connection + lost while reading message data (header) In-Reply-To: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> References: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> Message-ID: <1378410510.1039.YahooMailNeo@web140701.mail.bf1.yahoo.com> hello Team Could someone please advice as some of sender are unable to send mails to my server when i check the logs? i found 2013-09-05 20:31:32 SMTP connection from smtp-sender.com (senderdomain.com) [xx.xx.xx.xx] lost while reading message data (header) Regads lee From bill at herrin.us Thu Sep 5 21:12:59 2013 From: bill at herrin.us (William Herrin) Date: Thu, 5 Sep 2013 17:12:59 -0400 Subject: SMTP connection + lost while reading message data (header) In-Reply-To: <1378410510.1039.YahooMailNeo@web140701.mail.bf1.yahoo.com> References: <21cf01cea8f0$b6e19ea0$24a4dbe0$@ai.net> <1378410510.1039.YahooMailNeo@web140701.mail.bf1.yahoo.com> Message-ID: On Thu, Sep 5, 2013 at 3:48 PM, Kwas Lee wrote: > Could someone please advice as some of sender are unable to send mails to my server when i check the logs i found > > 2013-09-05 20:31:32 SMTP connection from smtp-sender.com (senderdomain.com) [xx.xx.xx.xx] lost while reading message data (header) Hi Lee, Smells like path MTU. The connection died at what is probably the first time in the SMTP session that the remote system tried to send you a large, probably 1500 byte packet: the beginning (message header) part of the data portion (the email message headers and body themselves, as opposed to the sender and recipient declarations). This is not the only candidate cause, but that's what my mind jumps to. Try adjusting the TCP Maximum Segment Size on your server. Turn it down to 1200 or so and see if the problem vanishes. If so, somebody's losing ICMP packets. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From deraadt at yycix.ca Thu Sep 5 20:47:00 2013 From: deraadt at yycix.ca (Theo de Raadt) Date: Thu, 05 Sep 2013 14:47:00 -0600 Subject: AlbertaIX - no longer a Cybera project? In-Reply-To: Message-ID: <201309052047.r85Kl0Yx021092@cvs.openbsd.org> On Sep 5, Chris Cappuccio wrote: > I can't answer these questions, but it seems that the AlbertaIX chair, Bernard > Parkinson (Platinum Communications) resigned yesterday, and the AlbertaIX co-chair, > Charles Taylor (City of Calgary) followed him by resigning too. > > I guess that leaves Bill Sandiford (CIRA) and Jean-Francois Amiot (Cybera) running > the show?? That is a good question. I am also a director on the AlbertaIX board, and don't have a clue what is going on. Most directors are being kept in the dark, while others take unapproved action. I should probably jump ship as well. The last six months in AlbertaIX saw no discussions (or approval) for any action plan. Without votes, nothing can be built. Now a new chair has to be selected first. Who will it be? The entire organization also lacks documents. The new game plan is to follow YYCIX because of Hurricane Electric's arrival at the datacenter which was (originally) the least preffered. Or maybe the new plan is to simply serve Cybera's interests through the re-use of seed money? After all, Cybera also supplies the secretary. I don't have answers, though I've been asking questions since the beginning. Things first went crazy in December when YYCIX was formed and installed a switch within days. Yes, as a local go-to-guy who wants to see better net around here, I installed the equipment. The schism between AlbertaIX and YYCIX has been discussed before, so I need not explain it here. Recently, events again went crazy when Robin Windsor (CEO of Cybera, the NPO local EDU provider) walked into an AlbertaIX board meeting and withheld Alberta Government seed money from AlbertaIX for the purchase of a switch --- unless I resign immediately. (It was quite a battle getting that episode into the minutes). The entire process was opaque and undemocratic from the start. It was captured. From royce at techsolvency.com Thu Sep 5 21:07:48 2013 From: royce at techsolvency.com (Royce Williams) Date: Thu, 5 Sep 2013 13:07:48 -0800 Subject: Yahoo is now recycling handles In-Reply-To: <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> Message-ID: On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley wrote: > > On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: > >> >> I've got to apologize publicly to Yahoo! here as part of my issue was my own stupidity. It appears in the past I've had multiple Yahoo! ID's and I was > > I, on the other hand, need someone from Yahoo! to contact me, because I decided to test their "email wishlist" feature. Repeated attempts got me nothing but a message saying that my credit card information was incorrect. But when I checked my bill this morning, I have three fifty cent charges against my account (one for each time I revalidated my email address while attempting to use their form). There's no contact page on http://wishlist.yahoo.com, despite the fact that it's an ecommerce page that takes credit cards, and there's no apparent way to contact a human from the main yahoo page. I can always ask my credit card company to refuse the charges, but if Yahoo! is charging credit cards and not providing services, I think someone there needs to know there's a problem. Never mind taking credit card numbers and providing no customer support. And it's not an isolated incident -- the exact same thing happened to me last night as well. Royce From jra at baylink.com Thu Sep 5 22:33:17 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 05 Sep 2013 18:33:17 -0400 Subject: MTR for Android? Message-ID: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> Does anybody know if the program has been ported, or re-created there? I have searched the market, but not found anything... at least nothing whose description includes the letters mtr. - jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From randy at psg.com Thu Sep 5 23:07:43 2013 From: randy at psg.com (Randy Bush) Date: Fri, 06 Sep 2013 08:07:43 +0900 Subject: AlbertaIX - no longer a Cybera project? In-Reply-To: <201309052047.r85Kl0Yx021092@cvs.openbsd.org> References: <201309052047.r85Kl0Yx021092@cvs.openbsd.org> Message-ID: < irrelevant spectator commentary > i do not know squat about the local issues in alberta. but we all seem to spend a lot of time and energy going sideways, sometimes backward, instead of forward. what is under these recent, seemingly unproductive, canadian exchange spats? why is vancouver a suburb of seattle? is it some sort of physics with telco horizontal vs trans-border pricing, or regulatory restrictions, or is it the poutine? i always thought canada was a somethat more civilized culture, well, except for poutine. it all looks strange from here. but then don't ask me why tokyo has the number of exchanges it does. randy From dmiller at tiggee.com Thu Sep 5 23:10:56 2013 From: dmiller at tiggee.com (David Miller) Date: Thu, 05 Sep 2013 19:10:56 -0400 Subject: MTR for Android? In-Reply-To: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> References: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> Message-ID: <52290F80.6060606@tiggee.com> On 9/5/2013 6:33 PM, Jay Ashworth wrote: > Does anybody know if the program has been ported, or re-created there? > > I have searched the market, but not found anything... at least nothing whose description includes the letters mtr. > - jra > I am not aware of a port of MTR, but I have used an app called TracePing for much of the same functionality. https://play.google.com/store/apps/details?id=com.inflim.trp -DMM From elouie at yahoo.com Thu Sep 5 23:28:16 2013 From: elouie at yahoo.com (Eric Louie) Date: Thu, 5 Sep 2013 16:28:16 -0700 Subject: FW: Yahoo Maintenance Notification for CoreSite - Any2 Denver Message-ID: <03aa01ceaa8f$999fb930$ccdf2b90$@com> For any Yahoo peers at Coresite, FYI - I'm expecting to lose my BGP peer for a portion of their maintenance. > -----Original Message----- > From: CoreSite OSC [mailto:osc at coresite.com] > Sent: Thursday, September 05, 2013 3:50 PM > Cc: CoreSite OSC; netops > Subject: FW: Yahoo Maintenance Notification for CoreSite - Any2 Denver > > Message forwarded from Yahoo. > > Operations Support Center > > CORESITE > (NYSE: COR) > +1.866.777.CORE (Prompt 2) > > OSC at CoreSite.com | www.CoreSite.com > > > -----Original Message----- > From: Nevin Gonsalves [mailto:nevin at yahoo-inc.com] > Sent: Thursday, September 05, 2013 9:43 AM > To: CoreSite OSC; Any2 > Subject: Yahoo Maintenance Notification for CoreSite - Any2 Denver > > Can you please help forward this notify to peers and if possible cc > peering at yahoo-inc.com - thx. > > > > Hi Peers, > > > Yahoo will be performing a maintenance on our router at CoreSite - Any2 > Denver. This will affect all peering sessions on our routers. > > > Exchange peering IPv4: 206.51.46.25 and Ipv6: 2605:6c00:303:303::25 > ASN: 10310 > Start:2013/09/05 18:00 PDT > End: 2013/09/05 21:00 PDT > Peering details: as10310.peeringdb.com > > > Thanks, > Nevin Gonsalves > Nevin at yahoo-inc.com / peering at yahoo-inc.com > From randy at psg.com Thu Sep 5 23:30:50 2013 From: randy at psg.com (Randy Bush) Date: Fri, 06 Sep 2013 08:30:50 +0900 Subject: MTR for Android? In-Reply-To: <52290F80.6060606@tiggee.com> References: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> <52290F80.6060606@tiggee.com> Message-ID: > https://play.google.com/store/apps/details?id=com.inflim.trp it needs all this because? This app has access to these permissions: Your location precise location (GPS and network-based) approximate location (network-based) Network communication full network access view network connections Phone calls read phone status and identity Storage modify or delete the contents of your USB storage Your accounts read Google service configuration Development tools read sensitive log data System tools test access to protected storage Affects Battery prevent device from sleeping randy From jra at baylink.com Thu Sep 5 23:32:14 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 05 Sep 2013 19:32:14 -0400 Subject: MTR for Android? In-Reply-To: References: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> <52290F80.6060606@tiggee.com> Message-ID: <85fd23be-08e0-4eac-9f11-600f07b8d6ef@email.android.com> Fair point. Have submitted a bug and an rfe; will request clarification if I get a dialog on. Randy Bush wrote: >> https://play.google.com/store/apps/details?id=com.inflim.trp > >it needs all this because? > > This app has access to these permissions: > Your location > precise location (GPS and network-based) > approximate location (network-based) > Network communication > full network access > view network connections > Phone calls > read phone status and identity > Storage > modify or delete the contents of your USB storage > Your accounts > read Google service configuration > Development tools > read sensitive log data > System tools > test access to protected storage > Affects Battery > prevent device from sleeping > >randy -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From cb.list6 at gmail.com Fri Sep 6 00:20:39 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 5 Sep 2013 17:20:39 -0700 Subject: MTR for Android? In-Reply-To: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> References: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> Message-ID: On Sep 5, 2013 3:34 PM, "Jay Ashworth" wrote: > > Does anybody know if the program has been ported, or re-created there? > > I have searched the market, but not found anything... at least nothing whose description includes the letters mtr. > - jra Mtr is here http://dan.drown.org/android/pkg/ CB > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Fri Sep 6 00:26:07 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 05 Sep 2013 20:26:07 -0400 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> Message-ID: <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> They're just validating a credit card number; that was an authorization which won't be settled, almost certainly. Royce Williams wrote: >On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley >wrote: >> >> On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: >> >>> >>> I've got to apologize publicly to Yahoo! here as part of my issue >was my own stupidity. It appears in the past I've had multiple Yahoo! >ID's and I was >> >> I, on the other hand, need someone from Yahoo! to contact me, because >I decided to test their "email wishlist" feature. Repeated attempts got >me nothing but a message saying that my credit card information was >incorrect. But when I checked my bill this morning, I have three fifty >cent charges against my account (one for each time I revalidated my >email address while attempting to use their form). There's no contact >page on http://wishlist.yahoo.com, despite the fact that it's an >ecommerce page that takes credit cards, and there's no apparent way to >contact a human from the main yahoo page. I can always ask my credit >card company to refuse the charges, but if Yahoo! is charging credit >cards and not providing services, I think someone there needs to know >there's a problem. Never mind taking credit card numbers and providing >no customer support. > >And it's not an isolated incident -- the exact same thing happened to >me last night as well. > >Royce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From wbailey at satelliteintelligencegroup.com Fri Sep 6 01:10:04 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Sep 2013 01:10:04 +0000 Subject: Yahoo is now recycling handles In-Reply-To: <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> , <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> Message-ID: Makes you wonder why the charges are in triplicate? An authorization takes place once to validate the card certainly, but once the validation is done yahoo should mark the card as good and allow you to party as previous scheduled. This isn't shocking.. Considering almost anything to do with Yahoo! turns into an epic cluster product and service wise. I'm still curious as to how they are actually going to generate money.. Probably a little less curious than they are I'd imagine.. ;) Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth Date: 09/05/2013 5:27 PM (GMT-08:00) To: Royce Williams ,"nanog at nanog.org list" Subject: Re: Yahoo is now recycling handles They're just validating a credit card number; that was an authorization which won't be settled, almost certainly. Royce Williams wrote: >On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley >wrote: >> >> On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: >> >>> >>> I've got to apologize publicly to Yahoo! here as part of my issue >was my own stupidity. It appears in the past I've had multiple Yahoo! >ID's and I was >> >> I, on the other hand, need someone from Yahoo! to contact me, because >I decided to test their "email wishlist" feature. Repeated attempts got >me nothing but a message saying that my credit card information was >incorrect. But when I checked my bill this morning, I have three fifty >cent charges against my account (one for each time I revalidated my >email address while attempting to use their form). There's no contact >page on http://wishlist.yahoo.com, despite the fact that it's an >ecommerce page that takes credit cards, and there's no apparent way to >contact a human from the main yahoo page. I can always ask my credit >card company to refuse the charges, but if Yahoo! is charging credit >cards and not providing services, I think someone there needs to know >there's a problem. Never mind taking credit card numbers and providing >no customer support. > >And it's not an isolated incident -- the exact same thing happened to >me last night as well. > >Royce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mpetach at netflight.com Fri Sep 6 01:33:13 2013 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 5 Sep 2013 18:33:13 -0700 Subject: FW: Yahoo Maintenance Notification for CoreSite - Any2 Denver In-Reply-To: <03aa01ceaa8f$999fb930$ccdf2b90$@com> References: <03aa01ceaa8f$999fb930$ccdf2b90$@com> Message-ID: On Thu, Sep 5, 2013 at 4:28 PM, Eric Louie wrote: > For any Yahoo peers at Coresite, FYI - I'm expecting to lose my BGP peer > for > a portion of their maintenance. > Should be all back up and happy on the new blade now. ^_^ Thanks! Matt > > > -----Original Message----- > > From: CoreSite OSC [mailto:osc at coresite.com] > > Sent: Thursday, September 05, 2013 3:50 PM > > Cc: CoreSite OSC; netops > > Subject: FW: Yahoo Maintenance Notification for CoreSite - Any2 Denver > > > > Message forwarded from Yahoo. > > > > Operations Support Center > > > > CORESITE > > (NYSE: COR) > > +1.866.777.CORE (Prompt 2) > > > > OSC at CoreSite.com | www.CoreSite.com > > > > > > -----Original Message----- > > From: Nevin Gonsalves [mailto:nevin at yahoo-inc.com] > > Sent: Thursday, September 05, 2013 9:43 AM > > To: CoreSite OSC; Any2 > > Subject: Yahoo Maintenance Notification for CoreSite - Any2 Denver > > > > Can you please help forward this notify to peers and if possible cc > > peering at yahoo-inc.com - thx. > > > > > > > > Hi Peers, > > > > > > Yahoo will be performing a maintenance on our router at CoreSite - Any2 > > Denver. This will affect all peering sessions on our routers. > > > > > > Exchange peering IPv4: 206.51.46.25 and Ipv6: 2605:6c00:303:303::25 > > ASN: 10310 > > Start:2013/09/05 18:00 PDT > > End: 2013/09/05 21:00 PDT > > Peering details: as10310.peeringdb.com > > > > > > Thanks, > > Nevin Gonsalves > > Nevin at yahoo-inc.com / peering at yahoo-inc.com > > > > > > From jra at baylink.com Fri Sep 6 03:55:16 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 05 Sep 2013 23:55:16 -0400 Subject: Yahoo is now recycling handles In-Reply-To: References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> , <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> Message-ID: <8095bc40-f4d6-45b0-8e64-3806dba69002@email.android.com> "Repeated attempts". Wonder how many. Cheers, - jr 'betting on three' a Warren Bailey wrote: >Makes you wonder why the charges are in triplicate? An authorization >takes place once to validate the card certainly, but once the >validation is done yahoo should mark the card as good and allow you to >party as previous scheduled. This isn't shocking.. Considering almost >anything to do with Yahoo! turns into an epic cluster product and >service wise. I'm still curious as to how they are actually going to >generate money.. Probably a little less curious than they are I'd >imagine.. ;) > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: Jay Ashworth >Date: 09/05/2013 5:27 PM (GMT-08:00) >To: Royce Williams ,"nanog at nanog.org list" > >Subject: Re: Yahoo is now recycling handles > > >They're just validating a credit card number; that was an authorization >which won't be settled, almost certainly. > >Royce Williams wrote: >>On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley >>wrote: >>> >>> On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: >>> >>>> >>>> I've got to apologize publicly to Yahoo! here as part of my issue >>was my own stupidity. It appears in the past I've had multiple Yahoo! >>ID's and I was >>> >>> I, on the other hand, need someone from Yahoo! to contact me, >because >>I decided to test their "email wishlist" feature. Repeated attempts >got >>me nothing but a message saying that my credit card information was >>incorrect. But when I checked my bill this morning, I have three fifty >>cent charges against my account (one for each time I revalidated my >>email address while attempting to use their form). There's no contact >>page on http://wishlist.yahoo.com, despite the fact that it's an >>ecommerce page that takes credit cards, and there's no apparent way to >>contact a human from the main yahoo page. I can always ask my credit >>card company to refuse the charges, but if Yahoo! is charging credit >>cards and not providing services, I think someone there needs to know >>there's a problem. Never mind taking credit card numbers and providing >>no customer support. >> >>And it's not an isolated incident -- the exact same thing happened to >>me last night as well. >> >>Royce > >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From wbailey at satelliteintelligencegroup.com Fri Sep 6 04:29:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Sep 2013 04:29:33 +0000 Subject: Yahoo is now recycling handles In-Reply-To: <8095bc40-f4d6-45b0-8e64-3806dba69002@email.android.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> , <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> , <8095bc40-f4d6-45b0-8e64-3806dba69002@email.android.com> Message-ID: <4xp7bxlykg1yp641l25y5npb.1378441768846@email.android.com> Cough. > >And it's not an isolated incident -- the exact same thing happened to >me last night as well. > >Royce Cough. ;) Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth Date: 09/05/2013 8:55 PM (GMT-08:00) To: Warren Bailey ,Warren Bailey ,Royce Williams ,"nanog at nanog.org list" Subject: Re: Yahoo is now recycling handles "Repeated attempts". Wonder how many. Cheers, - jr 'betting on three' a Warren Bailey wrote: Makes you wonder why the charges are in triplicate? An authorization takes place once to validate the card certainly, but once the validation is done yahoo should mark the card as good and allow you to party as previous scheduled. This isn't shocking.. Considering almost anything to do with Yahoo! turns into an epic cluster product and service wise. I'm still curious as to how they are actually going to generate money.. Probably a little less curious than they are I'd imagine.. ;) Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth Date: 09/05/2013 5:27 PM (GMT-08:00) To: Royce Williams ,"nanog at nanog.org list" Subject: Re: Yahoo is now recycling handles They're just validating a credit card number; that was an authorization which won't be settled, almost certainly. Royce Williams wrote: >On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley >wrote: >> >> On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: >> >>> >>> I've got to apologize publicly to Yahoo! here as part of my issue >was my own stupidity. It appears in the past I've had multiple Yahoo! >ID's and I was >> >> I, on the other hand, need someone from Yahoo! to contact me, because >I decided to test their "email wishlist" feature. Repeated attempts got >me nothing but a message saying that my credit card information was >incorrect. But when I checked my bill this morning, I have three fifty >cent charges against my account (one for each time I revalidated my >email address while attempting to use their form). There's no contact >page on http://wishlist.yahoo.com, despite the fact that it's an >ecommerce page that takes credit cards, and there's no apparent way to >contact a human from the main yahoo page. I can always ask my credit >card company to refuse the charges, but if Yahoo! is charging credit >cards and not providing services, I think someone there needs to know >there's a problem. Never mind taking credit card numbers and providing >no customer support. > >And it's not an isolated incident -- the exact same thing happened to >me last night as well. > >Royce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From leekwas at yahoo.com Fri Sep 6 05:00:13 2013 From: leekwas at yahoo.com (Kwas Lee) Date: Thu, 5 Sep 2013 22:00:13 -0700 (PDT) Subject: SMTP connection + lost while reading message data (header) In-Reply-To: Message-ID: <1378443613.38670.YahooMailIosMobile@web140701.mail.bf1.yahoo.com> William

Thanks for advice i will adjust and get update the status

Sent from Yahoo! Mail for iPhone From eugen at leitl.org Fri Sep 6 09:37:53 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 6 Sep 2013 11:37:53 +0200 Subject: The US government has betrayed the Internet. We need to take it back Message-ID: <20130906093753.GF29404@leitl.org> http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying The US government has betrayed the Internet. We need to take it back The NSA has undermined a fundamental social contract. We engineers built the Internet ? and now we have to fix it Bruce Schneier The Guardian, Thursday 5 September 2013 20.04 BST Internet business cables in California. 'Dismantling the surveillance state won't be easy. But whatever happens, we're going to be breaking new ground.' Photograph: Bob Sacha/Corbis Government and industry have betrayed the Internet, and us. By subverting the Internet at every level to make it a vast, multi-layered and robust surveillance platform, the NSA has undermined a fundamental social contract. The companies that build and manage our Internet infrastructure, the companies that create and sell us our hardware and software, or the companies that host our data: we can no longer trust them to be ethical Internet stewards. This is not the Internet the world needs, or the Internet its creators envisioned. We need to take it back. And by we, I mean the engineering community. Yes, this is primarily a political problem, a policy matter that requires political intervention. But this is also an engineering problem, and there are several things engineers can ? and should ? do. One, we should expose. If you do not have a security clearance, and if you have not received a National Security Letter, you are not bound by a federal confidentially requirements or a gag order. If you have been contacted by the NSA to subvert a product or protocol, you need to come forward with your story. Your employer obligations don't cover illegal or unethical activity. If you work with classified data and are truly brave, expose what you know. We need whistleblowers. We need to know how exactly how the NSA and other agencies are subverting routers, switches, the Internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do. Two, we can design. We need to figure out how to re-engineer the Internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information. We can make surveillance expensive again. In particular, we need open protocols, open implementations, open systems ? these will be harder for the NSA to subvert. The Internet Engineering Task Force, the group that defines the standards that make the Internet run, has a meeting planned for early November in Vancouver. This group needs to dedicate its next meeting to this task. This is an emergency, and demands an emergency response. Three, we can influence governance. I have resisted saying this up to now, and I am saddened to say it, but the US has proved to be an unethical steward of the Internet. The UK is no better. The NSA's actions are legitimizing the Internet abuses by China, Russia, Iran and others. We need to figure out new means of Internet governance, ones that makes it harder for powerful tech countries to monitor everything. For example, we need to demand transparency, oversight, and accountability from our governments and corporations. Unfortunately, this is going play directly into the hands of totalitarian governments that want to control their country's Internet for even more extreme forms of surveillance. We need to figure out how to prevent that, too. We need to avoid the mistakes of the International Telecommunications Union, which has become a forum to legitimize bad government behavior, and create truly international governance that can't be dominated or abused by any one country. Generations from now, when people look back on these early decades of the Internet, I hope they will not be disappointed in us. We can ensure that they don't only if each of us makes this a priority, and engages in the debate. We have a moral duty to do this, and we have no time to lose. Dismantling the surveillance state won't be easy. Has any country that engaged in mass surveillance of its own citizens voluntarily given up that capability? Has any mass surveillance country avoided becoming totalitarian? Whatever happens, we're going to be breaking new ground. Again, the politics of this is a bigger task than the engineering, but the engineering is critical. We need to demand that real technologists be involved in any key government decision making on these issues. We've had enough of lawyers and politicians not fully understanding technology; we need technologists at the table when we build tech policy. To the engineers, I say this: we built the Internet, and some of us have helped to subvert it. Now, those of us who love liberty have to fix it. ? Bruce Schneier writes about security, technology, and people. His latest book is Liars and Outliers: Enabling the Trust That Society Needs to Thrive. He is working for the Guardian on other NSA stories From rdobbins at arbor.net Fri Sep 6 09:57:25 2013 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 6 Sep 2013 19:57:25 +1000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906093753.GF29404@leitl.org> References: <20130906093753.GF29404@leitl.org> Message-ID: <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Eugen Leitl wrote: >We engineers built the Internet ? and now we have to fix it Nonsense. This is not a technical issue, it's a socio-political issue. It?s both naive & distracting to try & solve this set of problems with code and/or silicon, when it must in fact be addressed within the civic arena. There are no purely technical solutions to social ills. Schneier of all people should know this. --------------------------------------- Roland Dobbins From randy at psg.com Fri Sep 6 10:18:38 2013 From: randy at psg.com (Randy Bush) Date: Fri, 06 Sep 2013 19:18:38 +0900 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> References: <20130906093753.GF29404@leitl.org> <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Message-ID: >> We engineers built the Internet ? and now we have to fix it > There are no purely technical solutions to social ills. no. there are many issues in many arenas. but we are responsible for cleaning up our side of the street. randy From sam at circlenet.us Fri Sep 6 10:18:27 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 06:18:27 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> References: <20130906093753.GF29404@leitl.org> <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Message-ID: I believe you are correct, whatever technical hurdles we put in place will be overcome by policy. As long as you can legally require me to make my network intercept able for "lawful" purposes and are able to prevent me from explaining these purposes to my users any security that I would put in place is effectively neutered. I give up trying to resist, I am now firmly in the tin foil hat club. Sam On 2013-09-06 05:57, Roland Dobbins wrote: > Eugen Leitl wrote: > >>We engineers built the Internet ? and now we have to fix it > > Nonsense. This is not a technical issue, it's a socio-political > issue. It?s both naive & distracting to try & solve this set of > problems with code and/or silicon, when it must in fact be addressed > within the civic arena. > > There are no purely technical solutions to social ills. Schneier of > all people should know this. > > > --------------------------------------- > Roland Dobbins From contact at nullivex.com Fri Sep 6 10:23:06 2013 From: contact at nullivex.com (Bryan Tong) Date: Fri, 6 Sep 2013 04:23:06 -0600 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Message-ID: That and ignoring it will only continue to affect the code/silicon arena. Social problems are always affected by who throws the biggest fit. On Fri, Sep 6, 2013 at 4:18 AM, Randy Bush wrote: > >> We engineers built the Internet ? and now we have to fix it > > There are no purely technical solutions to social ills. > > no. there are many issues in many arenas. but we are responsible for > cleaning up our side of the street. > > randy > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From wbailey at satelliteintelligencegroup.com Fri Sep 6 10:24:26 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Sep 2013 10:24:26 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: Message-ID: Who's going to pay for the cleanup? The same people who are/were paid to create the mess? Clearly many of the "tin foil hat" theories are now becoming common place. I really don't know if there is any way out of this stateside, it's legislated. On 9/6/13 3:18 AM, "Randy Bush" wrote: >>> We engineers built the Internet ? and now we have to fix it >> There are no purely technical solutions to social ills. > >no. there are many issues in many arenas. but we are responsible for >cleaning up our side of the street. > >randy > From LarrySheldon at cox.net Fri Sep 6 10:29:17 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 06 Sep 2013 05:29:17 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Message-ID: <5229AE7D.3000908@cox.net> On 9/6/2013 5:23 AM, Bryan Tong wrote: > That and ignoring it will only continue to affect the code/silicon arena. > Social problems are always affected by who throws the biggest fit. > > > On Fri, Sep 6, 2013 at 4:18 AM, Randy Bush wrote: > >>>> We engineers built the Internet ? and now we have to fix it >>> There are no purely technical solutions to social ills. >> >> no. there are many issues in many arenas. but we are responsible for >> cleaning up our side of the street. We need to think bigger than "whatever it takes to get along to the end of the quarter....: -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jsqnanog at quarterman.com Fri Sep 6 10:47:26 2013 From: jsqnanog at quarterman.com (John S. Quarterman) Date: Fri, 06 Sep 2013 06:47:26 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: Your message of "Fri, 06 Sep 2013 06:18:27 EDT." Message-ID: <1378464447.420887.5071@rudra.quarterman.com> > On 2013-09-06 05:57, Roland Dobbins wrote: > > There are no purely technical solutions to social ills. Schneier of > > all people should know this. Schneier does know this, and explicitly said this. -jsq http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying Three, we can influence governance. I have resisted saying this up to now, and I am saddened to say it, but the US has proved to be an unethical steward of the internet. The UK is no better. The NSA's actions are legitimizing the internet abuses by China, Russia, Iran and others. We need to figure out new means of internet governance, ones that makes it harder for powerful tech countries to monitor everything. For example, we need to demand transparency, oversight, and accountability from our governments and corporations. Unfortunately, this is going play directly into the hands of totalitarian governments that want to control their country's internet for even more extreme forms of surveillance. We need to figure out how to prevent that, too. We need to avoid the mistakes of the International Telecommunications Union, which has become a forum to legitimize bad government behavior, and create truly international governance that can't be dominated or abused by any one country. Generations from now, when people look back on these early decades of the internet, I hope they will not be disappointed in us. We can ensure that they don't only if each of us makes this a priority, and engages in the debate. We have a moral duty to do this, and we have no time to lose. Dismantling the surveillance state won't be easy. Has any country that engaged in mass surveillance of its own citizens voluntarily given up that capability? Has any mass surveillance country avoided becoming totalitarian? Whatever happens, we're going to be breaking new ground. Again, the politics of this is a bigger task than the engineering, but the engineering is critical. We need to demand that real technologists be involved in any key government decision making on these issues. We've had enough of lawyers and politicians not fully understanding technology; we need technologists at the table when we build tech policy. To the engineers, I say this: we built the internet, and some of us have helped to subvert it. Now, those of us who love liberty have to fix it. From sam at circlenet.us Fri Sep 6 10:53:35 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 06:53:35 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <1378464447.420887.5071@rudra.quarterman.com> References: <1378464447.420887.5071@rudra.quarterman.com> Message-ID: True I shot from the hip, he does address the concerns later. I'm used to implementing technologies to solve security problems. It's just damn frustrating to have your hands tied in such a way that you can not and that's the position that I see myself and most other network ops in. Our customers decided at the ballot box that they didn't want protection and it was acceptable to entrust their privacy to the system. They seem to forget that decision when they ask if they are vulnerable to this type of intercept and what they can do about it. The answer is not much because I will not and can not break the law, it's unethical and wrong. I will encourage people to seek to change the laws to encourage true end to end security but the odds of that happening are near 0. Sam On 2013-09-06 06:47, John S. Quarterman wrote: >> On 2013-09-06 05:57, Roland Dobbins wrote: > >> > There are no purely technical solutions to social ills. Schneier >> of >> > all people should know this. > > Schneier does know this, and explicitly said this. > > -jsq > > > > http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying > > Three, we can influence governance. I have resisted saying this up to > now, > and I am saddened to say it, but the US has proved to be an unethical > steward of the internet. The UK is no better. The NSA's actions are > legitimizing the internet abuses by China, Russia, Iran and others. > We > need to figure out new means of internet governance, ones that makes > it > harder for powerful tech countries to monitor everything. For > example, > we need to demand transparency, oversight, and accountability from > our > governments and corporations. > > Unfortunately, this is going play directly into the hands of > totalitarian > governments that want to control their country's internet for even > more > extreme forms of surveillance. We need to figure out how to prevent > that, > too. We need to avoid the mistakes of the International > Telecommunications > Union, which has become a forum to legitimize bad government > behavior, > and create truly international governance that can't be dominated or > abused by any one country. > > Generations from now, when people look back on these early decades of > the internet, I hope they will not be disappointed in us. We can > ensure > that they don't only if each of us makes this a priority, and engages > in > the debate. We have a moral duty to do this, and we have no time to > lose. > > Dismantling the surveillance state won't be easy. Has any country > that > engaged in mass surveillance of its own citizens voluntarily given up > that capability? Has any mass surveillance country avoided becoming > totalitarian? Whatever happens, we're going to be breaking new > ground. > > Again, the politics of this is a bigger task than the engineering, > but > the engineering is critical. We need to demand that real > technologists > be involved in any key government decision making on these issues. > We've > had enough of lawyers and politicians not fully understanding > technology; > we need technologists at the table when we build tech policy. > > To the engineers, I say this: we built the internet, and some of us > have > helped to subvert it. Now, those of us who love liberty have to fix > it. From jsqnanog at quarterman.com Fri Sep 6 12:03:32 2013 From: jsqnanog at quarterman.com (John S. Quarterman) Date: Fri, 06 Sep 2013 08:03:32 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: Your message of "Fri, 06 Sep 2013 06:53:35 EDT." Message-ID: <1378469013.141845.6741@rudra.quarterman.com> > True I shot from the hip, he does address the concerns later. It happens. > I'm used > to implementing technologies to solve security problems. It's just damn > frustrating to have your hands tied in such a way that you can not and > that's the position that I see myself and most other network ops in. Maybe NSA has provided a marketing opportunity to get the public to demand real security. > Our customers decided at the ballot box that they didn't want > protection and it was acceptable to entrust their privacy to the system. > They seem to forget that decision when they ask if they are vulnerable > to this type of intercept and what they can do about it. The answer is > not much because I will not and can not break the law, it's unethical > and wrong. I will encourage people to seek to change the laws to > encourage true end to end security but the odds of that happening are > near 0. If everybody refuses to try, the odds are indeed zero. So maybe we should try. > Sam -jsq > On 2013-09-06 06:47, John S. Quarterman wrote: > >> On 2013-09-06 05:57, Roland Dobbins wrote: > > > >> > There are no purely technical solutions to social ills. Schneier > >> of > >> > all people should know this. > > > > Schneier does know this, and explicitly said this. > > > > -jsq > > > > > > > > http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-in > ternet-nsa-spying > > > > Three, we can influence governance. I have resisted saying this up to > > now, > > and I am saddened to say it, but the US has proved to be an unethical > > steward of the internet. The UK is no better. The NSA's actions are > > legitimizing the internet abuses by China, Russia, Iran and others. > > We > > need to figure out new means of internet governance, ones that makes > > it > > harder for powerful tech countries to monitor everything. For > > example, > > we need to demand transparency, oversight, and accountability from > > our > > governments and corporations. > > > > Unfortunately, this is going play directly into the hands of > > totalitarian > > governments that want to control their country's internet for even > > more > > extreme forms of surveillance. We need to figure out how to prevent > > that, > > too. We need to avoid the mistakes of the International > > Telecommunications > > Union, which has become a forum to legitimize bad government > > behavior, > > and create truly international governance that can't be dominated or > > abused by any one country. > > > > Generations from now, when people look back on these early decades of > > the internet, I hope they will not be disappointed in us. We can > > ensure > > that they don't only if each of us makes this a priority, and engages > > in > > the debate. We have a moral duty to do this, and we have no time to > > lose. > > > > Dismantling the surveillance state won't be easy. Has any country > > that > > engaged in mass surveillance of its own citizens voluntarily given up > > that capability? Has any mass surveillance country avoided becoming > > totalitarian? Whatever happens, we're going to be breaking new > > ground. > > > > Again, the politics of this is a bigger task than the engineering, > > but > > the engineering is critical. We need to demand that real > > technologists > > be involved in any key government decision making on these issues. > > We've > > had enough of lawyers and politicians not fully understanding > > technology; > > we need technologists at the table when we build tech policy. > > > > To the engineers, I say this: we built the internet, and some of us > > have > > helped to subvert it. Now, those of us who love liberty have to fix > > it. From jmamodio at gmail.com Fri Sep 6 12:46:59 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Sep 2013 07:46:59 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906093753.GF29404@leitl.org> References: <20130906093753.GF29404@leitl.org> Message-ID: http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying > > The US government has betrayed the Internet. We need to take it back > Who is we ? -J From john-nanog at johnpeach.com Fri Sep 6 13:08:31 2013 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 06 Sep 2013 09:08:31 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> Message-ID: <20130906090831.42a9e5dd@hulk> On Fri, 6 Sep 2013 07:46:59 -0500 Jorge Amodio wrote: > http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying > > > > The US government has betrayed the Internet. We need to take it back > > > > Who is we ? If you bothered to read the 1st paragraph you would know. > > -J -- John PGP Public Key: 412934AC From alex at corp.nac.net Fri Sep 6 13:20:07 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 6 Sep 2013 09:20:07 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <1b8b18f2-babd-407c-9a46-ad61a6c566d6@email.android.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8289EB4B521@EXCHMBX.hq.nac.net> > From: Sam Moats [mailto:sam at circlenet.us] > > I give up trying to resist, I am now firmly in the tin foil hat club. And therein lies the problem. From Joshua_Sholes at cable.comcast.com Fri Sep 6 13:29:58 2013 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Fri, 6 Sep 2013 13:29:58 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: Message-ID: >The answer is >not much because I will not and can not break the law, it's unethical >and wrong. I invite you to consider the concept of civil disobedience--where the law is unethical or wrong it can be argued that it's also unethical and wrong to FOLLOW the law. I haven't yet been placed in a position, and I doubt I will given the arc of my career, where I would have to make the choice between enabling this kind of surveillance quietly or blowing the whistle on it. I hope, as I imagine most of us do, that I'd choose to do the "right" thing (and correctly determine which option is "right", which is probably the real trick). -- Josh Sholes From oscar.vives at gmail.com Fri Sep 6 13:32:15 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Fri, 6 Sep 2013 15:32:15 +0200 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906093753.GF29404@leitl.org> References: <20130906093753.GF29404@leitl.org> Message-ID: On 6 September 2013 11:37, Eugen Leitl wrote: > > http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying > > The US government has betrayed the Internet. We need to take it back > Its like you have to abandon USA based encryptation systems that are closed source. But I dunno, maybe open source solutions can have problems. http://xkcd.com/221/ http://en.wikinews.org/wiki/Predictable_random_number_generator_discovered_in_the_Debian_version_of_OpenSSL I think the encryptation world will think about this, and will recommend a group of products (like PGP) that are almost sure safe. The NSA can spy on underwater internet cables, but they can't abolish Math. If you have a encryptation system that is not backdoored and is cryptographically strong enough the NSA or anyone will have a hard time to uncover your secrets. -- -- ?in del ?ensaje. From jmamodio at gmail.com Fri Sep 6 13:50:34 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Sep 2013 08:50:34 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906090831.42a9e5dd@hulk> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: > > The US government has betrayed the Internet. We need to take it back > > > > > > > Who is we ? > > If you bothered to read the 1st paragraph you would know. > I read all of it, the original article and other references to it. IMHO, there is no amount of engineering that can fix stupid people doing stupid things on both sides of the stupid lines. By trying to fix what is perceived an engineering issue (seems that China doing the same or worse for many years wasn't an engineering problem) the only result you will obtain is a budget increase on the counter-engineering efforts, that may represent a big chunk of money that can be used in more effective ways where it is really needed. My .02 -J From sakamura at gmail.com Fri Sep 6 14:14:59 2013 From: sakamura at gmail.com (Ishmael Rufus) Date: Fri, 6 Sep 2013 09:14:59 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: So when do we riot? I've been waiting for months now. On Fri, Sep 6, 2013 at 8:50 AM, Jorge Amodio wrote: > > > The US government has betrayed the Internet. We need to take it back > > > > > > > > > > > Who is we ? > > > > If you bothered to read the 1st paragraph you would know. > > > > I read all of it, the original article and other references to it. > > IMHO, there is no amount of engineering that can fix stupid people doing > stupid things on both sides of the stupid lines. > > By trying to fix what is perceived an engineering issue (seems that China > doing the same or worse for many years wasn't an engineering problem) the > only result you will obtain is a budget increase on the counter-engineering > efforts, that may represent a big chunk of money that can be used in more > effective ways where it is really needed. > > My .02 > -J > From sam at circlenet.us Fri Sep 6 14:23:11 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 10:23:11 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: I don't suggest a riot. I do believe in the rule of law, as a member of a democracy I need to accept that I will not always agree with the laws that are enacted. If we lived in China or somewhere else where there was no method to change laws that were unfair or unjust then yea I would support the civil disobiedence approach whole heartedly I do love my country, always have and I firmly believe in the concept of government by the consent of the governed. These rules were made by the people we choose, perhaps these were bad choices but they were are collective choices. Perhaps we should educate our user base so that in the future they make better choices. I suggest in an only half snarky way we just push out the standard DOD warning banner to them all. Since it now seems to apply... Below is a sample banner (IS is information System) By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. Sam On 2013-09-06 10:14, Ishmael Rufus wrote: > So when do we riot? I've been waiting for months now. > > > On Fri, Sep 6, 2013 at 8:50 AM, Jorge Amodio > wrote: > >> > > The US government has betrayed the Internet. We need to take it >> back >> >> > > > >> > > >> > > Who is we ? >> > >> > If you bothered to read the 1st paragraph you would know. >> > >> >> I read all of it, the original article and other references to it. >> >> IMHO, there is no amount of engineering that can fix stupid people >> doing >> stupid things on both sides of the stupid lines. >> >> By trying to fix what is perceived an engineering issue (seems that >> China >> doing the same or worse for many years wasn't an engineering >> problem) the >> only result you will obtain is a budget increase on the >> counter-engineering >> efforts, that may represent a big chunk of money that can be used in >> more >> effective ways where it is really needed. >> >> My .02 >> -J >> From SNaslund at medline.com Fri Sep 6 14:27:32 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 6 Sep 2013 14:27:32 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> The error in this whole conversation is that you cannot "take it back" as an engineer. You do not own it. You are like an architect or carpenter and are no more responsible for how it is used than the architect is responsible that the building he designed is being used as a crack house. Do Ford engineers have a "social contract" to ensure that I do not run over squirrels with my Explorer, will they "take it back" if I do so? The whole "social contract" argument is ridiculous. You have a contract (or most likely an "at will" agreement") with your employer to build what they want and operate it in the way that they want you to. If it is against your ethics to do so, quit. The companies that own the network have a fiduciary responsibility to their investors and a responsibility to serve their customers. If anyone is really that bent out of shape by the NSA tactics (and I am not so sure they are given the lack of political backlash) here is what you can do. In the United States there are two main centers of power that can affect these policies, the consumer and the voter. 1. We vote in a new executive branch every four years. They control and appoint the NSA director. Vote them out if you don't like how they run things. Do you think a President wants to maintain power? Of course they do and they will change a policy that will get them tossed out (if enough people actually care). 2. The Congress passes the laws that govern telecom and intelligence gathering. They also have the power to impeach and/or prosecute the executive branch for misdeeds. They will pass any law or do whatever it takes to keep themselves in power. Again this requires a lot of public pressure. 3. The companies that are consenting to monitoring (legal or illegal) are stuck between two powers. The federal government's power to regulate them and the investors / consumers they serve. Apparently they are more scared of the government even though the consumer can put them out of business overnight by simply not using their product any more. If everyone cancelled their gmail accounts, stopped using Google search, and stopped paying for Google placement and ads, their stock would go to zero nearly overnight. Again, no one seems to care about the issue enough to do this because I have seen no appreciable backlash against these companies. If a social contract exists at all in the United States, it would be to hold your government and the companies you do business with to your ethical standards. Another things to remember is that the NSA engineers were probably acting under their "social contract" to defend the United States from whatever enemies they are trying to monitor and also felt they were doing the "right thing". The problem with "social contracts" is that they are relative. As far as other countries are concerned, you can affect their policies as well. US carriers are peered with and provide transit to Chinese companies. If the whole world is that outraged with what they do, they just need to pressure the companies they do business with not to do business with China. Steven Naslund Chicago IL -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Friday, September 06, 2013 8:51 AM To: NANOG Subject: Re: The US government has betrayed the Internet. We need to take it back > > The US government has betrayed the Internet. We need to take it back > > > > > > > Who is we ? > > If you bothered to read the 1st paragraph you would know. > I read all of it, the original article and other references to it. IMHO, there is no amount of engineering that can fix stupid people doing stupid things on both sides of the stupid lines. By trying to fix what is perceived an engineering issue (seems that China doing the same or worse for many years wasn't an engineering problem) the only result you will obtain is a budget increase on the counter-engineering efforts, that may represent a big chunk of money that can be used in more effective ways where it is really needed. My .02 -J From Valdis.Kletnieks at vt.edu Fri Sep 6 14:25:14 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Sep 2013 10:25:14 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: Your message of "Fri, 06 Sep 2013 10:24:26 -0000." References: Message-ID: <56705.1378477514@turing-police.cc.vt.edu> On Fri, 06 Sep 2013 10:24:26 -0000, Warren Bailey said: > Who's going to pay for the cleanup? The same people who are/were paid to > create the mess? Clearly many of the "tin foil hat" theories are now > becoming common place. I really don't know if there is any way out of this > stateside, it's legislated. There's no legislation that says you're not allowed to enable OpenSSL perfect forward secrecy on your website, and fix the layout so HTTPS Everywhere is able to work on it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From sam at circlenet.us Fri Sep 6 14:30:31 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 10:30:31 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: <6f6579b06623c318cfe2e415c57b0771@www.circlenet.us> +1 I couldn't have said it any better. Sam On 2013-09-06 10:27, Naslund, Steve wrote: > The error in this whole conversation is that you cannot "take it > back" as an engineer. You do not own it. You are like an architect > or carpenter and are no more responsible for how it is used than the > architect is responsible that the building he designed is being used > as a crack house. Do Ford engineers have a "social contract" to > ensure that I do not run over squirrels with my Explorer, will they > "take it back" if I do so? The whole "social contract" argument is > ridiculous. You have a contract (or most likely an "at will" > agreement") with your employer to build what they want and operate it > in the way that they want you to. If it is against your ethics to do > so, quit. The companies that own the network have a fiduciary > responsibility to their investors and a responsibility to serve their > customers. If anyone is really that bent out of shape by the NSA > tactics (and I am not so sure they are given the lack of political > backlash) here is what you can do. > > In the United States there are two main centers of power that can > affect these policies, the consumer and the voter. > > 1. We vote in a new executive branch every four years. They control > and appoint the NSA director. Vote them out if you don't like how > they run things. Do you think a President wants to maintain power? > Of course they do and they will change a policy that will get them > tossed out (if enough people actually care). > > 2. The Congress passes the laws that govern telecom and intelligence > gathering. They also have the power to impeach and/or prosecute the > executive branch for misdeeds. They will pass any law or do whatever > it takes to keep themselves in power. Again this requires a lot of > public pressure. > > 3. The companies that are consenting to monitoring (legal or > illegal) are stuck between two powers. The federal government's > power > to regulate them and the investors / consumers they serve. > Apparently > they are more scared of the government even though the consumer can > put them out of business overnight by simply not using their product > any more. If everyone cancelled their gmail accounts, stopped using > Google search, and stopped paying for Google placement and ads, their > stock would go to zero nearly overnight. Again, no one seems to care > about the issue enough to do this because I have seen no appreciable > backlash against these companies. > > If a social contract exists at all in the United States, it would be > to hold your government and the companies you do business with to > your > ethical standards. Another things to remember is that the NSA > engineers were probably acting under their "social contract" to > defend > the United States from whatever enemies they are trying to monitor > and > also felt they were doing the "right thing". The problem with > "social > contracts" is that they are relative. > > As far as other countries are concerned, you can affect their > policies as well. US carriers are peered with and provide transit to > Chinese companies. If the whole world is that outraged with what > they > do, they just need to pressure the companies they do business with > not > to do business with China. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Friday, September 06, 2013 8:51 AM > To: NANOG > Subject: Re: The US government has betrayed the Internet. We need to > take it back > >> > The US government has betrayed the Internet. We need to take it >> back > >> > > >> > >> > Who is we ? >> >> If you bothered to read the 1st paragraph you would know. >> > > I read all of it, the original article and other references to it. > > IMHO, there is no amount of engineering that can fix stupid people > doing stupid things on both sides of the stupid lines. > > By trying to fix what is perceived an engineering issue (seems that > China doing the same or worse for many years wasn't an engineering > problem) the only result you will obtain is a budget increase on the > counter-engineering efforts, that may represent a big chunk of money > that can be used in more effective ways where it is really needed. > > My .02 > -J From jgreco at ns.sol.net Fri Sep 6 14:23:02 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 6 Sep 2013 09:23:02 -0500 (CDT) Subject: The US government has betrayed the Internet. We need to take it In-Reply-To: Message-ID: <201309061423.r86EN2KE097594@aurora.sol.net> > I don't suggest a riot. I do believe in the rule of law, as a member of > a democracy > I need to accept that I will not always agree with the laws that are > enacted. Well that's all nice and all, but what you're missing here is that this has very little to do with "laws that are enacted". When an author of the PATRIOT Act is filing amicus briefs indicating that the collection of data being done is not what Congress intended, and when the intelligence community is busy subverting the common definitions of words so that they can bend a law that says one thing when read in plain language but something very different when they use their own private definitions, then we're pretty far outside the scope of "law." We've been hearing for some years now that the way in which the PATRIOT Act has been interpreted was alarmingly expansive. If you choose to start redefining words, you can probably find a way to make the Constitution say "every child has a right to a puppy." Doesn't actually mean that it actually says that though. Feingold must be having such an "I told you so" moment. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From royce at techsolvency.com Fri Sep 6 14:55:39 2013 From: royce at techsolvency.com (Royce Williams) Date: Fri, 6 Sep 2013 06:55:39 -0800 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Sep 6, 2013 at 6:27 AM, Naslund, Steve wrote: [snip] > 1. We vote in a new executive branch every four years. They control and appoint the NSA director. Vote them out if you don't like how they run things. Do you think a President wants to maintain power? Of course they do and they will change a policy that will get them tossed out (if enough people actually care). > > 2. The Congress passes the laws that govern telecom and intelligence gathering. They also have the power to impeach and/or prosecute the executive branch for misdeeds. They will pass any law or do whatever it takes to keep themselves in power. Again this requires a lot of public pressure. Historically speaking, I'm not convinced that a pure political solution will ever work, other than on the surface. The need for surveillance transcends both administrations and political parties. Once the newly elected are presented with the intel available at that level, even their approach to handling the flow of information and their social interaction have to change in order to function. Daniel Ellsberg's attempt to explain this to Kissinger is insightful. It's a pretty quick read, with many layers of important observations. (It's Mother Jones, but this content is apolitical): http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge I think that Schneier's got it right. The solution has to be both technical and political, and must optimize for two functions: catch the bad guys, while protecting the rights of the good guys. When the time comes for the political choices to be made, the good technical choices must be the only ones available. Security engineering must pave the way to the high road -- so that it's the only road to get there. Royce From sam at circlenet.us Fri Sep 6 15:04:58 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 11:04:58 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: <09428536190357281104c4b05d29f720@www.circlenet.us> This is part of the purpose behind the separation of powers between executive, legislative and judicial. William Pitt wrote "Unlimited power is apt to corrupt the minds of those who possess it" . As such constraints are needed and in place. We expect politician to cheat,lie,be stupid and self serving. Because we like people who tell us what we want to hear and most of us vote for people that we like. The do not have to be wise, or even competent. Personally I think most of the fault currently lies with the Judicial side. These laws were enacted as a knee jerk reaction to an event. I can understand the passions of people at that time because I shared them, however the courts are supposed to be a bulwark against this very kind of rash action. These men and women are supposed to be well educated in the fundamental concepts that constructed our republic and appointed to terms that prevent them from worrying about the political whims of the time. Sam On 2013-09-06 10:55, Royce Williams wrote: > On Fri, Sep 6, 2013 at 6:27 AM, Naslund, Steve > wrote: > > [snip] > >> 1. We vote in a new executive branch every four years. They >> control and > appoint the NSA director. Vote them out if you don't like how they > run > things. Do you think a President wants to maintain power? Of course > they > do and they will change a policy that will get them tossed out (if > enough > people actually care). >> >> 2. The Congress passes the laws that govern telecom and >> intelligence > gathering. They also have the power to impeach and/or prosecute the > executive branch for misdeeds. They will pass any law or do whatever > it > takes to keep themselves in power. Again this requires a lot of > public > pressure. > > Historically speaking, I'm not convinced that a pure political > solution > will ever work, other than on the surface. The need for surveillance > transcends both administrations and political parties. Once the > newly > elected are presented with the intel available at that level, even > their > approach to handling the flow of information and their social > interaction > have to change in order to function. > > Daniel Ellsberg's attempt to explain this to Kissinger is insightful. > It's > a pretty quick read, with many layers of important observations. > (It's > Mother Jones, but this content is apolitical): > > > > http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge > > I think that Schneier's got it right. The solution has to be both > technical and political, and must optimize for two functions: catch > the bad > guys, while protecting the rights of the good guys. > > When the time comes for the political choices to be made, the good > technical choices must be the only ones available. > > Security engineering must pave the way to the high road -- so that > it's the > only road to get there. > > Royce From nazgul at somewhere.com Fri Sep 6 15:21:30 2013 From: nazgul at somewhere.com (Kee Hinckley) Date: Fri, 6 Sep 2013 11:21:30 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> Message-ID: <421D26A2-577E-4538-BC1B-AC4D7EF9D62F@somewhere.com> On Sep 5, 2013, at 8:26 PM, Jay Ashworth wrote: > They're just validating a credit card number; that was an authorization which won't be settled, almost certainly. I'd have more faith in that if a) there weren't three of them and b) they didn't then tell me that my credit card information was invalid. My guess is that their system failed somewhere between posting the charge and clearing it. However, they *are* still in the Pending category on my card, we'll see if they get posted. From nazgul at marrowbones.com Fri Sep 6 15:22:37 2013 From: nazgul at marrowbones.com (Kee Hinckley) Date: Fri, 6 Sep 2013 11:22:37 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> Message-ID: <41A2C20C-F7AB-4A7D-8B04-4A78BA92C610@marrowbones.com> On Sep 5, 2013, at 8:26 PM, Jay Ashworth wrote: > They're just validating a credit card number; that was an authorization which won't be settled, almost certainly. I'd have more faith in that if a) there weren't three of them and b) they didn't then tell me that my credit card information was invalid. My guess is that their system failed somewhere between posting the charge and clearing it. However, they *are* still in the Pending category on my card, we'll see if they get posted. From jra at baylink.com Fri Sep 6 15:27:39 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 06 Sep 2013 11:27:39 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <421D26A2-577E-4538-BC1B-AC4D7EF9D62F@somewhere.com> References: <12002734.6139.1378264199253.JavaMail.root@benjamin.baylink.com> <5226AD5C.8030407@alter3d.ca> <28D6EA53-B8CF-42B6-8DC1-5E055C371D14@ufp.org> <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> <48369127-ce30-4f8c-aa98-a97058b8e40f@email.android.com> <421D26A2-577E-4538-BC1B-AC4D7EF9D62F@somewhere.com> Message-ID: Sure. But the failure is /why/ you have three... -jra Kee Hinckley wrote: > >On Sep 5, 2013, at 8:26 PM, Jay Ashworth wrote: > >> They're just validating a credit card number; that was an >authorization which won't be settled, almost certainly. > >I'd have more faith in that if a) there weren't three of them and b) >they didn't then tell me that my credit card information was invalid. >My guess is that their system failed somewhere between posting the >charge and clearing it. However, they *are* still in the Pending >category on my card, we'll see if they get posted. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jmamodio at gmail.com Fri Sep 6 15:43:22 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Sep 2013 10:43:22 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: We have to do the right thing anyway because as engineers we are always motivated to innovate, to fix, to make things better. Motivation has not to come form the NSA or any other spooking service of the day. Even if we design and deploy the best engineering solution there is always a weak link that can be compromised, coerced by law or workaround by counter-engineering. We want better was to provide "privacy" ? I'm not against that, but if you really want privacy the best and cheapest engineering solution is to remove the plug. We should spend more cycles about how to make broadband real broadband, deploying IPv6, implementing DNSSEC, educating people and bringing Internet where is no access or where there is bad access make it good, if in the process of doing that the NSA wants to get high sniffing all packets I really don't care much because that is not an engineering problem. I think that "privacy" on a "public" network is a very relative concept, same as "security". -J On Fri, Sep 6, 2013 at 9:11 AM, Scott Brim wrote: > On Fri, Sep 6, 2013 at 9:50 AM, Jorge Amodio wrote: > > IMHO, there is no amount of engineering that can fix stupid people doing > > stupid things on both sides of the stupid lines. > > Yes but there is engineering to ensure that they have the opportunity > to do the right thing in the first place. If we (IETF) naively > engineer out the ability to have privacy, it doesn't matter if those > people are stupid or not. > From SNaslund at medline.com Fri Sep 6 16:02:20 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 6 Sep 2013 16:02:20 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B43C296C16@MUNPRDMBXA1.medline.com> I am unclear on what you mean by technical choice. Are you talking about a technical solution to keep the government from seeing your traffic? That will not work for two main reasons. 1. The government has a lot more resources and motivation than the average company when it comes to security systems. They do not have to be profitable, just effective. Most companies only invest in the security that they are required to provide. As a private entity they will be unlikely to want to get in a technological arms race with the NSA. Remember these are the guys that also design some of the most sophisticated encryption systems in the world and have nearly limitless computing power to break such systems. They attract some of the most brilliant mathematical minds in the world and actively pursue these employees. You are really unlikely to out "security engineer" the NSA especially since the USG can control legally what technology you are allowed to use and export. Who designed your encryption algorithm and which one of your employees is a qualified cryptographer that can assure you that it is secure enough. Is he qualified to tell you what backdoors or capability NSA has to break that encryption method? Do you have the technical experts to assure you that no US intelligence service has penetrated your human or technical resources? Do you think no one in your organization would plug something into your network if it comes with a bag of cash or a threat attached to it. If so, I think the NSA might offer you a lucrative job. Remember these are the same guys who are supposed to break the communications of foreign governments and by all accounts are fairly good at it. I don't want to bet my job on defeating them. 2. If the political environment allows, they will simply pass laws along the lines of CALEA to give them the legal right to tap your traffic. Even if you won the technological battle they can instantly trump you with key escrow and other such legal force means to defeat you. If the political will exists they can pass a law requiring you to pass them all information in plain text. Game over, you lose. Just try to defy a FISA court order or refuse a CALEA tap and see how long you are in business. There is always a debate of privacy vs security and there always has been in one form or the other. This is expressed by the people of this country in their political and economic choices. I know it does not seem like it sometimes but the government will only do what the majority of the people will accept most of the time. Every decision a politician makes is a balance between what he wants and what he thinks he can get away with. He want the information but it is only useful if he maintains his access to power. As you see, the ONLY solution is the political will to limit the governments powers. The only way that is done is to threaten the power structure or financial structure. The history of the best technical solution winning inside the US Government structure is pretty weak. POSIX compliance, ADA programming, need I say more? I say this as a former network engineer in the United States Air Force. As far as both parties being responsible for this, I agree completely. Everyone knows that information is power and everyone wants as much information as they can get. The only way to influence that is to make the cost of illegal information collection too high a price to pay for the politicians. The NSA will only use the technology they are allowed to use by whomever is in power. No one over there wants to go to jail and most government employees do not want to put their neck on the line if they know there is no safety net. The Director of NSA answers to the President. His job is to get the information the USG wants and not get anyone fired doing it. Everything he does is about that balance. If he does not do it, the President will appoint someone who does. Historically the NSA is directed by a General officer from the military. They generally follow the orders they are given by the President and that is where the power really lies. It is the job of the Congress to oversee that and ensure the limitations are being followed. If that is not happening, it is up to the citizens to replace the President or Congress with someone who will follow the will of the people. Steve -----Original Message----- From: Royce Williams [mailto:royce at techsolvency.com] Sent: Friday, September 06, 2013 9:56 AM To: NANOG Subject: Re: The US government has betrayed the Internet. We need to take it back [snip] http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge I think that Schneier's got it right. The solution has to be both technical and political, and must optimize for two functions: catch the bad guys, while protecting the rights of the good guys. When the time comes for the political choices to be made, the good technical choices must be the only ones available. Security engineering must pave the way to the high road -- so that it's the only road to get there. Royce [snip] From royce at techsolvency.com Fri Sep 6 16:02:44 2013 From: royce at techsolvency.com (Royce Williams) Date: Fri, 6 Sep 2013 08:02:44 -0800 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Sep 6, 2013 at 6:55 AM, Royce Williams wrote: > Daniel Ellsberg's attempt to explain this to Kissinger is insightful. It's a pretty quick read, with many layers of important observations. (It's Mother Jones, but this content is apolitical): > > http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge Er ... I forgot to include the part of the Ellsberg quote that was most relevant to the discussion, with the last sentence here being the icing on the cake: "You will deal with a person who doesn't have those clearances only from the point of view of what you want him to believe and what impression you want him to go away with, since you'll have to lie carefully to him about what you know. In effect, you will have to manipulate him. You'll give up trying to assess what he has to say. The danger is, you'll become something like a moron. You'll become incapable of learning from most people in the world, no matter how much experience they may have in their particular areas that may be much greater than yours." In other words: the very politicians with the clearances necessary to strike the best balance are the ones that we cannot expect to hear us, even in our areas of expertise. Security engineering must take this fact as a constraint. Royce From jmamodio at gmail.com Fri Sep 6 16:05:08 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 6 Sep 2013 11:05:08 -0500 Subject: The US government has betrayed the Internet. We need to take it In-Reply-To: <201309061423.r86EN2KE097594@aurora.sol.net> References: <201309061423.r86EN2KE097594@aurora.sol.net> Message-ID: Just call your senator and ask her/him to stop signing the checks ... -J From harbor235 at gmail.com Fri Sep 6 16:25:38 2013 From: harbor235 at gmail.com (harbor235) Date: Fri, 6 Sep 2013 12:25:38 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: The biggest mistake everyone is making is that while we are talking about what the USGOV/NSA in this instance you assume this is the only entity behaving in this manner. Morpheus : "This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes. " Mike On Fri, Sep 6, 2013 at 11:43 AM, Jorge Amodio wrote: > We have to do the right thing anyway because as engineers we are always > motivated to innovate, to fix, to make things better. Motivation has not to > come form the NSA or any other spooking service of the day. Even if we > design and deploy the best engineering solution there is always a weak link > that can be compromised, coerced by law or workaround by > counter-engineering. > > We want better was to provide "privacy" ? I'm not against that, but if you > really want privacy the best and cheapest engineering solution is to remove > the plug. > > We should spend more cycles about how to make broadband real broadband, > deploying IPv6, implementing DNSSEC, educating people and bringing Internet > where is no access or where there is bad access make it good, if in the > process of doing that the NSA wants to get high sniffing all packets I > really don't care much because that is not an engineering problem. > > I think that "privacy" on a "public" network is a very relative concept, > same as "security". > > -J > > > > On Fri, Sep 6, 2013 at 9:11 AM, Scott Brim wrote: > > > On Fri, Sep 6, 2013 at 9:50 AM, Jorge Amodio wrote: > > > IMHO, there is no amount of engineering that can fix stupid people > doing > > > stupid things on both sides of the stupid lines. > > > > Yes but there is engineering to ensure that they have the opportunity > > to do the right thing in the first place. If we (IETF) naively > > engineer out the ability to have privacy, it doesn't matter if those > > people are stupid or not. > > > From scott.brim at gmail.com Fri Sep 6 14:11:07 2013 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 6 Sep 2013 10:11:07 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: On Fri, Sep 6, 2013 at 9:50 AM, Jorge Amodio wrote: > IMHO, there is no amount of engineering that can fix stupid people doing > stupid things on both sides of the stupid lines. Yes but there is engineering to ensure that they have the opportunity to do the right thing in the first place. If we (IETF) naively engineer out the ability to have privacy, it doesn't matter if those people are stupid or not. From nicolai-nanog at chocolatine.org Fri Sep 6 17:20:05 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Fri, 6 Sep 2013 12:20:05 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> Message-ID: <20130906172005.GA14944@vectra.student.iastate.edu> On Fri, Sep 06, 2013 at 02:27:32PM +0000, Naslund, Steve wrote: > If everyone cancelled their gmail accounts, stopped using Google search, > and stopped paying for Google placement and ads, their stock would go to > zero nearly overnight. Again, no one seems to care about the issue > enough to do this because I have seen no appreciable backlash against > these companies. I think Joe 6mbps sitting at home reads that everything he uses has been subverted. He doesn't know what alternatives exist, and doesn't have the technical knowledge neccessary to find them on his own. And faced with a false choice -- stop using the Internet, or continue using it as he knows how -- he chooses the one that retains his ability to communicate with family and friends and keep up on the things he cares about. Schneier is saying we need to build better options for Joe 6mbps, competing with the PRISM-compatable services, so that privacy-respecting services become known and commonplace. Nicolai From sam at circlenet.us Fri Sep 6 17:52:16 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 06 Sep 2013 13:52:16 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906172005.GA14944@vectra.student.iastate.edu> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> Message-ID: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> The problem being is when you do have a provider that appears to be secure and out of reach, think lavabit, that provider will not survive for long. The CALEA requirements, and Patriot Act provisions will force them into compliance. There only options are to: Disobey the law, unacceptable in my opinion Close down services, noble but I need to eat and you probably want to keep getting email Compromise your principles and obey the law, the path often choosen. Sam Moats On 2013-09-06 13:20, Nicolai wrote: > On Fri, Sep 06, 2013 at 02:27:32PM +0000, Naslund, Steve wrote: > >> If everyone cancelled their gmail accounts, stopped using Google >> search, >> and stopped paying for Google placement and ads, their stock would >> go to >> zero nearly overnight. Again, no one seems to care about the issue >> enough to do this because I have seen no appreciable backlash >> against >> these companies. > > I think Joe 6mbps sitting at home reads that everything he uses has > been > subverted. He doesn't know what alternatives exist, and doesn't have > the technical knowledge neccessary to find them on his own. And > faced > with a false choice -- stop using the Internet, or continue using it > as > he knows how -- he chooses the one that retains his ability to > communicate with family and friends and keep up on the things he > cares > about. > > Schneier is saying we need to build better options for Joe 6mbps, > competing with the PRISM-compatable services, so that > privacy-respecting > services become known and commonplace. > > Nicolai From royce at techsolvency.com Fri Sep 6 18:01:46 2013 From: royce at techsolvency.com (Royce Williams) Date: Fri, 6 Sep 2013 10:01:46 -0800 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <9578293AE169674F9A048B2BC9A081B43C296C16@MUNPRDMBXA1.medline.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B43C296C16@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Sep 6, 2013 at 8:02 AM, Naslund, Steve wrote: > I am unclear on what you mean by technical choice. Are you talking about a technical solution to keep the government from seeing your traffic? That will not work for two main reasons. [good reasons snipped] Ah, I should have been more clear. I'm definitely not proposing that the private sector could succeed in such an arms race, for exactly the two reasons that you accurately laid out: the government has vastly greater resources, and they have the law. (And I would add a third: they have a valid mission to accomplish). I intended the "technical choice" idea to be more broad. I'm no crypto guy, but of the work happening in this space, it seems that there are a lot of people working on the problem of "how do we keep everyone else out?", and a lot of other people are working on "how do we get in?" And recently, a lot more folks are working on "how can we quickly tell that they got in?" But it doesn't seem to me that very many people are working (at a technical level) on the hard problem of "how do we simultaneously enable lawful intercept, and verifiably preserve privacy?" There seems to be an intractable conflict between freedom and surveillance. But if we set aside that assumption, we might discover technical approaches to support both. The politics might change if the politicians didn't have to choose one or the other. Pipe dream? Certainly. But escaping assumptions is where breakthroughs are made. Royce From oscar.vives at gmail.com Fri Sep 6 18:04:09 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Fri, 6 Sep 2013 11:04:09 -0700 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> Message-ID: On 6 September 2013 10:52, Sam Moats wrote: > The problem being is when you do have a provider that appears to be secure > and out of reach, think lavabit, that provider will not survive for long. > The CALEA requirements, and Patriot Act provisions will force them into > compliance. Only if are on USA territory. You can also push for distributed services that don't depend on one fat server farm. -- -- ?in del ?ensaje. From mpetach at netflight.com Fri Sep 6 18:13:00 2013 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 6 Sep 2013 11:13:00 -0700 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> Message-ID: On Fri, Sep 6, 2013 at 7:23 AM, Sam Moats wrote: > ... > Below is a sample banner (IS is information System) > > By using this IS (which includes any device attached to this IS), you > consent to the following conditions: > > -The USG routinely intercepts and monitors communications on this IS for > purposes including, but not limited to, penetration testing, COMSEC > monitoring, network operations and defense, personnel misconduct (PM), law > enforcement (LE), and counterintelligence (CI) investigations. > > -At any time, the USG may inspect and seize data stored on this IS. > > -Communications using, or data stored on, this IS are not private, are > subject to routine monitoring, interception, and search, and may be > disclosed or used for any USG authorized purpose. > > -This IS includes security measures (e.g., authentication and access > controls) to protect USG interests--not for your personal benefit or > privacy. > > -Notwithstanding the above, using this IS does not constitute consent to > PM, LE or CI investigative searching or monitoring of the content of > privileged communications, or work product, related to personal > representation or services by attorneys, psychotherapists, or clergy, and > their assistants. Such communications and work product are private and > confidential. > > > Sam > Ah. So, if we all become ordained ministers, our communications become privileged communications not subject to monitoring by the US government? Matt (spoken mostly tongue-in-cheek; but it would be fun to see the government go up against the religious right on the question of whether the government has the right to violate the seal of the confessional and monitor layperson communications with their clergy...) From wbailey at satelliteintelligencegroup.com Fri Sep 6 18:04:13 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Sep 2013 18:04:13 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu>, <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> Message-ID: My dad told once me they could indict a ham sandwich. I never really knew what meant.. A law does not mean an automatic grant of constitutionality. I'm all for following laws, but at what point does the public just say.. The threat isn't large enough to warrant a protcologist visit via NSA to see if you've been a good boy. I'm innocent until proven guilty beyond a reasonably doubt by a jury of my peers, it doesn't work any other way. You either respect the document that establishes basic principals for this land, or you do not. As I said before.. Snowden would have had a world wife frenzy of activity had he included "facebook is going to a pay model" instead of legit information about national war crimes. Sent from my Mobile Device. -------- Original message -------- From: Sam Moats Date: 09/06/2013 10:56 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: The US government has betrayed the Internet. We need to take it back The problem being is when you do have a provider that appears to be secure and out of reach, think lavabit, that provider will not survive for long. The CALEA requirements, and Patriot Act provisions will force them into compliance. There only options are to: Disobey the law, unacceptable in my opinion Close down services, noble but I need to eat and you probably want to keep getting email Compromise your principles and obey the law, the path often choosen. Sam Moats On 2013-09-06 13:20, Nicolai wrote: > On Fri, Sep 06, 2013 at 02:27:32PM +0000, Naslund, Steve wrote: > >> If everyone cancelled their gmail accounts, stopped using Google >> search, >> and stopped paying for Google placement and ads, their stock would >> go to >> zero nearly overnight. Again, no one seems to care about the issue >> enough to do this because I have seen no appreciable backlash >> against >> these companies. > > I think Joe 6mbps sitting at home reads that everything he uses has > been > subverted. He doesn't know what alternatives exist, and doesn't have > the technical knowledge neccessary to find them on his own. And > faced > with a false choice -- stop using the Internet, or continue using it > as > he knows how -- he chooses the one that retains his ability to > communicate with family and friends and keep up on the things he > cares > about. > > Schneier is saying we need to build better options for Joe 6mbps, > competing with the PRISM-compatable services, so that > privacy-respecting > services become known and commonplace. > > Nicolai From jgreco at ns.sol.net Fri Sep 6 18:02:37 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 6 Sep 2013 13:02:37 -0500 (CDT) Subject: The US government has betrayed the Internet. We need to take it In-Reply-To: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> Message-ID: <201309061802.r86I2cic099952@aurora.sol.net> > The problem being is when you do have a provider that appears to be > secure > and out of reach, think lavabit, that provider will not survive for > long. > The CALEA requirements, and Patriot Act provisions will force them into > compliance. > There only options are to: > Disobey the law, unacceptable in my opinion > Close down services, noble but I need to eat and you probably want to > keep getting email > Compromise your principles and obey the law, the path often choosen. Actually it might not be so horrible if the law was rewritten to be more reasonable, and then on top of that if the executive branch would stop inventing new definitions for words used in the law. However, we shouldn't rely on either of those two things. But the other big giant fail here is that we, as the engineers who have built all this stuff, have made it exceedingly easy for users to "just sign up with Gmail" and have totally failed at providing easy alternatives for the average person to use. That includes building intelligent, secure, and easy-to-use security into MIME and email, and extends to policies by ISP's designed to make it difficult to run your own server/services, and winds up with software authors who totally fail at creating usable server implementations. And that's just a broad brush. There are more failings than that. Reducing or eliminating the third party involvement in operating services would severely impact the ability to perform the sorts of blanket surveillance that we've seen. There's no technically valid reason that my mother couldn't host and run her own e-mail server on her home Internet connection. Except that she doesn't have a fixed IP. And there's no software that would make it trivial for her to do so (there are honorable mentions, but really this has got to be nearly as easy as plug-and-go). The Internet was designed as an any node to any node system. The insertion of ISP mail servers as an intermediate step made lots of sense back in the days of shell and dialup. It makes a little less sense now. But the community is extremely resistant to change. Certainly Gmail has no incentive to suggest that people go run their own mail server. And we've created enough other roadblocks that it isn't likely to happen. Sigh. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nicolai-nanog at chocolatine.org Fri Sep 6 18:19:50 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Fri, 6 Sep 2013 13:19:50 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> Message-ID: <20130906181950.GC14944@vectra.student.iastate.edu> On Fri, Sep 06, 2013 at 01:52:16PM -0400, Sam Moats wrote: > The problem being is when you do have a provider that appears to be > secure and out of reach, think lavabit, that provider will not survive > for long. That's true -- it is far easier to subvert email than most other services, and in the case of email we probably need a wholly new protocol. But many or most services can be sufficiently improved, and that's the goal: improvement. http://prism-break.org/ lists examples of this improvement. Nicolai From cscora at apnic.net Fri Sep 6 18:34:11 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Sep 2013 04:34:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201309061834.r86IYBJl020352@thyme.rand.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, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. 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 . Routing Table Report 04:00 +10GMT Sat 07 Sep, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 466753 Prefixes after maximum aggregation: 188207 Deaggregation factor: 2.48 Unique aggregates announced to Internet: 231835 Total ASes present in the Internet Routing Table: 44906 Prefixes per ASN: 10.39 Origin-only ASes present in the Internet Routing Table: 35097 Origin ASes announcing only one prefix: 16257 Transit ASes present in the Internet Routing Table: 5913 Transit-only ASes present in the Internet Routing Table: 165 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 5649 Unregistered ASNs in the Routing Table: 1916 Number of 32-bit ASNs allocated by the RIRs: 5006 Number of 32-bit ASNs visible in the Routing Table: 3896 Prefixes from 32-bit ASNs in the Routing Table: 11954 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 362 Number of addresses announced to Internet: 2641573844 Equivalent to 157 /8s, 115 /16s and 55 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.0 Total number of prefixes smaller than registry allocations: 163579 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110477 Total APNIC prefixes after maximum aggregation: 33521 APNIC Deaggregation factor: 3.30 Prefixes being announced from the APNIC address blocks: 112415 Unique aggregates announced from the APNIC address blocks: 46754 APNIC Region origin ASes present in the Internet Routing Table: 4866 APNIC Prefixes per ASN: 23.10 APNIC Region origin ASes announcing only one prefix: 1223 APNIC Region transit ASes present in the Internet Routing Table: 829 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 661 Number of APNIC addresses announced to Internet: 728202176 Equivalent to 43 /8s, 103 /16s and 123 /24s Percentage of available APNIC address space announced: 85.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 161488 Total ARIN prefixes after maximum aggregation: 81121 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 162089 Unique aggregates announced from the ARIN address blocks: 75491 ARIN Region origin ASes present in the Internet Routing Table: 15867 ARIN Prefixes per ASN: 10.22 ARIN Region origin ASes announcing only one prefix: 6025 ARIN Region transit ASes present in the Internet Routing Table: 1661 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 20 Number of ARIN addresses announced to Internet: 1071412992 Equivalent to 63 /8s, 220 /16s and 119 /24s Percentage of available ARIN address space announced: 56.7 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, 393216-394239 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: 119588 Total RIPE prefixes after maximum aggregation: 61203 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 123427 Unique aggregates announced from the RIPE address blocks: 79478 RIPE Region origin ASes present in the Internet Routing Table: 17412 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 8246 RIPE Region transit ASes present in the Internet Routing Table: 2819 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2390 Number of RIPE addresses announced to Internet: 657143780 Equivalent to 39 /8s, 43 /16s and 55 /24s Percentage of available RIPE address space announced: 95.5 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, 196608-199679 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: 51499 Total LACNIC prefixes after maximum aggregation: 9762 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 56191 Unique aggregates announced from the LACNIC address blocks: 25825 LACNIC Region origin ASes present in the Internet Routing Table: 2011 LACNIC Prefixes per ASN: 27.94 LACNIC Region origin ASes announcing only one prefix: 566 LACNIC Region transit ASes present in the Internet Routing Table: 379 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 819 Number of LACNIC addresses announced to Internet: 137498160 Equivalent to 8 /8s, 50 /16s and 14 /24s Percentage of available LACNIC address space announced: 82.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11655 Total AfriNIC prefixes after maximum aggregation: 2549 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 12269 Unique aggregates announced from the AfriNIC address blocks: 3952 AfriNIC Region origin ASes present in the Internet Routing Table: 652 AfriNIC Prefixes per ASN: 18.82 AfriNIC Region origin ASes announcing only one prefix: 197 AfriNIC Region transit ASes present in the Internet Routing Table: 138 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46563072 Equivalent to 2 /8s, 198 /16s and 127 /24s Percentage of available AfriNIC address space announced: 46.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 4766 2919 11561 924 Korea Telecom (KIX) 17974 2667 903 91 PT TELEKOMUNIKASI INDONESIA 7545 2068 321 112 TPG Internet Pty Ltd 4755 1769 390 190 TATA Communications formerly 9829 1547 1237 46 BSNL National Internet Backbo 9583 1229 92 508 Sify Limited 9498 1184 309 70 BHARTI Airtel Ltd. 4808 1160 2129 342 CNCGROUP IP network: China169 7552 1139 1080 13 Vietel Corporation 24560 1090 394 160 Bharti Airtel Ltd., Telemedia 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 6389 3068 3689 62 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 22773 2041 2933 125 Cox Communications, Inc. 1785 2013 679 125 PaeTec Communications, Inc. 20115 1675 1645 630 Charter Communications 4323 1618 1119 410 Time Warner Telecom 701 1520 11119 796 UUNET Technologies, Inc. 30036 1344 301 643 Mediacom Communications Corp 7018 1313 11277 827 AT&T WorldNet Services 11492 1220 218 366 Cable One 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 8402 1724 544 16 Corbina telecom 34984 1314 244 221 BILISIM TELEKOM 2118 1179 97 13 EUnet/RELCOM Autonomous Syste 20940 987 355 766 Akamai Technologies European 31148 982 43 18 FreeNet ISP 6830 895 2367 427 UPC Distribution Services 13188 847 99 72 Educational Network 8551 752 370 41 Bezeq International 12479 687 797 53 Uni2 Autonomous System 58113 541 55 339 LIR DATACENTER TELECOM SRL 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 28573 3232 1719 96 NET Servicos de Comunicao S.A 10620 2547 416 259 TVCABLE BOGOTA 7303 1693 1118 223 Telecom Argentina Stet-France 18881 1430 844 20 Global Village Telecom 8151 1282 2775 386 UniNet S.A. de C.V. 14522 987 150 9 SatNet S.A. 11830 926 364 15 Instituto Costarricense de El 27947 838 94 91 Telconet S.A 6503 812 434 64 AVANTEL, S.A. 7738 764 1498 36 Telecomunicacoes da Bahia S.A 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 36998 1861 112 5 MOBITEL 24863 869 274 30 LINKdotNET AS number 6713 543 633 26 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 257 921 216 The Internet Solution 36992 222 501 28 Etisalat MISR 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 12258 193 28 71 Vodacom Internet Company 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 28573 3232 1719 96 NET Servicos de Comunicao S.A 6389 3068 3689 62 bellsouth.net, inc. 4766 2919 11561 924 Korea Telecom (KIX) 17974 2667 903 91 PT TELEKOMUNIKASI INDONESIA 10620 2547 416 259 TVCABLE BOGOTA 7545 2068 321 112 TPG Internet Pty Ltd 18566 2065 382 184 Covad Communications 22773 2041 2933 125 Cox Communications, Inc. 1785 2013 679 125 PaeTec Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3068 3006 bellsouth.net, inc. 17974 2667 2576 PT TELEKOMUNIKASI INDONESIA 10620 2547 2288 TVCABLE BOGOTA 4766 2919 1995 Korea Telecom (KIX) 7545 2068 1956 TPG Internet Pty Ltd 22773 2041 1916 Cox Communications, Inc. 1785 2013 1888 PaeTec Communications, Inc. 18566 2065 1881 Covad Communications 36998 1861 1856 MOBITEL 8402 1724 1708 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.90.192.0/18 36086 Broad Communications Technolo 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.92.16.0/21 8001 Net Access Corporation 23.92.24.0/22 6939 Hurricane Electric 23.92.48.0/20 29761 OC3 Networks & Web Solutions, 23.92.64.0/24 54540 Incero LLC 23.92.65.0/24 54540 Incero LLC 23.92.66.0/24 54540 Incero LLC 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:11 /10:30 /11:93 /12:250 /13:479 /14:911 /15:1612 /16:12783 /17:6696 /18:11128 /19:22799 /20:32381 /21:35037 /22:49361 /23:43119 /24:247605 /25:827 /26:990 /27:467 /28:48 /29:77 /30:19 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1713 3068 bellsouth.net, inc. 8402 1447 1724 Corbina telecom 22773 1327 2041 Cox Communications, Inc. 30036 1207 1344 Mediacom Communications Corp 11492 1181 1220 Cable One 1785 1085 2013 PaeTec Communications, Inc. 6983 1025 1152 ITC^Deltacom 7011 933 1176 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:809 2:844 3:3 4:19 5:940 6:19 8:614 12:1894 13:2 14:867 15:11 16:3 17:11 18:19 20:18 23:377 24:1744 27:1565 31:1436 32:45 33:2 34:5 36:71 37:1863 38:898 39:4 40:179 41:3294 42:255 44:9 46:1972 47:4 49:665 50:840 52:12 54:37 55:7 57:26 58:1168 59:621 60:336 61:1415 62:1225 63:1990 64:4558 65:2311 66:4166 67:2064 68:1090 69:3302 70:863 71:496 72:2007 74:2549 75:329 76:304 77:1163 78:1056 79:625 80:1318 81:1024 82:646 83:582 84:581 85:1264 86:483 87:1049 88:556 89:1833 90:158 91:5623 92:604 93:1675 94:2027 95:1569 96:509 97:339 98:1041 99:44 100:29 101:598 103:3292 105:519 106:142 107:207 108:501 109:1878 110:963 111:1129 112:568 113:792 114:732 115:987 116:977 117:818 118:1124 119:1287 120:366 121:740 122:1872 123:1249 124:1387 125:1422 128:614 129:221 130:318 131:671 132:351 133:161 134:287 135:67 136:272 137:267 138:348 139:180 140:196 141:325 142:554 143:387 144:493 145:100 146:529 147:490 148:691 149:356 150:152 151:581 152:416 153:195 154:30 155:480 156:274 157:409 158:284 159:754 160:350 161:458 162:629 163:226 164:626 165:561 166:256 167:606 168:1033 169:125 170:1083 171:194 172:25 173:1600 174:520 175:499 176:1190 177:2148 178:1907 179:113 180:1528 181:706 182:1264 183:436 184:633 185:809 186:2475 187:1448 188:1896 189:1308 190:7263 192:6915 193:5705 194:4650 195:3573 196:1340 197:1011 198:4664 199:5445 200:6059 201:2608 202:8941 203:8920 204:4521 205:2619 206:2835 207:2901 208:4003 209:3623 210:2945 211:1560 212:2265 213:2056 214:919 215:100 216:5287 217:1653 218:623 219:312 220:1277 221:557 222:326 223:499 End of report From mike at mtcc.com Fri Sep 6 19:03:56 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Sep 2013 12:03:56 -0700 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906181950.GC14944@vectra.student.iastate.edu> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> Message-ID: <522A271C.6070904@mtcc.com> On 09/06/2013 11:19 AM, Nicolai wrote: > That's true -- it is far easier to subvert email than most other > services, and in the case of email we probably need a wholly new > protocol. > Uh, a first step might be to just turn on [START]TLS. We're not using the tools that have been implemented and deployed for a decade at least. Mike From eugen at leitl.org Fri Sep 6 19:14:32 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 6 Sep 2013 21:14:32 +0200 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <522A271C.6070904@mtcc.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> Message-ID: <20130906191432.GG29404@leitl.org> On Fri, Sep 06, 2013 at 12:03:56PM -0700, Michael Thomas wrote: > On 09/06/2013 11:19 AM, Nicolai wrote: > >That's true -- it is far easier to subvert email than most other > >services, and in the case of email we probably need a wholly new > >protocol. > > > > Uh, a first step might be to just turn on [START]TLS. We're not using the > tools that have been implemented and deployed for a decade at least. Received: from sc1.nanog.org (sc1.nanog.org [50.31.151.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by leitl.org (Postfix) with ESMTPS id 57418543E4D for ; Fri, 6 Sep 2013 21:06:34 +0200 (CEST) Received: from localhost ([::1] helo=sc1.nanog.org) by sc1.nanog.org with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VI1KX-000CSi-NT; Fri, 06 Sep 2013 19:04:29 +0000 Received: from mtcc.com ([50.0.18.224]) by sc1.nanog.org with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VI1KH-000CQe-Mt for nanog at nanog.org; Fri, 06 Sep 2013 19:04:13 +0000 Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r86J3uVr017222 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 12:03:57 -0700 -- doesn't do PFS, unfortunately. Everything should be doing PFS, now that we know. From mike at mtcc.com Fri Sep 6 19:24:51 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Sep 2013 12:24:51 -0700 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906191432.GG29404@leitl.org> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> <20130906191432.GG29404@leitl.org> Message-ID: <522A2C03.5040608@mtcc.com> On 09/06/2013 12:14 PM, Eugen Leitl wrote: > On Fri, Sep 06, 2013 at 12:03:56PM -0700, Michael Thomas wrote: >> On 09/06/2013 11:19 AM, Nicolai wrote: >>> That's true -- it is far easier to subvert email than most other >>> services, and in the case of email we probably need a wholly new >>> protocol. >>> >> Uh, a first step might be to just turn on [START]TLS. We're not using the >> tools that have been implemented and deployed for a decade at least. Of course: > Received: from sc1.nanog.org (sc1.nanog.org [50.31.151.68]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) > (Client did not present a certificate) doesn't instill a lot of confidence :) It's better than nothing though. Mike From betty at newnog.org Fri Sep 6 19:50:46 2013 From: betty at newnog.org (Betty Burke ) Date: Fri, 6 Sep 2013 15:50:46 -0400 Subject: [NANOG-announce] NANOG Fellowship Reminder Message-ID: If you are considering attending a NANOG meeting, and need a bit of assistance, consider submitting a NANOG Fellowship application. Fellowship Applicants are eligible if they meet all the criteria of either Fellowship, currently reside in the North American Region served by NANOG, and have not attended a NANOG meeting in the last five years. The NANOG 59 Fellowship application process will remain open from August 26, 2013 until 5:00 PM PST on September 9, 2013. As always, if you have additional questions, please feel free to also contact me directly. Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From nicolai-nanog at chocolatine.org Fri Sep 6 19:52:34 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Fri, 6 Sep 2013 14:52:34 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <522A271C.6070904@mtcc.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> Message-ID: <20130906195233.GA23760@vectra.student.iastate.edu> On Fri, Sep 06, 2013 at 12:03:56PM -0700, Michael Thomas wrote: > On 09/06/2013 11:19 AM, Nicolai wrote: > >That's true -- it is far easier to subvert email than most other > >services, and in the case of email we probably need a wholly new > >protocol. > > > > Uh, a first step might be to just turn on [START]TLS. We're not using the > tools that have been implemented and deployed for a decade at least. Agreed. Although some people are uncomfortable with OpenSSL's track record, and don't want to trade system security for better-than-plaintext network security. But the deeper issue is coercing providers to give up mail stored on private servers, bypassing the network altogether. TLS doesn't address this problem. Short term: deploy [START]TLS. Long term: we need a new email protocol with E2E encryption. Nicolai From matthew at matthew.at Fri Sep 6 20:00:41 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 06 Sep 2013 13:00:41 -0700 Subject: Caution! Don't attempt the Postini to Google Apps transition Message-ID: <522A3469.5050603@matthew.at> TL; DR: Email won't be delivered, No support I have two domains that I set up with Postini for spam filtering, and I was very happy for years. But Google purchased Postini, and has been increasingly insistent that I migrate to Google Apps. They have a transition process which is supposedly seamless, and which guarantees that mail will continue flowing throughout the transition. In reality, all of my email was offline for 24 hours, first into a black hole, and then bouncing with permanent failures. Calling Google support last night resulted in a long wait to finally talk to someone who told me that Postini support was too busy and who took down my name and number for a call back. Never got a call. This morning I opened a support ticket via the web site, and two hours later got a reply suggesting that it might be my MX records. Never mind that (according to the logs I could see) the mail was still flowing properly to Postini, passing through there to Google, and then being dumped at Google. When I called to escalate, I found a support agent who couldn't find the ticket I had opened via the website, and who then tried to transfer me. In the process, I sat on hold for 30 minutes, then the call was dropped. When I called right back, I went through the same phone tree and authentication process, and reached another agent. When he asked my problem, and I started to describe it, he said "oh, Postini" and then hung up on me. At that point it had been 24 hours, which is too long to have one's inbound email getting permanent failures, and so I've set my MX records to point directly at my own servers and will just live without spam filtering for a while. In the meantime, I strongly encourage anyone else who cares about reliable email delivery to avoid my fate. Matthew Kaufman matthew at matthew.at From cma at cmadams.net Fri Sep 6 20:02:22 2013 From: cma at cmadams.net (Chris Adams) Date: Fri, 6 Sep 2013 15:02:22 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906195233.GA23760@vectra.student.iastate.edu> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> <20130906195233.GA23760@vectra.student.iastate.edu> Message-ID: <20130906200222.GB2434@cmadams.net> Once upon a time, Nicolai said: > Agreed. Although some people are uncomfortable with OpenSSL's track record, > and don't want to trade system security for better-than-plaintext > network security. OpenSSL is not the only game in town. -- Chris Adams From mike at mtcc.com Fri Sep 6 20:04:48 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Sep 2013 13:04:48 -0700 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906195233.GA23760@vectra.student.iastate.edu> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> <20130906195233.GA23760@vectra.student.iastate.edu> Message-ID: <522A3560.5050103@mtcc.com> On 09/06/2013 12:52 PM, Nicolai wrote: > On Fri, Sep 06, 2013 at 12:03:56PM -0700, Michael Thomas wrote: >> On 09/06/2013 11:19 AM, Nicolai wrote: >>> That's true -- it is far easier to subvert email than most other >>> services, and in the case of email we probably need a wholly new >>> protocol. >>> >> Uh, a first step might be to just turn on [START]TLS. We're not using the >> tools that have been implemented and deployed for a decade at least. > Agreed. Although some people are uncomfortable with OpenSSL's track record, > and don't want to trade system security for better-than-plaintext > network security. > > But the deeper issue is coercing providers to give up mail stored on > private servers, bypassing the network altogether. TLS doesn't address > this problem. Short term: deploy [START]TLS. Long term: we need a new > email protocol with E2E encryption. > > I'd say we already have those things too in the form of PGP/SMIME. Who knows what the NSA can break, but it's just not right to say that we need new protocols. The means has been there for many years to secure email (fsvo 'secure'), it's just that it's not terribly convenient so we just don't for the most part. Mike From eugen at leitl.org Fri Sep 6 20:16:22 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 6 Sep 2013 22:16:22 +0200 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <522A3560.5050103@mtcc.com> References: <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <20130906181950.GC14944@vectra.student.iastate.edu> <522A271C.6070904@mtcc.com> <20130906195233.GA23760@vectra.student.iastate.edu> <522A3560.5050103@mtcc.com> Message-ID: <20130906201622.GM29404@leitl.org> On Fri, Sep 06, 2013 at 01:04:48PM -0700, Michael Thomas wrote: > I'd say we already have those things too in the form of PGP/SMIME. > Who knows what the NSA can break, but it's just not right to say that > we need new protocols. The means has been there for many years to > secure email (fsvo 'secure'), it's just that it's not terribly convenient > so we just don't for the most part. The scuttlebutt is that anything SMTP is unfixable, so XMPP/OTR is gap-filler until really distributed systems with zero metadata (Tahoe LAFS & Co) come along. In regards to Schneier's manifesto, it seems he's targeting noncorporate/nonaffiliated engineers, and there *has* been considerable activity in the woodworks in the past months. Most of the resulting countermeasures will be more for the network edge and end users, so not really operationally relevant for nanog. Sorry to waste your time, but it was worth a try. From scott at sberkman.net Fri Sep 6 20:41:20 2013 From: scott at sberkman.net (Scott Berkman) Date: Fri, 6 Sep 2013 16:41:20 -0400 Subject: [Q] Any good resource of info ref LECs, in different US areas? In-Reply-To: References: Message-ID: <0f3901ceab41$72811850$578348f0$@sberkman.net> Not sure exactly what you are looking for, but how about: http://localcallingguide.com/ (Free/open copy of certain LERG tables, should list all providers in a given RC/LATA/NPA-NXX) or http://www.telcodata.us/ Hope that helps, -Scott -----Original Message----- From: Stefan [mailto:netfortius at gmail.com] Sent: Wednesday, September 04, 2013 3:01 PM To: nanog at nanog.org Subject: [Q] Any good resource of info ref LECs, in different US areas? Trying to build diversity in some very odd places, about which the big names tell me exclusively about other bug names, but cannot easily verify. Thank you, ***Stefan From ncnet at sbcglobal.net Fri Sep 6 21:30:39 2013 From: ncnet at sbcglobal.net (Larry Stites) Date: Fri, 6 Sep 2013 14:30:39 -0700 (PDT) Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <09428536190357281104c4b05d29f720@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <09428536190357281104c4b05d29f720@www.circlenet.us> Message-ID: <1378503039.44372.YahooMailNeo@web181504.mail.ne1.yahoo.com> MAN UP! ________________________________ From: Sam Moats To: nanog at nanog.org Sent: Friday, September 6, 2013 8:04 AM Subject: Re: The US government has betrayed the Internet. We need to take it back This is part of the purpose behind the separation of powers between executive, legislative and judicial. William Pitt wrote "Unlimited power is apt to corrupt the minds of those who possess it" . As such constraints are needed and in place. We expect politician to cheat,lie,be stupid and self serving. Because we like people who tell us what we want to hear and most of us vote for people that we like. The do not have to be wise, or even competent. Personally I think most of the fault currently lies with the Judicial side. These laws were enacted as a knee jerk reaction to an event. I can understand the passions of people at that time because I shared them, however the courts are supposed to be a bulwark against this very kind of rash action. These men and women are supposed to be well educated in the fundamental concepts that constructed our republic and appointed to terms that prevent them from worrying about the political whims of the time. Sam On 2013-09-06 10:55, Royce Williams wrote: > On Fri, Sep 6, 2013 at 6:27 AM, Naslund, Steve wrote: > > [snip] > >> 1.? We vote in a new executive branch every four years.? They control and > appoint the NSA director.? Vote them out if you don't like how they run > things.? Do you think a President wants to maintain power?? Of course they > do and they will change a policy that will get them tossed out (if enough > people actually care). >> >> 2.? The Congress passes the laws that govern telecom and intelligence > gathering.? They also have the power to impeach and/or prosecute the > executive branch for misdeeds.? They will pass any law or do whatever it > takes to keep themselves in power.? Again this requires a lot of public > pressure. > > Historically speaking, I'm not convinced that a pure political solution > will ever work, other than on the surface.? The need for surveillance > transcends both administrations and political parties.? Once the newly > elected are presented with the intel available at that level, even their > approach to handling the flow of information and their social interaction > have to change in order to function. > > Daniel Ellsberg's attempt to explain this to Kissinger is insightful. It's > a pretty quick read, with many layers of important observations. (It's > Mother Jones, but this content is apolitical): > > > > http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge > > I think that Schneier's got it right.? The solution has to be both > technical and political, and must optimize for two functions: catch the bad > guys, while protecting the rights of the good guys. > > When the time comes for the political choices to be made, the good > technical choices must be the only ones available. > > Security engineering must pave the way to the high road -- so that it's the > only road to get there. > > Royce From ncnet at sbcglobal.net Fri Sep 6 21:43:44 2013 From: ncnet at sbcglobal.net (Larry Stites) Date: Fri, 6 Sep 2013 14:43:44 -0700 (PDT) Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <6f6579b06623c318cfe2e415c57b0771@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <6f6579b06623c318cfe2e415c57b0771@www.circlenet.us> Message-ID: <1378503824.21438.YahooMailNeo@web181502.mail.ne1.yahoo.com> "Just following orders..." ________________________________ From: Sam Moats To: nanog at nanog.org Sent: Friday, September 6, 2013 7:30 AM Subject: RE: The US government has betrayed the Internet. We need to take it back +1 I couldn't have said it any better. Sam On 2013-09-06 10:27, Naslund, Steve wrote: > The error in this whole conversation is that you cannot "take it > back" as an engineer.? You do not own it.? You are like an architect > or carpenter and are no more responsible for how it is used than the > architect is responsible that the building he designed is being used > as a crack house.? Do Ford engineers have a "social contract" to > ensure that I do not run over squirrels with my Explorer, will they > "take it back" if I do so?? The whole "social contract" argument is > ridiculous.? You have a contract (or most likely an "at will" > agreement") with your employer to build what they want and operate it > in the way that they want you to.? If it is against your ethics to do > so, quit.? The companies that own the network have a fiduciary > responsibility to their investors and a responsibility to serve their > customers.? If anyone is really that bent out of shape by the NSA > tactics (and I am not so sure they are given the lack of political > backlash) here is what you can do. > > In the United States there are two main centers of power that can > affect these policies, the consumer and the voter. > > 1.? We vote in a new executive branch every four years.? They control > and appoint the NSA director.? Vote them out if you don't like how > they run things.? Do you think a President wants to maintain power? > Of course they do and they will change a policy that will get them > tossed out (if enough people actually care). > > 2.? The Congress passes the laws that govern telecom and intelligence > gathering.? They also have the power to impeach and/or prosecute the > executive branch for misdeeds.? They will pass any law or do whatever > it takes to keep themselves in power.? Again this requires a lot of > public pressure. > > 3.? The companies that are consenting to monitoring (legal or > illegal) are stuck between two powers.? The federal government's power > to regulate them and the investors / consumers they serve.? Apparently > they are more scared of the government even though the consumer can > put them out of business overnight by simply not using their product > any more.? If everyone cancelled their gmail accounts, stopped using > Google search, and stopped paying for Google placement and ads, their > stock would go to zero nearly overnight.? Again, no one seems to care > about the issue enough to do this because I have seen no appreciable > backlash against these companies. > > If a social contract exists at all in the United States, it would be > to hold your government and the companies you do business with to your > ethical standards.? Another things to remember is that the NSA > engineers were probably acting under their "social contract" to defend > the United States from whatever enemies they are trying to monitor and > also felt they were doing the "right thing".? The problem with "social > contracts" is that they are relative. > > As far as other countries are concerned, you can affect their > policies as well.? US carriers are peered with and provide transit to > Chinese companies.? If the whole world is that outraged with what they > do, they just need to pressure the companies they do business with not > to do business with China. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Friday, September 06, 2013 8:51 AM > To: NANOG > Subject: Re: The US government has betrayed the Internet. We need to > take it back > >> > The US government has betrayed the Internet. We need to take it back > >> > > >> > >> > Who is we ? >> >> If you bothered to read the 1st paragraph you would know. >> > > I read all of it, the original article and other references to it. > > IMHO, there is no amount of engineering that can fix stupid people > doing stupid things on both sides of the stupid lines. > > By trying to fix what is perceived an engineering issue (seems that > China doing the same or worse for many years wasn't an engineering > problem) the only result you will obtain is a budget increase on the > counter-engineering efforts, that may represent a big chunk of money > that can be used in more effective ways where it is really needed. > > My .02 > -J From LarrySheldon at cox.net Fri Sep 6 21:50:42 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 06 Sep 2013 16:50:42 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: References: <20130906093753.GF29404@leitl.org> Message-ID: <522A4E32.9080809@cox.net> On 9/6/2013 8:08 AM, John Peach wrote: > On Fri, 6 Sep 2013 07:46:59 -0500 Jorge Amodio > wrote: > >> http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying >>> >>> >> >> The US government has betrayed the Internet. We need to take it back >>> >> >> Who is we ? > > If you bothered to read the 1st paragraph you would know. I did "bother".....the first 'graf after the link reads, in toto: > The US government has betrayed the Internet. We need to take it > back[sic] You apparently use the silent "period" at the ends of 'grafs so I took the blank lime as the 'graf delimiter. Who is "we". I lave learned to distrust the generic "we" as doers of stuff. What is your part of the recovery? What do you see as mine. (I like "you" and "me" as identifiers for doers of stuff. Third party identifiers are acceptible and tenatives, pending conversion to "me" or "you". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From cidr-report at potaroo.net Fri Sep 6 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Sep 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201309062200.r86M002Y009908@wattle.apnic.net> This report has been generated at Fri Sep 6 21:14:04 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 30-08-13 479696 271236 31-08-13 479888 271502 01-09-13 479969 271415 02-09-13 480012 270940 03-09-13 479606 271654 04-09-13 479909 272113 05-09-13 480734 272243 06-09-13 481151 272602 AS Summary 45072 Number of ASes in routing system 18545 Number of ASes announcing only one prefix 4174 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117918976 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Sep13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 481041 272501 208540 43.4% All ASes AS6389 3068 65 3003 97.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3233 473 2760 85.4% NET Servi?os de Comunica??o S.A. AS17974 2666 170 2496 93.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4174 2025 2149 51.5% WINDSTREAM - Windstream Communications Inc AS4766 2919 939 1980 67.8% KIXS-AS-KR Korea Telecom AS22773 2044 138 1906 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS10620 2549 1015 1534 60.2% Telmex Colombia S.A. AS3356 3236 1714 1522 47.0% LEVEL3 Level 3 Communications AS36998 1862 423 1439 77.3% SDN-MOBITEL AS4323 2971 1534 1437 48.4% TWTC - tw telecom holdings, inc. AS18881 1430 69 1361 95.2% Global Village Telecom AS7303 1693 455 1238 73.1% Telecom Argentina S.A. AS4755 1768 589 1179 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1179 75 1104 93.6% RELCOM-AS OOO "NPO Relcom" AS7552 1161 131 1030 88.7% VIETEL-AS-AP Vietel Corporation AS22561 1196 212 984 82.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2013 1157 856 42.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS11830 927 117 810 87.4% Instituto Costarricense de Electricidad y Telecom. AS18101 981 179 802 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1160 402 758 65.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 2073 1351 722 34.8% TPG-INTERNET-AP TPG Telecom Limited AS701 1521 800 721 47.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 853 142 711 83.4% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS6147 734 44 690 94.0% Telefonica del Peru S.A.A. AS8151 1290 608 682 52.9% Uninet S.A. de C.V. AS855 732 55 677 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1152 483 669 58.1% ITCDELTA - ITC^Deltacom AS24560 1090 433 657 60.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7738 764 135 629 82.3% Telemar Norte Leste S.A. Total 54504 16401 38103 69.9% Top 30 total Possible Bogus Routes 23.92.128.0/17 AS42981 RES-PL RES.PL ISP S.C. 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 31.13.184.0/21 AS42981 RES-PL RES.PL ISP S.C. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 82.103.0.0/18 AS30901 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.200.188.0/22 AS44016 91.205.188.0/22 AS47983 91.207.0.0/23 AS174 COGENT Cogent/PSI 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.13.112.0/22 AS17676 GIGAINFRA Softbank BB Corp. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 164.40.184.0/24 AS19821 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.34.168.0/22 AS35224 SALLANDXS SallandXS B.V. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.0.227.0/24 AS34476 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.126.219.0/24 AS34545 194.146.220.0/22 AS29692 194.169.237.0/24 AS12968 CDP Netia SA 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.43.124.0/24 AS38193 TWA-AS-AP Transworld Associates (Pvt.) Ltd. 202.43.127.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.84.16.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.84.17.0/24 AS17781 XINHUA Xinhua News Agency 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Sep 6 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Sep 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201309062200.r86M01j8009930@wattle.apnic.net> BGP Update Report Interval: 29-Aug-13 -to- 05-Sep-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6866 122404 5.8% 683.8 -- CYTA-NETWORK Cyprus Telecommunications Authority 2 - AS27738 42369 2.0% 73.4 -- Ecuadortelecom S.A. 3 - AS9829 34878 1.7% 27.4 -- BSNL-NIB National Internet Backbone 4 - AS8402 34340 1.6% 20.0 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS28573 26252 1.2% 7.9 -- NET Servi?os de Comunica??o S.A. 6 - AS14287 21002 1.0% 388.9 -- TRIAD-TELECOM - Triad Telecom, Inc. 7 - AS9416 19059 0.9% 560.6 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - AS27941 18220 0.9% 1138.8 -- CONSULNETWORK LTDA 9 - AS36998 17919 0.8% 9.6 -- SDN-MOBITEL 10 - AS4775 16486 0.8% 229.0 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS6713 15677 0.7% 29.3 -- IAM-AS 12 - AS9498 13823 0.7% 15.2 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS11664 12702 0.6% 33.7 -- Techtel LMDS Comunicaciones Interactivas S.A. 14 - AS10620 11860 0.6% 4.8 -- Telmex Colombia S.A. 15 - AS4434 10579 0.5% 155.6 -- ERX-RADNET1-AS PT Rahajasa Media Internet 16 - AS2118 10022 0.5% 7.3 -- RELCOM-AS OOO "NPO Relcom" 17 - AS48612 9892 0.5% 899.3 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 18 - AS33597 9872 0.5% 60.6 -- INFORELAY - InfoRelay Online Systems, Inc. 19 - AS23487 9700 0.5% 89.8 -- CONECEL 20 - AS50710 9254 0.4% 38.4 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53008 8175 0.4% 8175.0 -- Pontal Cabo Ltda 2 - AS6174 7201 0.3% 3600.5 -- SPRINTLINK8 - Sprint 3 - AS42334 3226 0.1% 3226.0 -- BBP-AS Broadband Plus s.a.l. 4 - AS28698 6646 0.3% 2215.3 -- UUNETZM-AS 5 - AS7202 8766 0.4% 1252.3 -- FAMU - Florida A & M University 6 - AS27941 18220 0.9% 1138.8 -- CONSULNETWORK LTDA 7 - AS38654 6615 0.3% 1102.5 -- INES-NETWORK INES Corporation. 8 - AS37367 1072 0.1% 1072.0 -- CALLKEY 9 - AS43884 949 0.1% 949.0 -- EG-CONSULTING-AS EG Information Consulting Ltd 10 - AS6629 9219 0.4% 921.9 -- NOAA-AS - NOAA 11 - AS48612 9892 0.5% 899.3 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 12 - AS37374 746 0.0% 746.0 -- Liquid-zambia 13 - AS57201 713 0.0% 713.0 -- EDF-AS Estonian Defence Forces 14 - AS6866 122404 5.8% 683.8 -- CYTA-NETWORK Cyprus Telecommunications Authority 15 - AS18148 597 0.0% 597.0 -- FUKUOKA-U Fukuoka University 16 - AS9416 19059 0.9% 560.6 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 17 - AS47582 555 0.0% 555.0 -- KRAFT-S-TOGLIATTI Kraft-S JSC 18 - AS59699 535 0.0% 535.0 -- NICEBLUE-AS Nice Blue s.r.l. 19 - AS38000 1556 0.1% 518.7 -- CRISIL-AS [CRISIL Limited.Autonomous System] 20 - AS3 514 0.0% 307.0 -- CMED-AS Cmed Technology Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 61.95.239.0/24 11974 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 202.154.17.0/24 10391 0.5% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 3 - 92.246.207.0/24 9854 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 4 - 203.118.224.0/21 9537 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 9427 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 9127 0.4% AS6629 -- NOAA-AS - NOAA 7 - 120.28.62.0/24 8494 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 194.219.56.0/24 8178 0.4% AS1241 -- FORTHNET-GR Forthnet 9 - 177.185.160.0/20 8175 0.4% AS53008 -- Pontal Cabo Ltda 10 - 222.127.0.0/24 7906 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 11 - 41.216.64.0/19 7360 0.3% AS28698 -- UUNETZM-AS AS37374 -- Liquid-zambia 12 - 150.39.0.0/16 6610 0.3% AS38654 -- INES-NETWORK INES Corporation. 13 - 69.38.178.0/24 4710 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 204.29.132.0/23 4594 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 15 - 200.29.234.0/24 4575 0.2% AS27941 -- CONSULNETWORK LTDA 16 - 200.29.238.0/24 4575 0.2% AS27941 -- CONSULNETWORK LTDA 17 - 200.29.236.0/24 4575 0.2% AS27941 -- CONSULNETWORK LTDA 18 - 200.29.239.0/24 4483 0.2% AS27941 -- CONSULNETWORK LTDA 19 - 168.223.206.0/23 4390 0.2% AS7202 -- FAMU - Florida A & M University 20 - 64.187.64.0/23 4385 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From surfer at mauigateway.com Fri Sep 6 22:29:59 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Sep 2013 15:29:59 -0700 Subject: The US government has betrayed the Internet. We need to take it back Message-ID: <20130906152959.7B2CE221@resin03.mta.everyone.net> --- sam at circlenet.us wrote: From: Sam Moats There only options are to: Disobey the law, unacceptable in my opinion Close down services, noble but I need to eat and you probably want to keep getting email Compromise your principles and obey the law, the path often choosen. ---------------------------------------- So, there's no choice except to get a 5-gallon bucket of gov't-ky jelly and take it? So many things come to mind on your flag-waving emails, I can't think of what to say first. And believe me, that's not usual... ;-) After a while, you'll become raw and probably change your mind. scott From pdonner at cisco.com Fri Sep 6 23:03:44 2013 From: pdonner at cisco.com (Paul Donner (pdonner)) Date: Fri, 6 Sep 2013 23:03:44 +0000 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu>, <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> Message-ID: <79B23DB4F91C474E8B9D8CAB5C4738830E600072@xmb-aln-x01.cisco.com> Great opportunity for a country like Brazil (for example) to become a place of business for many of these services which are subject to Calea (and such) in the US. This type of behavior is certainly a motivator for folks in other countries to benefit, to our detriment. If the NSA is truly undermining the security of private enterprises which rely on compromised security implements, besides being counter productive, it will cost (maybe already has) in lost revenue or damages. Sooner or later this is going to take its toll. In the end the universal language of "cold hard cash" will reign. /wp ________________________________ From: Sam Moats Sent: ?9/?6/?2013 11:55 AM To: nanog at nanog.org Subject: Re: The US government has betrayed the Internet. We need to take it back The problem being is when you do have a provider that appears to be secure and out of reach, think lavabit, that provider will not survive for long. The CALEA requirements, and Patriot Act provisions will force them into compliance. There only options are to: Disobey the law, unacceptable in my opinion Close down services, noble but I need to eat and you probably want to keep getting email Compromise your principles and obey the law, the path often choosen. Sam Moats On 2013-09-06 13:20, Nicolai wrote: > On Fri, Sep 06, 2013 at 02:27:32PM +0000, Naslund, Steve wrote: > >> If everyone cancelled their gmail accounts, stopped using Google >> search, >> and stopped paying for Google placement and ads, their stock would >> go to >> zero nearly overnight. Again, no one seems to care about the issue >> enough to do this because I have seen no appreciable backlash >> against >> these companies. > > I think Joe 6mbps sitting at home reads that everything he uses has > been > subverted. He doesn't know what alternatives exist, and doesn't have > the technical knowledge neccessary to find them on his own. And > faced > with a false choice -- stop using the Internet, or continue using it > as > he knows how -- he chooses the one that retains his ability to > communicate with family and friends and keep up on the things he > cares > about. > > Schneier is saying we need to build better options for Joe 6mbps, > competing with the PRISM-compatable services, so that > privacy-respecting > services become known and commonplace. > > Nicolai From cboyd at gizmopartners.com Fri Sep 6 23:14:02 2013 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 06 Sep 2013 18:14:02 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <79B23DB4F91C474E8B9D8CAB5C4738830E600072@xmb-aln-x01.cisco.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <20130906172005.GA14944@vectra.student.iastate.edu> , <3ddcaf55f3860bfd8d22f9fe4f9ac321@www.circlenet.us> <79B23DB4F91C474E8B9D8CAB5C4738830E600072@xmb-aln-x01.cisco.com> Message-ID: <1378509242.23718.1.camel@hounddog> On Fri, 2013-09-06 at 23:03 +0000, Paul Donner (pdonner) wrote: > Great opportunity for a country like Brazil (for example) to become a > place of business for many of these services which are subject to > Calea (and such) in the US. This type of behavior is certainly a > motivator for folks in other countries to benefit, to our detriment. > > If the NSA is truly undermining the security of private enterprises > which rely on compromised security implements, besides being counter > productive, it will cost (maybe already has) in lost revenue or > damages. Sooner or later this is going to take its toll. In the end > the universal language of "cold hard cash" will reign. You mean like this? http://www.zdnet.com/u-s-cloud-industry-stands-to-lose-35-billion-amid-prism-fallout-7000018974/ As one currently working in the cloud this is deeply concerning. --Chris From MGauvin at dryden.ca Fri Sep 6 23:13:57 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Fri, 6 Sep 2013 18:13:57 -0500 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906152959.7B2CE221@resin03.mta.everyone.net> References: <20130906152959.7B2CE221@resin03.mta.everyone.net> Message-ID: <104FA7FE-3EA5-4D10-9ECD-D33C7D641033@dryden.ca> This has been known for years so why the sudden list spam Calea in Canada goes into full force jan 1 2014 and yes it was meant to stop pedo bears but it is much farther reaching Sent from my iPhone On 2013-09-06, at 5:33 PM, "Scott Weeks" wrote: > > > --- sam at circlenet.us wrote: > From: Sam Moats > > There only options are to: > > Disobey the law, unacceptable in my opinion > > Close down services, noble but I need to eat and you probably want to > keep getting email > > Compromise your principles and obey the law, the path often choosen. > ---------------------------------------- > > > So, there's no choice except to get a 5-gallon bucket of gov't-ky > jelly and take it? So many things come to mind on your flag-waving > emails, I can't think of what to say first. And believe me, that's > not usual... ;-) After a while, you'll become raw and probably > change your mind. > > scott > From bzs at world.std.com Sat Sep 7 02:28:13 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 6 Sep 2013 22:28:13 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <9578293AE169674F9A048B2BC9A081B43C296C16@MUNPRDMBXA1.medline.com> References: <20130906093753.GF29404@leitl.org> <20130906090831.42a9e5dd@hulk> <9578293AE169674F9A048B2BC9A081B43C296970@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B43C296C16@MUNPRDMBXA1.medline.com> Message-ID: <21034.36669.616170.401954@world.std.com> The problem is that the US govt and others have been sucked into a vortex of bad game theory. They believe we the people don't want any terrorist acts against us, or minimized as much as possible, which is roughly: none. This belief is reasonable. Worse, terrorism has become a political weapon against whoever can be characterized as asleep on the watch. The president, DHS, FBI - remember all the news articles asking why the FBI didn't act earlier on the Marathon bombers? etc. Tonight at midnight Janet Napolitano is no longer head of DHS. As many have said: What a bad job she had! Just waiting for a terrorist attack so congress et al can demand to know why. So DHS, NSA, et al sit around dreaming up ways to prevent terrorism which in some cases probably works, and in other cases is probably impossible. They seem to have hit upon this surveillance effort as a "deliverable". The govt is going to resist "engineering" efforts because as I said it's their butts on the line not yours if there's an attack. Or yours only figuratively or by some coincidence (you're actually the victim of an attack.) We have a bad feedback loop going on in govt right now. Did the brains at al Qaeda foresee this in 2001? Possibly. It's not magic -- fear of terrorism creating a feedback loop like this. There are, or were, intellectuals behind AQ, some no doubt bright. So when people ask what is the aim of terrorism I think we're living it right here. I'm not convinced that characterizing "the govt" as the evil here is entirely constructive. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From sam at circlenet.us Sat Sep 7 12:32:44 2013 From: sam at circlenet.us (Sam Moats) Date: Sat, 07 Sep 2013 08:32:44 -0400 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <20130906152959.7B2CE221@resin03.mta.everyone.net> References: <20130906152959.7B2CE221@resin03.mta.everyone.net> Message-ID: <94f55d1319951119e121a77a53e1c579@www.circlenet.us> I'm sorry if you don't share my view. Personally I think the Patriot Act is unconsitutional and CALEA is a tool to enable the total invasion of privacy. I think the laws need changed, I want to change. That said I will not break them and neither will you. How would/does your company respond to NSLs or subpoenas? Do you comply with FCC 499 requirements and with CALEA requirements? I do, and I'm betting you will to. Does it suck? Yea of course it does but unless you have a better plan for a US based provider I will keep doing what I'm doing. Sam On 2013-09-06 18:29, Scot Weeks wrote: > --- sam at circlenet.us wrote: > From: Sam Moats > > There only options are to: > > Disobey the law, unacceptable in my opinion > > Close down services, noble but I need to eat and you probably want to > keep getting email > > Compromise your principles and obey the law, the path often choosen. > ---------------------------------------- > > > So, there's no choice except to get a 5-gallon bucket of gov't-ky > jelly and take it? So many things come to mind on your flag-waving > emails, I can't think of what to say first. And believe me, that's > not usual... ;-) After a while, you'll become raw and probably > change your mind. > > scott From mleber at he.net Sat Sep 7 19:28:09 2013 From: mleber at he.net (Mike Leber) Date: Sat, 07 Sep 2013 12:28:09 -0700 Subject: AlbertaIX - no longer a Cybera project? In-Reply-To: <201309052047.r85Kl0Yx021092@cvs.openbsd.org> References: <201309052047.r85Kl0Yx021092@cvs.openbsd.org> Message-ID: <522B7E49.2070503@he.net> On 9/5/13 1:47 PM, Theo de Raadt wrote: > The last six months in AlbertaIX saw no discussions (or approval) for > any action plan. Without votes, nothing can be built. This is probably the key ideological problem and a good example not to follow if you are trying to start an exchange. Do first, implement bureaucracy later, if at all. I completely respect the people that were on the board and also Cybera. FWIW, I have no direct insight into the conversations between the people involved. From a distance it seemed like exactly the right people to be involved (with only the minor problem of not enough ethernet switch pluggin' in and too much meetin' and discussin'). Facility and parties willing, hopefully there will be a YYCIX switch in Cybera. > The entire organization also lacks documents. The new game plan is to > follow YYCIX because of Hurricane Electric's arrival at the datacenter > which was (originally) the least preffered. Our criteria for choosing a facility in Calgary was: * Which facilities have a live ethernet switch for any Internet exchange? Then given the candidate list of data centers in the area: * Is there a live ethernet switch in their facility? * How many IPs are pingable on that switch? * Does the facility want us in their facility? (Is there any value for them? Are they happy to have us build in?) * Does the facility want the exchange to succeed? (Do they get it?) (Sadly sometimes the answer here is either indifference or hostility.) * Does the facility understand that we need them to encourage more networks to build into their facility? * Is the price for cross connects and power reasonable? * How many networks are in the building? * Can we get develop enough revenue to cover our costs to get circuits, colo, power, cross connects etc to build out to the site? (DataHive met all of these requirements and was repeatedly very helpful to make things happen.) There's a magic moment in the beginning of forming data center neutral exchanges where the engineers operating the exchange and the facility owners need to have a meeting of the minds and view the exchange as something they are doing together and then take the immediate actions to get it live. I'm not sure how the magic of this goes down since the facility owners may or may not view each other as competitors (and may or may not view the exchange as that useful). Once an exchange has critical mass like AMS-IX I suppose this becomes an easy decision for a new facility owner. I am led to understand that there is city fiber in Calgary available at reasonable cost, which hopefully would translate to exchange switches in multiple buildings eventually in Calgary (if various stages of critical mass are achieved). Mike. From deraadt at yycix.ca Sat Sep 7 20:22:16 2013 From: deraadt at yycix.ca (Theo de Raadt) Date: Sat, 07 Sep 2013 14:22:16 -0600 Subject: AlbertaIX - no longer a Cybera project? Message-ID: <201309072022.r87KMGvI029687@cvs.openbsd.org> Mike Leber wrote: > Facility and parties willing, hopefully there will be a YYCIX switch in > Cybera. Interesting idea, how the heck did I miss that. It would depend on Cybera being open to the idea, which starts off with a reevaluation of the following "not-for-profit acting as an ISP of last resort" strategy: http://www.cybera.ca/strategic-projects/internet-buying-group http://www.cybera.ca/strategic-projects/peering/ http://www.cybera.ca/membership/membership-structure/ In Canada, the other collision preventing exchanges from showing up is the CANARIE content peering model, which by providing free content access to schools and such takes many (young bandwidth hungry) eyeballs out of the equation for IX development and growth: http://www.canarie.ca/en/cds/policy http://www.canarie.ca/en/cds/cds_content_providers Time for change? From fergdawgster at mykolab.com Sat Sep 7 21:08:31 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sat, 07 Sep 2013 14:08:31 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522AEB22.8010007@internetidentity.com> References: <522AEB22.8010007@internetidentity.com> Message-ID: <522B95CF.2090206@mykolab.com> A Canadian ISP colleague of mine suggested that the NANOG constituency might be interested in this, given some recent 'revelations', so I forward it here for you perusal. "Preliminary analysis of more than 25,000 traceroutes reveals a phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian internet transmissions are routinely routed through the United States. Canadian originated transmissions that travel to a Canadian destination via a U.S. switching centre or carrier are subject to U.S. law - including the USA Patriot Act and FISAA. As a result, these transmissions expose Canadians to potential U.S. surveillance activities ? a violation of Canadian network sovereignty." http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html Cheers, - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From aaron at wholesaleinternet.net Sat Sep 7 21:17:45 2013 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Sat, 07 Sep 2013 16:17:45 -0500 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B95CF.2090206@mykolab.com> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: <522B97F9.3090708@wholesaleinternet.net> Not just a Canadian issue but one we should look at in the US as well. Deploying more IXs and routing our traffic direct instead of through the "big guys" can secure our own communications from our own government until we change who we have in office. Aaron On 9/7/2013 4:08 PM, Paul Ferguson wrote: > > A Canadian ISP colleague of mine suggested that the NANOG constituency > might be interested in this, given some recent 'revelations', so I > forward it here for you perusal. > > > > "Preliminary analysis of more than 25,000 traceroutes reveals a > phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian > internet transmissions are routinely routed through the United States. > Canadian originated transmissions that travel to a Canadian destination > via a U.S. switching centre or carrier are subject to U.S. law - > including the USA Patriot Act and FISAA. As a result, these > transmissions expose Canadians to potential U.S. surveillance activities > ? a violation of Canadian network sovereignty." > > http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html > > > Cheers, > > - ferg > > From deleskie at gmail.com Sat Sep 7 21:19:34 2013 From: deleskie at gmail.com (jim deleskie) Date: Sat, 7 Sep 2013 18:19:34 -0300 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B95CF.2090206@mykolab.com> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: Paul, I agree this is a problem, but its been a problem since at least 1994 ( my first exposure ) and I suspect longer, the issue is east we capacity in Canada is very $$, pushing traffic from Toronto east to points south to get it to Vancouver is much more cost effective. -jim On Sat, Sep 7, 2013 at 6:08 PM, Paul Ferguson wrote: > > A Canadian ISP colleague of mine suggested that the NANOG constituency > might be interested in this, given some recent 'revelations', so I forward > it here for you perusal. > > > > "Preliminary analysis of more than 25,000 traceroutes reveals a > phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian > internet transmissions are routinely routed through the United States. > Canadian originated transmissions that travel to a Canadian destination > via a U.S. switching centre or carrier are subject to U.S. law - > including the USA Patriot Act and FISAA. As a result, these > transmissions expose Canadians to potential U.S. surveillance activities > ? a violation of Canadian network sovereignty." > > http://lawprofessors.typepad.**com/media_law_prof_blog/2013/** > 09/routing-internet-**transmission-across-the-**canada-us-border-and-us-** > surveillance-activities.html > > Cheers, > > - ferg > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com > > From jmamodio at gmail.com Sat Sep 7 22:47:25 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 7 Sep 2013 17:47:25 -0500 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B97F9.3090708@wholesaleinternet.net> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <522B97F9.3090708@wholesaleinternet.net> Message-ID: <47D2B210-2A07-462A-8F17-24B46B9E4626@gmail.com> You have to change way more than that. BTW the one in office didn't start this. -Jorge On Sep 7, 2013, at 4:17 PM, Aaron Wendel wrote: > Not just a Canadian issue but one we should look at in the US as well. Deploying more IXs and routing our traffic direct instead of through the "big guys" can secure our own communications from our own government until we change who we have in office. > > Aaron From jimpop at gmail.com Sat Sep 7 21:51:44 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 7 Sep 2013 17:51:44 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B97F9.3090708@wholesaleinternet.net> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <522B97F9.3090708@wholesaleinternet.net> Message-ID: On Sat, Sep 7, 2013 at 5:17 PM, Aaron Wendel wrote: > Not just a Canadian issue... Nor even a North American one. -Jim P. From kmedcalf at dessus.com Sat Sep 7 23:34:36 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 07 Sep 2013 17:34:36 -0600 Subject: Yahoo is now recycling handles In-Reply-To: <11481.1378354648@turing-police.cc.vt.edu> Message-ID: <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> > > There's still the much more minor point that when I tried to "self > > serve" I ended up at a blank page on the Yahoo! web site, hopefully > > they will figure that out as well. > I'm continually amazed at the number of web designers that don't test > their pages with NoScript enabled. Just sayin'. The whole point of putting JavaScript (and other similar smegma) on a Web Page where it is not needed is to prevent people with smegma filters from being to access the page, and to suggest in no uncertain terms that these people take their business (and their money) elsewhere. Same applies to Flash. Take your business elsewhere. There is no point in complaining about it. Sometimes, it is a deliberate feature which is deliberately used to attack the visitors of a web site. Prime example is the DHS. From web at typo.org Sat Sep 7 23:45:19 2013 From: web at typo.org (Wayne E Bouchard) Date: Sat, 7 Sep 2013 16:45:19 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B95CF.2090206@mykolab.com> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: <20130907234519.GA63313@wakko.typo.org> It's a good point to consider however that omits the probabilty that Canada is doing exactly the same thing as the U.S. and thus this may free you from certain legalities but does not actually ensure privacy. The other fact of this is that we are well aware that the NSA's database is being accessed freely by (at the very least) England and Australia (I think that's who I read) I believe with reciprical agreements and I'd be shocked if Canada isn't in there too. What are the ramifications of that? Do we even know? Points to ponder... -Wayne On Sat, Sep 07, 2013 at 02:08:31PM -0700, Paul Ferguson wrote: > > A Canadian ISP colleague of mine suggested that the NANOG constituency > might be interested in this, given some recent 'revelations', so I > forward it here for you perusal. > > > > "Preliminary analysis of more than 25,000 traceroutes reveals a > phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian > internet transmissions are routinely routed through the United States. > Canadian originated transmissions that travel to a Canadian destination > via a U.S. switching centre or carrier are subject to U.S. law - > including the USA Patriot Act and FISAA. As a result, these > transmissions expose Canadians to potential U.S. surveillance activities > ? a violation of Canadian network sovereignty." > > http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html > > Cheers, > > - ferg > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From kmedcalf at dessus.com Sat Sep 7 23:58:14 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 07 Sep 2013 17:58:14 -0600 Subject: Yahoo is now recycling handles In-Reply-To: <2DF7933E-A48B-428C-B9DE-2810D50A43A1@marrowbones.com> Message-ID: <9fbb82d50743544dbe9e64792d9917eb@mail.dessus.com> The appropriate party to inform would be the FBI ... The word fraud comes to mind, and millions of 50 centses puts company officers in prison for a long long long time. > -----Original Message----- > From: Kee Hinckley [mailto:nazgul at marrowbones.com] > Sent: Thursday, 5 September, 2013 11:28 > To: nanog at nanog.org list > Subject: Re: Yahoo is now recycling handles > > > On Sep 4, 2013, at 9:47 PM, Leo Bicknell wrote: > > > > > I've got to apologize publicly to Yahoo! here as part of my issue was > my own stupidity. It appears in the past I've had multiple Yahoo! ID's > and I was > > I, on the other hand, need someone from Yahoo! to contact me, because I > decided to test their "email wishlist" feature. Repeated attempts got me > nothing but a message saying that my credit card information was > incorrect. But when I checked my bill this morning, I have three fifty > cent charges against my account (one for each time I revalidated my > email address while attempting to use their form). There's no contact > page on http://wishlist.yahoo.com, despite the fact that it's an > ecommerce page that takes credit cards, and there's no apparent way to > contact a human from the main yahoo page. I can always ask my credit > card company to refuse the charges, but if Yahoo! is charging credit > cards and not providing services, I think someone there needs to know > there's a problem. Never mind taking credit card numbers and providing > no customer support. From kmedcalf at dessus.com Sun Sep 8 00:20:58 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 07 Sep 2013 18:20:58 -0600 Subject: MTR for Android? In-Reply-To: Message-ID: Look for TRACEROUTE by SRCGUARDIAN in the Play Store. It needs network access only... Doesn't do TCP but does ICMP and UDP traceroutes and displays ASN as well ... From chk at pobox.com Sun Sep 8 00:33:16 2013 From: chk at pobox.com (Harald Koch) Date: Sat, 7 Sep 2013 20:33:16 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B95CF.2090206@mykolab.com> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: On 7 September 2013 17:08, Paul Ferguson wrote: > "Preliminary analysis of more than 25,000 traceroutes reveals a > phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian > internet transmissions are routinely routed through the United States. > I sincerely hope that nobody in Canada is surprised by this, since it was already an issue in 1994 (when I was at CA*net). -- Harald From randy at psg.com Sun Sep 8 00:34:49 2013 From: randy at psg.com (Randy Bush) Date: Sun, 08 Sep 2013 09:34:49 +0900 Subject: MTR for Android? In-Reply-To: References: Message-ID: > Look for TRACEROUTE by SRCGUARDIAN in the Play Store. thanks. works. From kmedcalf at dessus.com Sun Sep 8 00:38:48 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 07 Sep 2013 18:38:48 -0600 Subject: The US government has betrayed the Internet. We need to take it back In-Reply-To: <522A2C03.5040608@mtcc.com> Message-ID: Sure it does. You have confidentiality between the parties who are speaking together against third-parties merely passively intercepting the communication. Authentication and Confidentiality are two completely separate things and can (and are) implemented separately. The only Authentication which would be of any value to me is if the certificates was issued by me to the other party. Otherwise, one must assume that the certificate is fake for the purposes of authentication (ie, has no more value than a self-signed certificate). > -----Original Message----- > From: Michael Thomas [mailto:mike at mtcc.com] > Sent: Friday, 6 September, 2013 13:25 > To: Eugen Leitl > Cc: nanog at nanog.org > Subject: Re: The US government has betrayed the Internet. We need to > take it back > > On 09/06/2013 12:14 PM, Eugen Leitl wrote: > > On Fri, Sep 06, 2013 at 12:03:56PM -0700, Michael Thomas wrote: > >> On 09/06/2013 11:19 AM, Nicolai wrote: > >>> That's true -- it is far easier to subvert email than most other > >>> services, and in the case of email we probably need a wholly new > >>> protocol. > >>> > >> Uh, a first step might be to just turn on [START]TLS. We're not using > the > >> tools that have been implemented and deployed for a decade at least. > > Of course: > > Received: from sc1.nanog.org (sc1.nanog.org [50.31.151.68]) > > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits)) > > (Client did not present a certificate) > > doesn't instill a lot of confidence :) It's better than nothing though. > > Mike From rdobbins at arbor.net Sun Sep 8 01:09:25 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 8 Sep 2013 01:09:25 +0000 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522B95CF.2090206@mykolab.com> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> On Sep 8, 2013, at 4:08 AM, Paul Ferguson wrote: > As a result, these transmissions expose Canadians to potential U.S. surveillance activities ? a violation of Canadian network sovereignty." Yes, far better to keep those communications within Canada - where CSEC can hand them over to GCHQ, who'll then hand them over to NSA . . . ;> There are no technical solutions to purely social ills. This set of issues has nothing to do with technology, and everything to do with civil society. Any meaningful change in the status quo will not originate the technological realm, but rather in the political sphere. Quite frankly, all this chatter about technical 'calls to arms' and whatnot is pointless and distracting (thereby calling into question the motivations behind continued agitation for technical remedies, which clearly won't have any effect whatsoever). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Sun Sep 8 01:42:53 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 8 Sep 2013 01:42:53 +0000 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: <3CB5AB6B-6FBA-4717-95D0-2EB28B07F867@arbor.net> On Sep 8, 2013, at 8:09 AM, Dobbins, Roland wrote: > There are no technical solutions to purely social ills. That should read, 'There are no purely technical solutions to social ills.' ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From oscar.vives at gmail.com Sun Sep 8 01:54:28 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Sat, 7 Sep 2013 18:54:28 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: On 7 September 2013 18:09, Dobbins, Roland wrote: > > On Sep 8, 2013, at 4:08 AM, Paul Ferguson wrote: > >> As a result, these transmissions expose Canadians to potential U.S. surveillance activities ? a violation of Canadian network sovereignty." > > Yes, far better to keep those communications within Canada - where CSEC can hand them over to GCHQ, who'll then hand them over to NSA . . . But I don't think every secret service have installed his own backdoors in all popular software and protocols. And the NSA can't share these backdoors/weakness with all his "friends", because if you tell a secret to everyone, it stop being a secret. The existence and nature of these backdoors will be revealed, and the affected software will fix them. So probably the NSA works like Wall-Mart Secrets. And they sell secrets, 100.000$ for a list of human rights activist, 2 millions for the emails of the leaders of the opposition. -- -- ?in del ?ensaje. From randy at psg.com Sun Sep 8 07:58:52 2013 From: randy at psg.com (Randy Bush) Date: Sun, 08 Sep 2013 16:58:52 +0900 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: > Quite frankly, all this chatter about technical 'calls to arms' and > whatnot is pointless and distracting (thereby calling into question > the motivations behind continued agitation for technical remedies, > which clearly won't have any effect whatsoever). cool. then i presume you will continue to run using rc4 and rsa 1024. smart folk over there at arbor. randy From rdobbins at arbor.net Sun Sep 8 08:12:30 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 8 Sep 2013 08:12:30 +0000 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: <53DF743F-A1A7-42AF-B6C9-E3E3309A2E49@arbor.net> On Sep 8, 2013, at 2:58 PM, Randy Bush wrote: > cool. then i presume you will continue to run using rc4 and rsa 1024. The point is that no matter what crypto algorithms are developed and implemented, it's generally trivial for authorized (for whatever value of 'authorized' applies in a given situation) entities to obviate them by simply compromising the endpoints under color of law, if nothing else. If folks are unhappy with the current state of affairs, they ought to concentrate on writing laws, not code. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at leitl.org Sun Sep 8 09:25:43 2013 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 8 Sep 2013 11:25:43 +0200 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" Message-ID: <20130908092543.GO29404@leitl.org> ----- Forwarded message from Gregory Perry ----- Date: Sat, 7 Sep 2013 21:14:47 +0000 From: Gregory Perry To: Phillip Hallam-Baker Cc: "cryptography at metzdowd.com" , ianG Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. And this is exactly why there is no real security on the Internet. Because the IETF and standards committees and working groups are all in reality political fiefdoms and technological monopolies aimed at lining the pockets of a select few companies deemed "worthy" of authenticating user documentation for purposes of establishing online credibility. There is no reason for any of this, and I would once again cite to Bitcoin as an example of how an entire secure online currency standard can be created and maintained in a decentralized fashion without the need for complex hierarchies of quasi-political commercial interests. Encrypting SMTP is trivial, it's all about the standard to make it happen. Encrypting IPv6 was initially a mandatory part of the spec, but then it somehow became discretionary. The nuts and bolts of strong crypto have been around for decades, but the IETF and related standards "powers to be" are more interested in creating a global police state than guaranteeing some semblance of confidential and privacy for Internet users. _______________________________________________ The cryptography mailing list cryptography at metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 From jmamodio at gmail.com Sun Sep 8 10:46:52 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 8 Sep 2013 05:46:52 -0500 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" In-Reply-To: <20130908092543.GO29404@leitl.org> References: <20130908092543.GO29404@leitl.org> Message-ID: Now is pretty clear, Randy is The Mole !!!! ROFL -J On Sun, Sep 8, 2013 at 4:25 AM, Eugen Leitl wrote: > ----- Forwarded message from Gregory Perry > ----- > > Date: Sat, 7 Sep 2013 21:14:47 +0000 > From: Gregory Perry > To: Phillip Hallam-Baker > Cc: "cryptography at metzdowd.com" , ianG < > iang at iang.org> > Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" > > On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: > > Good theory only the CA industry tried very hard to deploy and was > prevented from doing so because Randy Bush abused his position as DNSEXT > chair to prevent modification of the spec to meet the deployment > requirements in .com. > > DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF > followed the clear consensus of the DNSEXT working group and approved the > OPT-IN proposal. The code was written and ready to deploy. > > I told the IESG and the IAB that the VeriSign position was no bluff and > that if OPT-IN did not get approved there would be no deployment in .com. A > business is not going to spend $100million on deployment of a feature that > has no proven market demand when the same job can be done for $5 million > with only minor changes. > > And this is exactly why there is no real security on the Internet. > Because the IETF and standards committees and working groups are all in > reality political fiefdoms and technological monopolies aimed at lining the > pockets of a select few companies deemed "worthy" of authenticating user > documentation for purposes of establishing online credibility. > > There is no reason for any of this, and I would once again cite to Bitcoin > as an example of how an entire secure online currency standard can be > created and maintained in a decentralized fashion without the need for > complex hierarchies of quasi-political commercial interests. > > Encrypting SMTP is trivial, it's all about the standard to make it happen. > Encrypting IPv6 was initially a mandatory part of the spec, but then it > somehow became discretionary. The nuts and bolts of strong crypto have > been around for decades, but the IETF and related standards "powers to be" > are more interested in creating a global police state than guaranteeing > some semblance of confidential and privacy for Internet users. > > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 > > From bmanning at vacation.karoshi.com Sun Sep 8 10:55:41 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 8 Sep 2013 10:55:41 +0000 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: <20130908105541.GA25004@vacation.karoshi.com.> On Sun, Sep 08, 2013 at 04:58:52PM +0900, Randy Bush wrote: > > Quite frankly, all this chatter about technical 'calls to arms' and > > whatnot is pointless and distracting (thereby calling into question > > the motivations behind continued agitation for technical remedies, > > which clearly won't have any effect whatsoever). > > cool. then i presume you will continue to run using rc4 and rsa 1024. > smart folk over there at arbor. > > randy nothing better than clear text. pesky crypto just slows things down. /bill` From eugen at leitl.org Sun Sep 8 14:07:25 2013 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 8 Sep 2013 16:07:25 +0200 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" Message-ID: <20130908140725.GU29404@leitl.org> ----- Forwarded message from "Jeffrey I. Schiller" ----- Date: Sat, 7 Sep 2013 19:52:44 -0400 From: "Jeffrey I. Schiller" To: Gregory Perry Cc: "cryptography at metzdowd.com" , Phillip Hallam-Baker , ianG Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mutt/1.5.21 (2010-09-15) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Sep 07, 2013 at 09:14:47PM +0000, Gregory Perry wrote: > And this is exactly why there is no real security on the Internet. > Because the IETF and standards committees and working groups are all > in reality political fiefdoms and technological monopolies aimed at > lining the pockets of a select few companies deemed "worthy" of > authenticating user documentation for purposes of establishing > online credibility. > ... > Encrypting IPv6 was initially a mandatory part of the spec, > but then it somehow became discretionary. The nuts and bolts of > strong crypto have been around for decades, but the IETF and related > standards "powers to be" are more interested in creating a global > police state than guaranteeing some semblance of confidential and > privacy for Internet users. I?m sorry, but I cannot let this go unchallenged. I was there, I saw it. For those who don?t know, I was the IESG Security Area Director from 1994 - 2003. (by myself until 1998 after which we had two co-AD?s in the Security Area). During this timeframe we formed the TLS working group, the PGP working group and IPv6 became a Draft Standard. Scott Bradner and I decided that security should be mandatory in IPv6, in the hope that we could drive more adoption. The IETF was (and probably still is) a bunch of hard working individuals who strive to create useful technology for the Internet. In particular IETF contributors are in theory individual contributors and not representatives of their employers. Of course this is the theory and practice is a bit ?noisier? but the bulk of participant I worked with were honest hard working individuals. Security fails on the Internet for three important reasons, that have nothing to do with the IETF or the technology per-se (except for point 3). 1. There is little market for ?the good stuff?. When people see that they have to provide a password to login, they figure they are safe... In general the consuming public cannot tell the difference between ?good stuff? and snake oil. So when presented with a $100 ?good? solution or a $10 bunch of snake oil, guess what gets bought. 2. Security is *hard*, it is a negative deliverable. You do not know when you have it, you only know when you have lost it (via compromise). It is therefore hard to show return on investment with security. It is hard to assign a value to something not happening. 2a. Most people don?t really care until they have been personally bitten. A lot of people only purchase a burglar alarm after they have been burglarized. Although people are more security aware today, that is a relatively recent development. 3. As engineers we have totally and completely failed to deliver products that people can use. I point out e-mail encryption as a key example. With today?s solutions you need to understand PK and PKI at some level in order to use it. That is likely requiring a driver to understand the internal combustion engine before they can drive their car. The real world doesn?t work that way. No government conspiracy required. We have seen the enemy and it is... -Jeff _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room E17-110A, 32-392 Cambridge, MA 02139-4307 617.910.0259 - Voice jis at mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSK7xM8CBzV/QUlSsRApyUAKCB6GpP/hUHxtOQNGjSB5FDZS8hFACfVec6 pPw4Xvukq3OqPEkmVZKl0c8= =9/UP -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography at metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 From mysidia at gmail.com Sun Sep 8 15:04:36 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 8 Sep 2013 10:04:36 -0500 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" In-Reply-To: <20130908140725.GU29404@leitl.org> References: <20130908140725.GU29404@leitl.org> Message-ID: On Sun, Sep 8, 2013 at 9:07 AM, Eugen Leitl wrote: > 1. [...] In general the consuming public cannot tell the > difference between ?good stuff? and snake oil. So when presented > with a $100 ?good? solution or a $10 bunch of snake oil, guess > what gets bought. Or there might be 2 good solutions for certain security functions around $100. And 10 different flavors of $90 snake oil,and plenty of $50, $100, and $120 snake oil flavors. The world is full of salespeople and marketers; and the snakeoil salespersons are just as great as the "good stuff" salespeople ---- also, with more resources to devote to sales, than engineering; the snakeoil salespersons have more time and resources available to look at their competitors' merchandising, and make the snakeoil bottles on the store shelves are the ones that look the most appealing to the potential buyers. A wary buyer should not believe the salesperson, but demand a thorough long-term critical review (a 30 day demo of some product is not sufficient duration to discover that it's totally bunk). 2. Security is *hard*, it is a negative deliverable. You do not know > when you have it, you only know when you have lost it (via > compromise). It is therefore hard to show return on investment > with security. It is hard to assign a value to something not > happening. > This is because it doesn't make sense to say that security itself has a ROI in the first place. IT security is risk management --- therefore, in isolation security means nothing: security is a way of mitigating fundamental risks that are improbable events that are nevertheless certain to happen eventually (given enough time) that have an average negative ROI. There is a fundamental tradeoff between risk and return: If you spend NO money on security, lawyers, to help structure the business to avoid liabilities, and other protections such as insurance then you INCREASE return; in the short term, you will most likely have much greater profit, if you don't bother with any insurance, lawyers, or security. It all works fine, until there is a disaster, someone files a lawsuit, or you have a breakin. For example: by not purchasing insurance on your business assets; you avoid spending insurance premium dollars. This increases how much money you make (your return), as long as nothing bad happens. However, not buying insurance, or not paying the costs of security greatly increase the risk that the business incurs a loss because something bad happens. Furthermore, spending a lot of money on security reduces return, BUT also reduces the risk. Security does not have a ROI, but it does have a tradeoff. That tradeoff should be understood using the language of risk management, not profit/loss. And there is no reason people can't understand that.... after all; they do understand, what happens if you don't pay lawyers to help your enterprises comply with the law, or draft successfully binding contracts. You should expect to spend amounts on security per year, commensurate with the costs of insuring those data assets against the liability that would be incurred if they were tampered with or leaked to the public; granted, plenty of orgs are much more likely to have an internet-based security breach than a fire or a flood, therefore, the risk you take on by not spending on security is possibly a larger risk. 2a. Most people don?t really care until they have been personally > bitten. A lot of people only purchase a burglar alarm after they > have been burglarized. Most people purchase homeowners' insurance. Vehicle insurance is mandated by the state in many cases. I wonder if someday; a similar per-PC mandatory purchase will someday be required for computer security. > 3. As engineers we have totally and completely failed to deliver > products that people can use. I point out e-mail encryption as a > key example. With today?s solutions you need to understand PK and > PKI at some level in order to use it. That is likely requiring a > driver to understand the internal combustion engine before they > can drive their car. The real world doesn?t work that way. Yes. This is a total nightmare. Before Joe consumer can send an encrypted mail; he has to either go to some command line and gpg --gen-key or go to Xyz CA corporation, buy a personal SSL certificate for some expensive per-year premium $10 or more... and then go through a lot of trouble to figure out how to import that into the browser, and manually repeat this process every 1 to 3 years that his certificate expires; the process Joe has to go through to S/MIME enable every copy of his mail client on all his different computers, and his webmail provider, is even more complicated. Before anyone can send Joe an encrypted message; Joe somehow has to get all his correspondents to manually import a copy of his certificate. This is clearly miles outside the realm of possibility for the average Windows user. > -Jeff > -- -JH From Derek.Andrew at usask.ca Sun Sep 8 15:54:44 2013 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Sun, 8 Sep 2013 09:54:44 -0600 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> Message-ID: The topic of Canadian network sovereignty has been part of the Canadian conscience since the failure of CANNET back in the 1970s. Canadians citizens, on Canadian soil, already supply feeds directly to the NSA. Rerouting Internet traffic would make no difference. On Sat, Sep 7, 2013 at 3:08 PM, Paul Ferguson wrote: > > A Canadian ISP colleague of mine suggested that the NANOG constituency > might be interested in this, given some recent 'revelations', so I > forward it here for you perusal. > > > > "Preliminary analysis of more than 25,000 traceroutes reveals a > phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian > internet transmissions are routinely routed through the United States. > Canadian originated transmissions that travel to a Canadian destination > via a U.S. switching centre or carrier are subject to U.S. law - > including the USA Patriot Act and FISAA. As a result, these > transmissions expose Canadians to potential U.S. surveillance activities > ? a violation of Canadian network sovereignty." > > > http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html > > Cheers, > > - ferg > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com > > -- Copyright 2013 Derek Andrew (excluding quotations) +1 306 966 4808 Information and Communications Technology University of Saskatchewan Peterson 120; 54 Innovation Boulevard Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 Typed but not read. From mike at mtcc.com Sun Sep 8 17:09:15 2013 From: mike at mtcc.com (Michael Thomas) Date: Sun, 08 Sep 2013 10:09:15 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> <560F18AA-D2EB-41EE-9AB0-21D60EEF73DB@arbor.net> Message-ID: <522CAF3B.2080605@mtcc.com> On 9/8/13 12:58 AM, Randy Bush wrote: >> Quite frankly, all this chatter about technical 'calls to arms' and >> whatnot is pointless and distracting (thereby calling into question >> the motivations behind continued agitation for technical remedies, >> which clearly won't have any effect whatsoever). > cool. then i presume you will continue to run using rc4 and rsa 1024. > smart folk over there at arbor. > Even if you believe that it's pretty futile to try to protect yourself against ~$50b, there's a long tail of others to worry about. Mike From me at anuragbhatia.com Sun Sep 8 19:35:32 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 9 Sep 2013 01:05:32 +0530 Subject: MTR for Android? In-Reply-To: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> References: <62e3308c-9261-4e67-b684-9042cf2a07f8@email.android.com> Message-ID: I use Fing app which gives traceroute (not MTR) and has some additional features like scanning of broadcast for other machines as well as wake on LAN trigger etc. Checkout - https://play.google.com/store/apps/details?id=com.overlook.android.fing&hl=en The only bad side is irritating banner which comes in middle at random times. On Fri, Sep 6, 2013 at 4:03 AM, Jay Ashworth wrote: > Does anybody know if the program has been ported, or re-created there? > > I have searched the market, but not found anything... at least nothing > whose description includes the letters mtr. > - jra > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From me at anuragbhatia.com Sun Sep 8 19:38:00 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 9 Sep 2013 01:08:00 +0530 Subject: Caution! Don't attempt the Postini to Google Apps transition In-Reply-To: <522A3469.5050603@matthew.at> References: <522A3469.5050603@matthew.at> Message-ID: Hi Matthew Interesting experience. >first into a black hole, and then bouncing with permanent failures. What you mean by permanent failures? Can you share error you saw in bounce report? On Sat, Sep 7, 2013 at 1:30 AM, Matthew Kaufman wrote: > TL; DR: Email won't be delivered, No support > > I have two domains that I set up with Postini for spam filtering, and I > was very happy for years. But Google purchased Postini, and has been > increasingly insistent that I migrate to Google Apps. They have a > transition process which is supposedly seamless, and which guarantees that > mail will continue flowing throughout the transition. In reality, all of my > email was offline for 24 hours, first into a black hole, and then bouncing > with permanent failures. > > Calling Google support last night resulted in a long wait to finally talk > to someone who told me that Postini support was too busy and who took down > my name and number for a call back. Never got a call. > > This morning I opened a support ticket via the web site, and two hours > later got a reply suggesting that it might be my MX records. Never mind > that (according to the logs I could see) the mail was still flowing > properly to Postini, passing through there to Google, and then being dumped > at Google. > > When I called to escalate, I found a support agent who couldn't find the > ticket I had opened via the website, and who then tried to transfer me. In > the process, I sat on hold for 30 minutes, then the call was dropped. > > When I called right back, I went through the same phone tree and > authentication process, and reached another agent. When he asked my > problem, and I started to describe it, he said "oh, Postini" and then hung > up on me. > > At that point it had been 24 hours, which is too long to have one's > inbound email getting permanent failures, and so I've set my MX records to > point directly at my own servers and will just live without spam filtering > for a while. In the meantime, I strongly encourage anyone else who cares > about reliable email delivery to avoid my fate. > > Matthew Kaufman > matthew at matthew.at > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From jfmezei_nanog at vaxination.ca Sun Sep 8 19:50:33 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 08 Sep 2013 15:50:33 -0400 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" In-Reply-To: References: <20130908140725.GU29404@leitl.org> Message-ID: <522CD509.5020700@vaxination.ca> With regards to the 10$ snake oil security product versus the real one at $100: since the NSA can break both, they are both worth worth $0 in terms of privacy. >From a business/corporate point of view, there are two aspects: 1- Image: If your weak security has allowed a data breach to become public (such as TJ-Maxx) then you have damage to your image. But TJ-Maxx has survived and average person forgot about millions of credit card numbers having been stolen from its databases. If the NSA snoops on your systems to see what kind of underwear Ossama Bin Ladin buys and where he has them delivered, there is nothing your company can do about it. Either you don't know it is happening and NSA will never make it public (no image problem), or you got a warrant and were forced to do it (some image problem, but you can say your hands were tied and shift blame to NSA) 2- Real cost: if you're a bank, and someone intercepts a letter of credit or payment transaction to find out how much a corporate customer pays for widgets, that customer can sue you for breach of security/confidentiality (since its competitors now know what deal he has negotiated to buy those widgets). The lawsuit against the bank has real costs (not only lawyers, but settlement as well). It becomes easier to cost justify security when you can put real costs to not having security. So risk management is an important factor in both cases. BUT, when you get to general public, the equation changes: For the general public, a burglary is a good analogy. You can easily put value to the stolen TV set and replace it. But this isn't what happens when the NSA spies on your private communications and you have no real measurable damage. The damage you get is akin to losing your family pictures or the feeling of having been violated because someone came into your home and rummage through all your personal stuff and not knowing exactly what they will do with your personal items and why they stole them. Putting a value to this is next to impossible. Risk managememnt becomes impossible, except at the politival level. If the NSA intercepts private emails between a husband and his mistress, the husband can't know if the NSA will ever use this against him. This fear remains because the NSA night hold on to these emails for a long time (or might not). And at the political level, Obama made it clear in a recent speech that he hopes this will blow over and that he will be able to convince americans that the NSA is doing good things. Their political staffers evaluated the risk that this might backfire and figured it wouldn't. This has nothing to do with selection of technology to guard against the NSA' it is all about political public opinion. Here is what the politicians forget: Because the economy is moving to the internet, losing trust in the internet is akin to losing trust in the banking system. I am not sure network operators have much of a choice. Sure, someone like Bell Canada will hopefully review their no-peering policy in Canada (forcing so much traffic to route via USA), but for other networks there isn't much they can do to prevent NSA from accessing any/all data while in transit. What is really needed is for an intelligent debate by politicians on the need to preserve trust in the internet and whether preventing a couple of bombs is really worth the loss of trust and freedom due to implementation of measures worse than what "1984" predicted. Since intelligent debate by politicians is impossible, the other way to change things is to seriously deprive any politician who supports excessive spying by NSA of any money and chance to be re-elected. Imagine the good publicity AT&T and/or Verizon would get if they were to announce that they are ceasing all political contributions to any party or individual politician who supports the indiscriminate data collection done by NSA. And this might be enough to tilt the table and get politicians to start to criticise the NSA and call for measures to limit its spying. From nazgul at marrowbones.com Sun Sep 8 21:21:21 2013 From: nazgul at marrowbones.com (Kee Hinckley) Date: Sun, 8 Sep 2013 17:21:21 -0400 Subject: Yahoo is now recycling handles In-Reply-To: <9fbb82d50743544dbe9e64792d9917eb@mail.dessus.com> References: <9fbb82d50743544dbe9e64792d9917eb@mail.dessus.com> Message-ID: <81A3201B-4795-4039-97CA-0F73C8D4165C@marrowbones.com> On Sep 7, 2013, at 7:58 PM, Keith Medcalf wrote: > > The appropriate party to inform would be the FBI ... The word fraud comes to mind, and millions of 50 centses puts company officers in prison for a long long long time. The charges did indeed expire rather than get posted. None of which excuses Yahoo!'s complete lack of customer support (and broken charge system), but at least there's that. From LarrySheldon at cox.net Sun Sep 8 21:49:08 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 08 Sep 2013 16:49:08 -0500 Subject: Caution! Don't attempt the Postini to Google Apps transition In-Reply-To: References: <522A3469.5050603@matthew.at> Message-ID: <522CF0D4.30403@cox.net> On 9/8/2013 2:38 PM, Anurag Bhatia wrote: > Hi Matthew > > > Interesting experience. > >> first into a black hole, and then bouncing with permanent failures. > > > What you mean by permanent failures? Can you share error you saw in bounce > report? > RFC 2505 Anti-Spam Recommendations February 1999 > > > 1.6. SMTP Return Codes > > SMTP has several classes of Return Codes, see [1] for a discussion: > > o 5xx > is a Permanent Negative Completion reply (Fatal Error) and > results in the mail transfer being terminated and the mail > returned to sender. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From fergdawgster at mykolab.com Sun Sep 8 22:29:56 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 08 Sep 2013 15:29:56 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522CF99F.1070002@people.ops-trust.net> References: <522CF99F.1070002@people.ops-trust.net> Message-ID: <522CFA64.8080707@mykolab.com> Actually Roland is right when he says: > If folks are unhappy with the current state of affairs, they ought to concentrate on writing laws, not code. Randy is being his usual self and playing devils advocate, which is fine, but doesn't move the ball (or is simply self-serving). In any event, we *all* need to raise our game, because we are not as clever as we think we are. - ferg On 9/8/2013 1:12 AM, Dobbins, Roland wrote: > On Sep 8, 2013, at 2:58 PM, Randy Bush wrote: > >> >cool. then i presume you will continue to run using rc4 and rsa 1024. > The point is that no matter what crypto algorithms are developed and implemented, it's generally trivial for authorized (for whatever value of 'authorized' applies in a given situation) entities to obviate them by simply compromising the endpoints under color of law, if nothing else. > > If folks are unhappy with the current state of affairs, they ought to concentrate on writing laws, not code. -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From randy_94108 at yahoo.com Sun Sep 8 22:30:18 2013 From: randy_94108 at yahoo.com (Randy) Date: Sun, 8 Sep 2013 15:30:18 -0700 (PDT) Subject: Yahoo is now recycling handles In-Reply-To: <81A3201B-4795-4039-97CA-0F73C8D4165C@marrowbones.com> References: <9fbb82d50743544dbe9e64792d9917eb@mail.dessus.com> <81A3201B-4795-4039-97CA-0F73C8D4165C@marrowbones.com> Message-ID: <1378679418.84373.YahooMailNeo@web184702.mail.ne1.yahoo.com> ----- Original Message ----- > From: Kee Hinckley > To: "nanog at nanog.org list" > Cc: > Sent: Sunday, September 8, 2013 2:21 PM > Subject: Re: Yahoo is now recycling handles > > > On Sep 7, 2013, at 7:58 PM, Keith Medcalf wrote: > >> >> The appropriate party to inform would be the FBI ... The word fraud comes > to mind, and millions of 50 centses puts company officers in prison for a long > long long time. > > The charges did indeed expire rather than get posted. None of which excuses > Yahoo!'s complete lack of customer support (and broken charge system), but > at least there's that. > So, Yahoo *actually* had a working cust-support at some point? ? I obviously missed that boat. I have had three perfectly valid handles reclaimed in the last three weeks ( my yahoo addr.book is tiny!) I just let the holders of said handles know the implications of what happened and asked they let everyone else know NOT to use said handle at yahoo ./Randy From dougb at dougbarton.us Sun Sep 8 22:44:05 2013 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 08 Sep 2013 15:44:05 -0700 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" In-Reply-To: <20130908092543.GO29404@leitl.org> References: <20130908092543.GO29404@leitl.org> Message-ID: <522CFDB5.3060901@dougbarton.us> On 09/08/2013 02:25 AM, Eugen Leitl wrote: > ----- Forwarded message from Gregory Perry ----- > > Date: Sat, 7 Sep 2013 21:14:47 +0000 > From: Gregory Perry > To: Phillip Hallam-Baker > Cc: "cryptography at metzdowd.com" , ianG > Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" > > On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: > > Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. > > DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. > > I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. I was also there in 2003, and for a long time before that, and was also one of the voices that was saying that we needed opt-in, and protection from zone walking, or else the thing wouldn't fly. I don't recall that any 1 person was the reason those things didn't happen sooner than they did; in fact I recall near-universal sentiment that zone walking was a non-issue, and that opt-in defeated the very nature of what DNSSEC was trying to accomplish. Fast forward to my time at IANA in 2004 and after considerable behind the scenes organization a coalition of TLD registries came forward and said that they would not deploy DNSSEC without those 2 features, and were willing to dedicate the resources to create them. So it was not 1 person who stopped DNSSEC deployment, and it wasn't 1 person who made it happen. Your larger point about fiefdoms and oligarchies in the IETF is, however, tragically accurate. The blindness of the DNSSEC literati to the real-world needs was a huge part of what caused the delay in deployment on the authoritative side, and the malaise caused by the decade+ of fighting to get it out the door is a big contributor to what's preventing any real solution to the last mile problem (which is what it takes to make DNSSEC really useful). Doug From mpalmer at hezmatt.org Sun Sep 8 21:45:08 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 9 Sep 2013 07:45:08 +1000 Subject: Opening Discussion: Speculation on "BULLRUN" In-Reply-To: <522CD509.5020700@vaxination.ca> References: <20130908140725.GU29404@leitl.org> <522CD509.5020700@vaxination.ca> Message-ID: <20130908214508.GE31882@hezmatt.org> On Sun, Sep 08, 2013 at 03:50:33PM -0400, Jean-Francois Mezei wrote: > Here is what the politicians forget: > Because the economy is moving to the internet, losing trust in the > internet is akin to losing trust in the banking system. If the last five years have left anyone with a shred of trust in the banking system, then the Internet is in no danger of becoming untrusted due to the recent revelations. - Matt From Valdis.Kletnieks at vt.edu Mon Sep 9 01:08:32 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 08 Sep 2013 21:08:32 -0400 Subject: Yahoo is now recycling handles In-Reply-To: Your message of "Sat, 07 Sep 2013 17:34:36 -0600." <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> References: <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> Message-ID: <7995.1378688912@turing-police.cc.vt.edu> On Sat, 07 Sep 2013 17:34:36 -0600, "Keith Medcalf" said: > Sometimes, it is a deliberate feature which is deliberately used to attack > the visitors of a web site. Prime example is the DHS. I must have missed this one. Citation please? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From alex.buie at frozenfeline.net Mon Sep 9 02:04:14 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Sun, 8 Sep 2013 19:04:14 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <7995.1378688912@turing-police.cc.vt.edu> References: <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> <7995.1378688912@turing-police.cc.vt.edu> Message-ID: Recent TOR thing with freedomhosting (?) come to mind... On Sun, Sep 8, 2013 at 6:08 PM, wrote: > On Sat, 07 Sep 2013 17:34:36 -0600, "Keith Medcalf" said: > > > Sometimes, it is a deliberate feature which is deliberately used to > attack > > the visitors of a web site. Prime example is the DHS. > > I must have missed this one. Citation please? > > From joly at punkcast.com Mon Sep 9 06:47:24 2013 From: joly at punkcast.com (Joly MacFie) Date: Mon, 9 Sep 2013 02:47:24 -0400 Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" In-Reply-To: <522CFDB5.3060901@dougbarton.us> References: <20130908092543.GO29404@leitl.org> <522CFDB5.3060901@dougbarton.us> Message-ID: In case you missed it, Jari Arkko, Chair of the IETF and Stephen Farrell, IETF Security Area Director, just posted: http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From eugen at leitl.org Mon Sep 9 11:07:42 2013 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 9 Sep 2013 13:07:42 +0200 Subject: [cryptography] New NSA Slides and Details Released last night via Fantastico (BR) Message-ID: <20130909110742.GL10405@leitl.org> "Based on this slide, it appears that the bandwidth providers are dumping the traffic at core routers directly to the NSA." ----- Forwarded message from David D ----- Date: Mon, 9 Sep 2013 12:56:17 +0200 From: David D To: 'Crypto discussion list' Subject: Re: [cryptography] New NSA Slides and Details Released last night via Fantastico (BR) X-Mailer: Microsoft Office Outlook 12.0 http://g1.globo.com/fantastico/noticia/2013/09/nsa-documents-show-united-sta tes-spied-brazilian-oil-giant.html No millisecond counter: 1:49 US-983 Stormbrew - Fiber connections 1:49 US-983 Stormbrew - "KEY CORPORATE PARTNER WITH ACCESS TO INTERNATIONAL CABLES, ROUTERS, AND SWITCHES". (# traceroute google.com) 2:07 - "QUERY BY CERTIFICATE META DATA" 2:07 - "Private keys of Diginotar stolen by hacker" FLYING PIG ... Launch a MITM attack. 2:08 - mail.ru and server IP: 94.100.104.14 This site has broken out some of the screenshots from the video: http://leaksource.wordpress.com/2013/09/09/economic-espionage-nsa-spies-on-b razil-oil-giant-petrobras/ "How the attack was done:" image is most interesting. http://leaksource.files.wordpress.com/2013/09/nsa-brazil-5.png Based on this slide, it appears that the bandwidth providers are dumping the traffic at core routers directly to the NSA. -----Original Message----- From: cryptography [mailto:cryptography-bounces at randombit.net] On Behalf Of David D Sent: Monday, September 09, 2013 12:07 PM To: 'Crypto discussion list' Subject: Re: [cryptography] New NSA Slides and Details Released last night via Fantastico (BR) Lots of gems in this video: http://g1.globo.com/fantastico/noticia/2013/09/nsa-documents-show-united-sta tes-spied-brazilian-oil-giant.html _______________________________________________ cryptography mailing list cryptography at randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From wmaton at ottix.net Mon Sep 9 12:06:24 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Mon, 9 Sep 2013 08:06:24 -0400 (EDT) Subject: AlbertaIX - no longer a Cybera project? In-Reply-To: <201309072022.r87KMGvI029687@cvs.openbsd.org> References: <201309072022.r87KMGvI029687@cvs.openbsd.org> Message-ID: On Sat, 7 Sep 2013, Theo de Raadt wrote: > Mike Leber wrote: >> Facility and parties willing, hopefully there will be a YYCIX switch in >> Cybera. > > Interesting idea, how the heck did I miss that. Indeed, if multiple IX pops in any given locale makes sense, then it is worth pursuing - providing there is a benefactor willing to aid in the cross connect between the pops or an economic model enabling the IXP to do it itself. > In Canada, the other collision preventing exchanges from showing up is > the CANARIE content peering model, which by providing free content > access to schools and such takes many (young bandwidth hungry) > eyeballs out of the equation for IX development and growth: This isn't a new idea actually. It was first proposed on the CANARIE techs mailing list way back in mid-2000 I believe. In any case it is a replication of the Internet2 CDS effort. Not sure how well this has caught on, but since CANARIE are now charging user fees, it remains to be seen how far it goes. > Time for change? There once was a proposal back in the day that CANARIE POPs should be co-located at either universities (offering a neutral venue for everyone) or at least with other IXPs....Oh, what IXPs? The idea quickly evolved to CANARIE establishing some IXPs but this was very quickly shot down (IIRC) by the then CANARIE board as it was seen to be interference by CANARIE in municipal affairs - because back then municipal dark fibre builds were all the rage. WHET those BTW? In any case, I did persuade CANARIE to peer to at least one IXP in Canada to pick peering instead of doing a backhaul for all the peerings into the USA. My little bit of contribution to the IXP cause. However, given the science and academic population in CANARIE's network, I do know it is felt in some quarters to be of no real benefit to peer at IXPs. wfms From starwars1070 at gmail.com Mon Sep 9 01:55:42 2013 From: starwars1070 at gmail.com (s) Date: Sun, 08 Sep 2013 18:55:42 -0700 Subject: Google support contact Message-ID: <522D2A9E.3080400@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 can someone from the Google support team please contact me off list -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSLSqeAAoJEENc8MKW+7m4xXsH/2jfHIEDJ3kKZvbkSQp2mE3s VcPm/l8qmQ89Olmu8kNmGPcBbnjn/EIu42OnuE3GHwsgyJ06KM5aiacL8X2YAVSn EmJXZvfWQMQqpWV+yaadbRr3EwEkGnh0T/dYx2edpY5M9ggltTdUjVzgHRwSmeH1 9/WheIY/rnzxDh5wFascJi+sPuHr9sga4M4jGsX6+uA/wVh9bwk3kDoyb71MXG9R UzaDnq3/AL5bS4pOt6Skl67f6NK0gwEx93Jbtgei7OpKWb9NKI/qL+vcRvlaEWp9 cIdofWBMF2eQG7nt2d1Nsl/vwG4bkBrAdFJyxIlDHs/ykkNXoGaMR/hxixFA0Q0= =5C5x -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Mon Sep 9 13:31:05 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Sep 2013 09:31:05 -0400 Subject: Yahoo is now recycling handles In-Reply-To: Your message of "Sun, 08 Sep 2013 19:04:14 -0700." References: <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> <7995.1378688912@turing-police.cc.vt.edu> Message-ID: <41592.1378733465@turing-police.cc.vt.edu> On Sun, 08 Sep 2013 19:04:14 -0700, Alex Buie said: > Recent TOR thing with freedomhosting (?) come to mind... That one appears to have been the FBI, which is DOJ not DHS. If you have evidence to the contrary, feel free to bring it out in the open. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From johnl at iecc.com Mon Sep 9 13:42:37 2013 From: johnl at iecc.com (John Levine) Date: 9 Sep 2013 13:42:37 -0000 Subject: Is the FBI's DNSSEC no longer broken? In-Reply-To: <20130903212813.4637.qmail@joyce.lan> Message-ID: <20130909134237.30625.qmail@joyce.lan> >I heard back, seems like I found someone at the FBI who was able to >explain the problem to Neustar (DNS software provider) who say they >will fix it. Seems to be fixed now. Here's the formerly broken query, via unbound: ; <<>> DiG 9.8.3-P4 <<>> mail.ic.fbi.gov aaaa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24041 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mail.ic.fbi.gov. IN AAAA ;; AUTHORITY SECTION: fbi.gov. 600 IN SOA ns1.fbi.gov. dns-admin.fbi.gov. 2013090301 7200 3600 2592000 43200 fbi.gov. 600 IN RRSIG SOA 7 2 600 20131202142044 20130903142044 32497 fbi.gov. lGgY8jWxYyxqi/pezCXZpSnY7B2UqDTvOQMrxt+REnd7rCHs2qU2U5k3 qnfAOVbPr2lEOVaChT9i+tElTQNfZxrmg0DvR+Nluj9DBD6kfwPnGdOT iBZJvrEhNsq5fY0DJ3jF7RMzr9YtA+Jl1T6bM+aWiUgXn9zvFT39+ReJ vA0= 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR.fbi.gov. 41250 IN NSEC3 1 0 10 BBAB 97S2G907NEFOJ79P721E4FEQ9LR3IT1S A RRSIG 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR.fbi.gov. 41250 IN RRSIG NSEC3 7 3 43200 20131202142044 20130903142044 32497 fbi.gov. ZqMr4lUifz0n46YCL/s/qa3iMp0Hz8OhIuYC/uDgWzwPJsD26VTECG0G aG4xWUlmumfm6GLMppo07keXa273bsJEYXgXVhTEWHMbDqrc5xhBPykG C53E8N36dcmzdnfN+v7cVnwWXdPOKMrIBPrZhBuHD2qT0QepAgdo8Aoa lgQ= ;; Query time: 161 msec ;; SERVER: 192.168.80.2#53(192.168.80.2) ;; WHEN: Mon Sep 9 09:41:43 2013 ;; MSG SIZE rcvd: 509 From jason at lixfeld.ca Mon Sep 9 14:43:12 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 9 Sep 2013 10:43:12 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> Message-ID: That notwithstanding, it's stupid to send traffic to/from one of the large $your_region/country incumbents via $not_your_region/country. It's just not good Internet. You make enough money already. Be a good netizen. It pays more in the long run and that's all you're really after for your shareholders anyway, right? On 2013-09-08, at 11:54 AM, Derek Andrew wrote: > The topic of Canadian network sovereignty has been part of the Canadian > conscience since the failure of CANNET back in the 1970s. > > Canadians citizens, on Canadian soil, already supply feeds directly to the > NSA. Rerouting Internet traffic would make no difference. > > > > > > > > On Sat, Sep 7, 2013 at 3:08 PM, Paul Ferguson wrote: > >> >> A Canadian ISP colleague of mine suggested that the NANOG constituency >> might be interested in this, given some recent 'revelations', so I >> forward it here for you perusal. >> >> >> >> "Preliminary analysis of more than 25,000 traceroutes reveals a >> phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian >> internet transmissions are routinely routed through the United States. >> Canadian originated transmissions that travel to a Canadian destination >> via a U.S. switching centre or carrier are subject to U.S. law - >> including the USA Patriot Act and FISAA. As a result, these >> transmissions expose Canadians to potential U.S. surveillance activities >> ? a violation of Canadian network sovereignty." >> >> >> http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html >> >> Cheers, >> >> - ferg >> >> >> -- >> Paul Ferguson >> Vice President, Threat Intelligence >> Internet Identity, Tacoma, Washington USA >> IID --> "Connect and Collaborate" --> www.internetidentity.com >> >> > > > -- > Copyright 2013 Derek Andrew (excluding quotations) > > +1 306 966 4808 > Information and Communications Technology > University of Saskatchewan > Peterson 120; 54 Innovation Boulevard > Saskatoon,Saskatchewan,Canada. S7N 2V3 > Timezone GMT-6 > > Typed but not read. From allenmckinleykitchen at gmail.com Mon Sep 9 15:22:42 2013 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Mon, 9 Sep 2013 11:22:42 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> Message-ID: <52D803DC-6F1E-446E-988B-5307762A6459@gmail.com> I'm confident that someone else may point this out, but I feel this is important enough to weigh in on .. Respectfully, I must disagree with any philosophy that perpetuates the archaic concept of political boundaries in the context of information flow. Calling it "stupid" to send traffic on any particular route because that route crosses political boundaries reflects a surrender to an old way of thought. While I can agree that the fact of crossing political boundaries introduces a very unwelcome artifact of exposing that traffic to adverse political effects, that doesn't mean that the desirable response is one of returning to nationalistic silos. Instead, the way forward is to protect the traffic rather than the boundaries. Due to political realities, that may indeed mean that a intra-national backup path is necessary. But to my mind, what's "just not good Internet" is the artificial restriction of traffic to solely intra-national primary paths. That mindset reflects a territoriality that's not our friend; I still dream of a fully interconnected world. So, I respectfully suggest that we work on fixing the problems and vulnerabilities that arise from the interconnectedness rather than hunkering down and fragmenting / forking. Yes, these are shameful and terrible problems that have come to our attention right now; still, we can move forward better together than apart, don't you think? ..Allen On Sep 9, 2013, at 10:43, Jason Lixfeld wrote: > That notwithstanding, it's stupid to send traffic to/from one of the large $your_region/country incumbents via $not_your_region/country. It's just not good Internet. You make enough money already. Be a good netizen. It pays more in the long run and that's all you're really after for your shareholders anyway, right? > > On 2013-09-08, at 11:54 AM, Derek Andrew wrote: > >> The topic of Canadian network sovereignty has been part of the Canadian >> conscience since the failure of CANNET back in the 1970s. >> >> Canadians citizens, on Canadian soil, already supply feeds directly to the >> NSA. Rerouting Internet traffic would make no difference. >> >> >> >> >> >> >> >> On Sat, Sep 7, 2013 at 3:08 PM, Paul Ferguson wrote: >> >>> >>> A Canadian ISP colleague of mine suggested that the NANOG constituency >>> might be interested in this, given some recent 'revelations', so I >>> forward it here for you perusal. >>> >>> >>> >>> "Preliminary analysis of more than 25,000 traceroutes reveals a >>> phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian >>> internet transmissions are routinely routed through the United States. >>> Canadian originated transmissions that travel to a Canadian destination >>> via a U.S. switching centre or carrier are subject to U.S. law - >>> including the USA Patriot Act and FISAA. As a result, these >>> transmissions expose Canadians to potential U.S. surveillance activities >>> ? a violation of Canadian network sovereignty." >>> >>> >>> http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html >>> >>> Cheers, >>> >>> - ferg >>> >>> >>> -- >>> Paul Ferguson >>> Vice President, Threat Intelligence >>> Internet Identity, Tacoma, Washington USA >>> IID --> "Connect and Collaborate" --> www.internetidentity.com >> >> >> -- >> Copyright 2013 Derek Andrew (excluding quotations) >> >> +1 306 966 4808 >> Information and Communications Technology >> University of Saskatchewan >> Peterson 120; 54 Innovation Boulevard >> Saskatoon,Saskatchewan,Canada. S7N 2V3 >> Timezone GMT-6 >> >> Typed but not read. > > From mikea at mikea.ath.cx Mon Sep 9 15:58:55 2013 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 9 Sep 2013 10:58:55 -0500 Subject: US and UK spy agencies defeat privacy and security on the internet In-Reply-To: References: Message-ID: <20130909155855.GB33884@mikea.ath.cx> On Thu, Sep 05, 2013 at 07:12:36PM +0000, Warren Bailey wrote: > Anyone else see this coming? > > US and UK spy agencies defeat privacy and security on the internet > > http://gu.com/p/3thvv Yes, long, long ago. I just didn't expect to see it revealed. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From alex.buie at frozenfeline.net Mon Sep 9 17:37:14 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Mon, 9 Sep 2013 10:37:14 -0700 Subject: Yahoo is now recycling handles In-Reply-To: <41592.1378733465@turing-police.cc.vt.edu> References: <87dc075154bd9c4db6b81cbb6f19819c@mail.dessus.com> <7995.1378688912@turing-police.cc.vt.edu> <41592.1378733465@turing-police.cc.vt.edu> Message-ID: Whoops, my bad. Misparsed that acronym. On Mon, Sep 9, 2013 at 6:31 AM, wrote: > On Sun, 08 Sep 2013 19:04:14 -0700, Alex Buie said: > > > Recent TOR thing with freedomhosting (?) come to mind... > > That one appears to have been the FBI, which is DOJ not DHS. If you have > evidence to the contrary, feel free to bring it out in the open. > > > From leo.vegoda at icann.org Mon Sep 9 17:02:59 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 9 Sep 2013 10:02:59 -0700 Subject: One block of AS Numbers allocated to the RIPE NCC Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E16F5A77@EXVPMBX100-1.exc.icann.org> Hi, The IANA AS Numbers registry has been updated to reflect the allocation of one block of 1,024 AS Numbers to the RIPE NCC in September 2013: 61952-62463 Assigned by RIPE NCC whois.ripe.net 2013-09-09 199680-200191 Assigned by RIPE NCC whois.ripe.net 2013-09-09 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/ Regards, Leo Vegoda ICANN IANA -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From phil.gardnerjr at gmail.com Mon Sep 9 17:50:49 2013 From: phil.gardnerjr at gmail.com (Phil Gardner) Date: Mon, 09 Sep 2013 13:50:49 -0400 Subject: US and UK spy agencies defeat privacy and security on the internet In-Reply-To: <20130909155855.GB33884@mikea.ath.cx> References: <20130909155855.GB33884@mikea.ath.cx> Message-ID: <522E0A79.9010104@gmail.com> On 09/09/2013 11:58 AM, Mike A wrote: > On Thu, Sep 05, 2013 at 07:12:36PM +0000, Warren Bailey wrote: >> Anyone else see this coming? >> >> US and UK spy agencies defeat privacy and security on the internet >> >> http://gu.com/p/3thvv > > Yes, long, long ago. I just didn't expect to see it revealed. > This is really only a 'work-around' by the NSA, meaning they get around strong encryption by going directly to the source of the unencrypted data (eg. google/yahoo/M$ servers), or by potentially posing as a "trusted" CA. Like Snowden said back in June, good encryption still works. There still isn't enough compute power available to bruteforce open-spec encryption, using peer-reviewed, popular open source software. I say "popular" because it should be a project in active development that has the code monitored and reviewed often (I'm no software engineer, so I can't read source code). PGP still works...assuming the NSA already doesn't have a backdoor in your modem/chipset firmware (since there aren't any free firmware/libs for any modern SoC that I know of)...or a backdoor trojan on your system...or a super secret root kit on your old Fedora Core 2 system (swear I don't have any Fedora Core systems left..). Moral of the story, stay away from the centralized services and commercial encryption software. And write your own custom firmware for you phone's wifi/cell chip. Start by helping these guys out - http://replicant.us/ ;) -- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 From joelja at bogus.com Mon Sep 9 18:29:34 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 09 Sep 2013 11:29:34 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> Message-ID: <522E138E.9040809@bogus.com> On 9/9/13 7:43 AM, Jason Lixfeld wrote: > That notwithstanding, it's stupid to send traffic to/from one of the > large $your_region/country incumbents via $not_your_region/country. > It's just not good Internet. yyz-yvr is faster via the united states. physics doesn't respect poltical boundries. You make enough money already. Be a > good netizen. It pays more in the long run and that's all you're > really after for your shareholders anyway, right? > > On 2013-09-08, at 11:54 AM, Derek Andrew > wrote: > >> The topic of Canadian network sovereignty has been part of the >> Canadian conscience since the failure of CANNET back in the 1970s. >> >> Canadians citizens, on Canadian soil, already supply feeds directly >> to the NSA. Rerouting Internet traffic would make no difference. >> >> >> >> >> >> >> >> On Sat, Sep 7, 2013 at 3:08 PM, Paul Ferguson >> wrote: >> >>> >>> A Canadian ISP colleague of mine suggested that the NANOG >>> constituency might be interested in this, given some recent >>> 'revelations', so I forward it here for you perusal. >>> >>> >>> >>> "Preliminary analysis of more than 25,000 traceroutes reveals a >>> phenomenon we call ?boomerang routing? whereby >>> Canadian-to-Canadian internet transmissions are routinely routed >>> through the United States. Canadian originated transmissions that >>> travel to a Canadian destination via a U.S. switching centre or >>> carrier are subject to U.S. law - including the USA Patriot Act >>> and FISAA. As a result, these transmissions expose Canadians to >>> potential U.S. surveillance activities ? a violation of Canadian >>> network sovereignty." >>> >>> >>> http://lawprofessors.typepad.com/media_law_prof_blog/2013/09/routing-internet-transmission-across-the-canada-us-border-and-us-surveillance-activities.html >>> >>> >>> Cheers, >>> >>> - ferg >>> >>> >>> -- Paul Ferguson Vice President, Threat Intelligence Internet >>> Identity, Tacoma, Washington USA IID --> "Connect and >>> Collaborate" --> www.internetidentity.com >>> >>> >> >> >> -- Copyright 2013 Derek Andrew (excluding quotations) >> >> +1 306 966 4808 Information and Communications Technology >> University of Saskatchewan Peterson 120; 54 Innovation Boulevard >> Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 >> >> Typed but not read. > > > From jabley at hopcount.ca Mon Sep 9 19:16:05 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 9 Sep 2013 15:16:05 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522E138E.9040809@bogus.com> References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> Message-ID: On 2013-09-09, at 14:29, joel jaeggli wrote: > On 9/9/13 7:43 AM, Jason Lixfeld wrote: >> That notwithstanding, it's stupid to send traffic to/from one of the >> large $your_region/country incumbents via $not_your_region/country. >> It's just not good Internet. > > yyz-yvr is faster via the united states. physics doesn't respect > poltical boundries. Not only physics, but geometry. Vancouver is further north than Seattle, but Toronto is further south than Portland. http://www.gcmap.com/mapui?P=YYZ-YVR Joe From m.hallgren at free.fr Mon Sep 9 19:43:50 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 09 Sep 2013 21:43:50 +0200 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> Message-ID: <522E24F6.8050501@free.fr> Le 09/09/2013 21:16, Joe Abley a ?crit : > On 2013-09-09, at 14:29, joel jaeggli wrote: > >> On 9/9/13 7:43 AM, Jason Lixfeld wrote: >>> That notwithstanding, it's stupid to send traffic to/from one of the >>> large $your_region/country incumbents via $not_your_region/country. >>> It's just not good Internet. >> yyz-yvr is faster via the united states. physics doesn't respect >> poltical boundries. > Not only physics, but geometry. Vancouver is further north than Seattle, but Toronto is further south than Portland. > > http://www.gcmap.com/mapui?P=YYZ-YVR Fiber path along great circle? Cool case. :) mh > > > Joe > > From joelja at bogus.com Mon Sep 9 19:57:46 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 09 Sep 2013 12:57:46 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522E24F6.8050501@free.fr> References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> <522E24F6.8050501@free.fr> Message-ID: <522E283A.8090507@bogus.com> On 9/9/13 12:43 PM, Michael Hallgren wrote: > Le 09/09/2013 21:16, Joe Abley a ?crit : >> On 2013-09-09, at 14:29, joel jaeggli wrote: >> >>> On 9/9/13 7:43 AM, Jason Lixfeld wrote: >>>> That notwithstanding, it's stupid to send traffic to/from one of the >>>> large $your_region/country incumbents via $not_your_region/country. >>>> It's just not good Internet. >>> yyz-yvr is faster via the united states. physics doesn't respect >>> poltical boundries. >> Not only physics, but geometry. Vancouver is further north than Seattle, but Toronto is further south than Portland. >> >> http://www.gcmap.com/mapui?P=YYZ-YVR > > Fiber path along great circle? Cool case. :) YYZ-CHI-MSP-SEA-YVR is close enough. this is BNSF vs CN > mh > >> >> >> Joe >> >> > > From dhc2 at dcrocker.net Mon Sep 9 20:12:53 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 09 Sep 2013 13:12:53 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522B95CF.2090206@mykolab.com> Message-ID: <522E2BC5.7060004@dcrocker.net> On 9/7/2013 5:33 PM, Harald Koch wrote: > On 7 September 2013 17:08, Paul Ferguson wrote: >> "Preliminary analysis of more than 25,000 traceroutes reveals a >> phenomenon we call ?boomerang routing? whereby Canadian-to-Canadian >> internet transmissions are routinely routed through the United States. > > I sincerely hope that nobody in Canada is surprised by this, since it was > already an issue in 1994 (when I was at CA*net). Much farther back than that. In 1985 I was working in Toronto and did a proposal for a national X.25 network. The pragmatics for reliability were simple at a national scale: Essentially all Canadian telecom links went through a few common sites across the country; if you wanted redundancy you had to have a second, independent path through the US. Given that most Canadian population occupies a relatively thin band (close to the US border), this topological fragility was/is largely inherent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fergdawgster at mykolab.com Tue Sep 10 08:34:02 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 10 Sep 2013 01:34:02 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522ED933.2060503@people.ops-trust.net> References: <522ED933.2060503@people.ops-trust.net> Message-ID: <522ED97A.1080405@mykolab.com> On 9/9/2013 11:29 AM, joel jaeggli responded with a "smart guy" answer: > On 9/9/13 7:43 AM, Jason Lixfeld wrote: >> >That notwithstanding, it's stupid to send traffic to/from one of the >> >large $your_region/country incumbents via $not_your_region/country. >> >It's just not good Internet. > yyz-yvr is faster via the united states. physics doesn't respect > poltical boundries. There are still a lot of people that care about the sheer principle of the issue. Please do not discount that with math. - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From richih.mailinglist at gmail.com Tue Sep 10 14:10:23 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 10 Sep 2013 16:10:23 +0200 Subject: Direct sales contacts to local loop providers in NYC Message-ID: Dear all, I have received a lot of off-list mail as a result of my last email, so I figured I would try the same approach local loops. We seem to be unable to get past the silk screen of residential, private lines with most carriers of local loops within NYC. Specifically, we are looking for one 10M line in Manhattan as of right now, but we already have new deals in our pipeline and wouldn't make the jump across the pond if we didn't see steady long-term growth in the future. If anyone has contact with the right sales people (or the right sales people lurk on this list), please feel free to contact me. Thanks, Richard From ingrid at ripe.net Tue Sep 10 14:36:44 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 10 Sep 2013 16:36:44 +0200 Subject: New AS Number Block allocated to the RIPE NCC Message-ID: <522F2E7C.5020009@ripe.net> Dear Colleagues, The RIPE NCC has received the following AS Number Block from the IANA in September 2013. 61952-62463 199680-200191 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC From jfmezei_nanog at vaxination.ca Tue Sep 10 16:29:21 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 10 Sep 2013 12:29:21 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> Message-ID: <522F48E1.1020203@vaxination.ca> On 13-09-09 15:16, Joe Abley wrote: > Not only physics, but geometry. Vancouver is further north than Seattle, but Toronto is further south than Portland. It is about sovereignty and the ability of one nation to decide for itself. In the past, because people were blind to the NSA operations, it didn't matter so much. But with past revelations, will the market start to demand routes that avoid the USA if the destination is not the USA ? Could the government set policies that end up making within-canada transit and peering more competitive than buying transit through the USA ? Lets reverse the situation for half a second. Say most traffic from USA to USA were to pass through Canada and Canada had the ability to spy on all USA traffic, including emails between congressman and their mistresses. Do you think the USA would let another nation spy on its traffic for half a second ? How can Bombardier compete against Boeing when the NSA captures Bombardier's emails etc and could potentially hand them over to Boeing? From woody at pch.net Tue Sep 10 17:27:15 2013 From: woody at pch.net (Bill Woodcock) Date: Tue, 10 Sep 2013 10:27:15 -0700 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <522F48E1.1020203@vaxination.ca> References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> <522F48E1.1020203@vaxination.ca> Message-ID: On Sep 10, 2013, at 9:29 AM, Jean-Francois Mezei wrote: > Will the market start to demand routes that avoid the USA if the destination is not the USA ? Unlikely, all else being equal. The market demands the least expensive routes. Which is why we push for new IXPs on the Canadian side of the border, so that the _cheapest_ route will also be the _shortest_ route, and will remain within Canadian jurisdiction and the purview of Canadian personal privacy law, for instance. > It is about sovereignty and the ability of one nation to decide for itself. > Could the government set policies that end up making within-canada > transit and peering more competitive than buying transit through the USA ? Note that this is an entirely different question, orthogonal to markets and economics. It is within the power of the Canadian sovereign government to do whatever wiretaps it likes within Canada, and share that information with other governments, for instance, and neither shortest paths nor least expensive paths will have any effect on that. That said, regulatory best-practice is generally held to be to either keep hands off the Internet entirely, or to make an ISP class license requirement that every service provider network deliver traffic that has source and destination addresses within a region, without passing the traffic across the border of the region. That's a technology-neutral way of saying that if you have a customer in a region, and someone else has a customer in the same region, you and they had better figure out a way of delivering that traffic through peering or local transit. > Lets reverse the situation for half a second. Say most traffic from USA > to USA were to pass through Canada and Canada had the ability to spy on > all USA traffic, including emails between congressman and their mistresses. > Do you think the USA would let another nation spy on its traffic for > half a second ? Happens all the time. China Telecom has routers within the U.S. borders, and offers domestic routes across the U.S. Stands to reason that France Telecom, Deutsche Telekom, et cetera, would be doing the same thing for their respective sovereigns. All of this is just routine power-struggle, it's not an all-or-nothing thing, and absolutes are of little value in the discussion. > How can Bombardier compete against Boeing when the NSA captures > Bombardier's emails etc and could potentially hand them over to Boeing? The theory was that, paraphrasing _Brazil_, "this is the Department of Records, not the Department of Information Retrieval." Theoretically, the countries that collected and shared information did so for the benefit of the sovereign, not the benefit of the people or the benefit of capital, and did not share what they collected with the private sector. That has, however, been abused before: http://yro.slashdot.org/story/00/02/09/1845227/france-sues-us-and-uk-over-echelon Also of note: http://en.wikipedia.org/wiki/Canada?France_relations#Saint_Pierre_and_Miquelon_boundary_dispute So, not meaning to be a downer here, just pointing out that we should all be doing what we can, and not wasting too much energy on shocked outrage at the misbehavior of others. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wwaites at tardis.ed.ac.uk Tue Sep 10 17:51:21 2013 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Tue, 10 Sep 2013 18:51:21 +0100 (BST) Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522F48E1.1020203@vaxination.ca> Message-ID: <20130910.185121.145639853.wwaites@tardis.ed.ac.uk> On Tue, 10 Sep 2013 10:27:15 -0700, Bill Woodcock said: > or to make an ISP class license requirement that every service > provider network deliver traffic that has source and destination > addresses within a region, without passing the traffic across > the border of the region. That's a technology-neutral way of > saying that if you have a customer in a region, and someone else > has a customer in the same region, you and they had better > figure out a way of delivering that traffic through peering or > local transit. That's historically the way it was in Canada, although it was original phrased in terms of the telegraph and persisted up until the beginnings of the commercial Internet when the rule was abolished. It's also the reason why, for example, the old trans-atlantic cables went from the UK to Nova Scotia before New York even though the bulk of the traffic was UK-US. Theoretically, traffic within the empire was not supposed to cross a third border. I believe the rationale behind this was to prevent eavesdropping. I have a pet theory that this rule was one of the main reasons that Canada has such a well developed telecommunications industry -- it was forced by law to develop it indiginously rather than just dumping telephone calls across the border into the 'states, which probably would have made more economic sense. When the rule was abolished in the early 1990s it wasn't clear if it should or should not apply to Internet traffic but leaving the answer entirely to market forces may have stunted the development of East-West capacity within Canada. Is this a good or a bad thing? I can remember back when there was a project in the 'states called Carnivore, and we had some American police -- I believe they were FBI -- come up and ask us politely if we'd like to put some of their machines on our network. Everybody pretty much uniformly said no. Shortly thereafter an American carrier showed up selling gigabit ethernet circuits to NYC for well below what was the going rate at the time and effectively pulled a lot of traffic that would otherwise have remained in country across the border. I've been outside of North America for a while now so I don't know first hand, but from the commentary on this list that trends appears to have continued... -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From maray at microsoft.com Tue Sep 10 21:30:35 2013 From: maray at microsoft.com (Marsh Ray) Date: Tue, 10 Sep 2013 21:30:35 +0000 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: References: <522AEB22.8010007@internetidentity.com> <522E138E.9040809@bogus.com> <522F48E1.1020203@vaxination.ca> Message-ID: <612c227c50554f71bc0170469e5a921c@BLUPR03MB166.namprd03.prod.outlook.com> > From: Bill Woodcock [mailto:woody at pch.net] > Subject: Re: Internet Surveillance and Boomerang Routing: A Call for > Canadian Network Sovereignty > > On Sep 10, 2013, at 9:29 AM, Jean-Francois Mezei > wrote: > > Will the market start to demand routes that avoid the USA if the > destination is not the USA ? > > Unlikely, all else being equal. The market demands the least expensive > routes. Which is why we push for new IXPs on the Canadian side of the > border, so that the _cheapest_ route will also be the _shortest_ route, and > will remain within Canadian jurisdiction and the purview of Canadian personal > privacy law, for instance. Maybe it's time to dust off some of those "reserved for future use" IP security options. It's almost as if someone saw this problem coming a long time ago. - Marsh https://tools.ietf.org/html/rfc791#page-17 Security This option provides a way for hosts to send security, compartmentation, handling restrictions, and TCC (closed user group) parameters. The format for this option is as follows: +--------+--------+---//---+---//---+---//---+---//---+ |10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC | +--------+--------+---//---+---//---+---//---+---//---+ Type=130 Length=11 Security (S field): 16 bits Specifies one of 16 levels of security (eight of which are reserved for future use). 00000000 00000000 - Unclassified 11110001 00110101 - Confidential 01111000 10011010 - EFTO 10111100 01001101 - MMMM 01011110 00100110 - PROG 10101111 00010011 - Restricted 11010111 10001000 - Secret 01101011 11000101 - Top Secret 00110101 11100010 - (Reserved for future use) 10011010 11110001 - (Reserved for future use) 01001101 01111000 - (Reserved for future use) 00100100 10111101 - (Reserved for future use) 00010011 01011110 - (Reserved for future use) 10001001 10101111 - (Reserved for future use) 11000100 11010110 - (Reserved for future use) 11100010 01101011 - (Reserved for future use) From rs at seastrom.com Tue Sep 10 23:05:09 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 10 Sep 2013 19:05:09 -0400 Subject: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty In-Reply-To: <20130910.185121.145639853.wwaites@tardis.ed.ac.uk> (William Waites's message of "Tue, 10 Sep 2013 18:51:21 +0100 (BST)") References: <522F48E1.1020203@vaxination.ca> <20130910.185121.145639853.wwaites@tardis.ed.ac.uk> Message-ID: <8661u8uvkq.fsf@valhalla.seastrom.com> William Waites writes: > Is this a good or a bad thing? I can remember back when there was a > project in the 'states called Carnivore, and we had some American > police -- I believe they were FBI -- come up and ask us politely if > we'd like to put some of their machines on our network. Everybody > pretty much uniformly said no. Shortly thereafter an American carrier > showed up selling gigabit ethernet circuits to NYC for well below what > was the going rate at the time and effectively pulled a lot of traffic > that would otherwise have remained in country across the border. More attributable to the unintended consequences of some of the more draconian parts of http://en.wikipedia.org/wiki/PROTECT_Act_of_2003 than of Carnivore, actually. :) -r From steve.bertrand at amayagaming.com Wed Sep 11 02:05:35 2013 From: steve.bertrand at amayagaming.com (Steve Bertrand) Date: Wed, 11 Sep 2013 02:05:35 +0000 Subject: Bandwidth at Caesars Casino in NJ Message-ID: We're just about to light up an infrastructure within Caesars in Atlantic City, and I'm wondering who can provide possible multi-homed access in that area (kudos if you're already in the building). Although the need is imminent, we do not have our own ARIN IP space, nor are we looking to multi-home immediately. I just want to find a provider who will let us use a 27-25 prefix for now (with proper justification), and is open to a client who will multi-home in the future (with either our space or yours). Would like to start with 100Mb, escalating quickly (or signing immediately if a decent price is found) to 1Gb. Off-list would be dandy. Thanks, Steve From ops.lists at gmail.com Wed Sep 11 03:00:50 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Sep 2013 08:30:50 +0530 Subject: Paging zoneedit.com Message-ID: Hi - sent a couple of support requests your way about stale NS on one of your hosts. Haven't got a ticket number back, so if you're listening, TIA for checking. thanks -srs -- --srs (iPad) From jra at baylink.com Wed Sep 11 14:39:40 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 11 Sep 2013 10:39:40 -0400 (EDT) Subject: MTR for Android? In-Reply-To: <85fd23be-08e0-4eac-9f11-600f07b8d6ef@email.android.com> Message-ID: <20930567.6941.1378910380277.JavaMail.root@benjamin.baylink.com> I've just heard back from traceping's author, Dmitry Yurchenko. He concurs with my bug report (DNS thread blocks ping reception), and likes my 2 RFEs, and hopes to get some time to hammer on the app again Real Soon Now. I have passed Randy's (justifiable) concerns on the permissions along to him, and will report what response I get. ----- Original Message ----- > From: "Jay Ashworth" > To: "Randy Bush" , "David Miller" > Cc: nanog at nanog.org > Sent: Thursday, September 5, 2013 7:32:14 PM > Subject: Re: MTR for Android? > Fair point. Have submitted a bug and an rfe; will request > clarification if I get a dialog on. > > Randy Bush wrote: > >> https://play.google.com/store/apps/details?id=com.inflim.trp > > > >it needs all this because? > > > > This app has access to these permissions: > > Your location > > precise location (GPS and network-based) > > approximate location (network-based) > > Network communication > > full network access > > view network connections > > Phone calls > > read phone status and identity > > Storage > > modify or delete the contents of your USB storage > > Your accounts > > read Google service configuration > > Development tools > > read sensitive log data > > System tools > > test access to protected storage > > Affects Battery > > prevent device from sleeping > > > >randy > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From glen.kent at gmail.com Wed Sep 11 16:47:37 2013 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 11 Sep 2013 22:17:37 +0530 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: I was forwarded a link to a blog post that vividly describes the attack. Sharing it with others in case they're interested .. http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/ Glen On Fri, Aug 2, 2013 at 10:10 PM, Glen Kent wrote: > Hi, > > Does anybody have details on what this vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > From crogers at inerail.net Wed Sep 11 20:25:17 2013 From: crogers at inerail.net (Chris Rogers) Date: Wed, 11 Sep 2013 16:25:17 -0400 Subject: Cogent Prefix Filtering Message-ID: Hello list, I'm hoping that someone from Cogent can contact me off-list to discuss prefix filtering on my BGP circuit. (We've tried going through standard channels, but our tickets keep getting closed without being completed. [Yes, there are more details]) Thanks! -Chris From leo.vegoda at icann.org Wed Sep 11 17:03:29 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 11 Sep 2013 10:03:29 -0700 Subject: One block of AS Numbers allocated to APNIC Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E16F5BD8@EXVPMBX100-1.exc.icann.org> Hi, The IANA AS Numbers registry has been updated to reflect the allocation of one block of 1,024 AS Numbers to APNIC in September 2013: 63488-63999 Assigned by APNIC whois.apnic.net 2013-09-11 133120-133631 Assigned by APNIC whois.apnic.net 2013-09-11 You can find the IANA AS Numbers registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/en/resources/policy/global-addressing/global-polic y-asn-blocks-21sep10-en.htm Regards, Leo Vegoda ICANN IANA -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From philfagan at gmail.com Thu Sep 12 20:03:44 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 12 Sep 2013 14:03:44 -0600 Subject: DNS Reliability Message-ID: Everything else remaining equal...is there a standard or expectation for DNS reliability? 98% 99% 99.5% 99.9% 99.99% 99.999% Measured in queries completed vs. queries lost. Whats the consensus? -- Phil Fagan Denver, CO 970-480-7618 From contact at nullivex.com Thu Sep 12 20:11:08 2013 From: contact at nullivex.com (Bryan Tong) Date: Thu, 12 Sep 2013 14:11:08 -0600 Subject: DNS Reliability In-Reply-To: References: Message-ID: To me anything below 99.99% is unacceptable. 100 failures out of 100,000 queries still seems like a lot especially if its not network related. So I would say 99.999% would be what I would look for. Thanks On Thu, Sep 12, 2013 at 2:03 PM, Phil Fagan wrote: > Everything else remaining equal...is there a standard or expectation for > DNS reliability? > > 98% > 99% > 99.5% > 99.9% > 99.99% > 99.999% > > Measured in queries completed vs. queries lost. > > Whats the consensus? > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From pfunix at gmail.com Thu Sep 12 20:14:34 2013 From: pfunix at gmail.com (Beavis) Date: Thu, 12 Sep 2013 21:14:34 +0100 Subject: DNS Reliability In-Reply-To: References: Message-ID: I go with 99.999% given that you have a good number of DNS Servers (anycasted). On Thu, Sep 12, 2013 at 9:03 PM, Phil Fagan wrote: > Everything else remaining equal...is there a standard or expectation for > DNS reliability? > > 98% > 99% > 99.5% > 99.9% > 99.99% > 99.999% > > Measured in queries completed vs. queries lost. > > Whats the consensus? > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From philfagan at gmail.com Thu Sep 12 20:25:25 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 12 Sep 2013 14:25:25 -0600 Subject: DNS Reliability In-Reply-To: References: Message-ID: Its a good point about the anycast; 99.999% should be expected. On Thu, Sep 12, 2013 at 2:14 PM, Beavis wrote: > I go with 99.999% given that you have a good number of DNS Servers > (anycasted). > > > On Thu, Sep 12, 2013 at 9:03 PM, Phil Fagan wrote: > >> Everything else remaining equal...is there a standard or expectation for >> DNS reliability? >> >> 98% >> 99% >> 99.5% >> 99.9% >> 99.99% >> 99.999% >> >> Measured in queries completed vs. queries lost. >> >> Whats the consensus? >> >> >> -- >> Phil Fagan >> Denver, CO >> 970-480-7618 >> > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Disclaimer: > http://goldmark.org/jeff/stupid-disclaimers/ > -- Phil Fagan Denver, CO 970-480-7618 From rubensk at gmail.com Thu Sep 12 20:39:42 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 12 Sep 2013 17:39:42 -0300 Subject: DNS Reliability In-Reply-To: References: Message-ID: On Thu, Sep 12, 2013 at 5:03 PM, Phil Fagan wrote: > Everything else remaining equal...is there a standard or expectation for > DNS reliability? > > 98% > 99% > 99.5% > 99.9% > 99.99% > 99.999% > > Measured in queries completed vs. queries lost. > > Whats the consensus? > ICANN new gTLD agreements specified 100% availability for the service, meaning at least 2 DNS IP addresses answered 95% of requests within 500 ms (UDP) or 1500 ms (TCP) for 51+% of the probes, or 99% availability for a single name server, defined as 1 DNS IP address. Rubens From glen.wiley at gmail.com Thu Sep 12 20:40:05 2013 From: glen.wiley at gmail.com (Glen Wiley) Date: Thu, 12 Sep 2013 16:40:05 -0400 Subject: DNS Reliability In-Reply-To: References: Message-ID: Remember though that anycast only solves for availability in one layer of the system and it is not difficult to create a less available anycast presence if you do silly things with the way you manage your routes. A system is only as available as the least available layer in that system For example, if you use an automated system that changes your route advertisements and that system encounters a defect that breaks your announcements then although a well built anycast footprint might acheive 99.999, a poorly implemented management system that is less available and creates an outage would reduce the number. On Thu, Sep 12, 2013 at 4:25 PM, Phil Fagan wrote: > Its a good point about the anycast; 99.999% should be expected. > > > On Thu, Sep 12, 2013 at 2:14 PM, Beavis wrote: > > > I go with 99.999% given that you have a good number of DNS Servers > > (anycasted). > > > > > > On Thu, Sep 12, 2013 at 9:03 PM, Phil Fagan wrote: > > > >> Everything else remaining equal...is there a standard or expectation for > >> DNS reliability? > >> > >> 98% > >> 99% > >> 99.5% > >> 99.9% > >> 99.99% > >> 99.999% > >> > >> Measured in queries completed vs. queries lost. > >> > >> Whats the consensus? > >> > >> > >> -- > >> Phil Fagan > >> Denver, CO > >> 970-480-7618 > >> > > > > > > > > -- > > () ascii ribbon campaign - against html e-mail > > /\ www.asciiribbon.org - against proprietary attachments > > > > Disclaimer: > > http://goldmark.org/jeff/stupid-disclaimers/ > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- Glen Wiley KK4SFV "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery From philfagan at gmail.com Thu Sep 12 20:48:46 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 12 Sep 2013 14:48:46 -0600 Subject: DNS Reliability In-Reply-To: References: Message-ID: Good reference; thank you. On Thu, Sep 12, 2013 at 2:39 PM, Rubens Kuhl wrote: > > > > On Thu, Sep 12, 2013 at 5:03 PM, Phil Fagan wrote: > >> Everything else remaining equal...is there a standard or expectation for >> DNS reliability? >> >> 98% >> 99% >> 99.5% >> 99.9% >> 99.99% >> 99.999% >> >> Measured in queries completed vs. queries lost. >> >> Whats the consensus? >> > > ICANN new gTLD agreements specified 100% availability for the service, > meaning at least 2 DNS IP addresses answered 95% of requests within 500 ms > (UDP) or 1500 ms (TCP) for 51+% of the probes, or 99% availability for a > single name server, defined as 1 DNS IP address. > > > Rubens > > > -- Phil Fagan Denver, CO 970-480-7618 From philfagan at gmail.com Thu Sep 12 20:49:57 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 12 Sep 2013 14:49:57 -0600 Subject: DNS Reliability In-Reply-To: References: Message-ID: Thumbs up on this one; my entire path and chain of management of that path need to be equally fault tolerant - Awesome. On Thu, Sep 12, 2013 at 2:40 PM, Glen Wiley wrote: > Remember though that anycast only solves for availability in one layer of > the system and it is not difficult to create a less available anycast > presence if you do silly things with the way you manage your routes. A > system is only as available as the least available layer in that system > > For example, if you use an automated system that changes your route > advertisements and that system encounters a defect that breaks your > announcements then although a well built anycast footprint might acheive > 99.999, a poorly implemented management system that is less available and > creates an outage would reduce the number. > > > On Thu, Sep 12, 2013 at 4:25 PM, Phil Fagan wrote: > > > Its a good point about the anycast; 99.999% should be expected. > > > > > > On Thu, Sep 12, 2013 at 2:14 PM, Beavis wrote: > > > > > I go with 99.999% given that you have a good number of DNS Servers > > > (anycasted). > > > > > > > > > On Thu, Sep 12, 2013 at 9:03 PM, Phil Fagan > wrote: > > > > > >> Everything else remaining equal...is there a standard or expectation > for > > >> DNS reliability? > > >> > > >> 98% > > >> 99% > > >> 99.5% > > >> 99.9% > > >> 99.99% > > >> 99.999% > > >> > > >> Measured in queries completed vs. queries lost. > > >> > > >> Whats the consensus? > > >> > > >> > > >> -- > > >> Phil Fagan > > >> Denver, CO > > >> 970-480-7618 > > >> > > > > > > > > > > > > -- > > > () ascii ribbon campaign - against html e-mail > > > /\ www.asciiribbon.org - against proprietary attachments > > > > > > Disclaimer: > > > http://goldmark.org/jeff/stupid-disclaimers/ > > > > > > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > > > -- > Glen Wiley > KK4SFV > > "A designer knows he has achieved perfection not when there is nothing left > to add, but when there is nothing left to take away." - Antoine de > Saint-Exupery > -- Phil Fagan Denver, CO 970-480-7618 From randy at psg.com Thu Sep 12 21:35:40 2013 From: randy at psg.com (Randy Bush) Date: Thu, 12 Sep 2013 11:35:40 -1000 Subject: DNS Reliability In-Reply-To: References: Message-ID: > Everything else remaining equal...is there a standard or expectation for > DNS reliability? > ... > Measured in queries completed vs. queries lost. this is the wrong question. the protocol is designed assuming query failures. randy From swm at emanon.com Thu Sep 12 22:10:02 2013 From: swm at emanon.com (Scott Morris) Date: Thu, 12 Sep 2013 18:10:02 -0400 Subject: Verizon Wireless network contact? Message-ID: <52323BBA.5070507@emanon.com> If there's anyone from the IP-side of Verizon Wireless, if you could contact me off-list, that would be awesome! Saves me hours of pointless phone calls. :) Thanks! -- *Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713, CCDE #2009::D, CCNP-Data Center, CCNP-Voice, JNCIE-SP #153, JNCIE-ER #102, JNCIS-QFX, CISSP, et al. IPv6 Gold Certified Engineer, IPv6 Gold Certified Trainer CCSI #21903, JNCI-SP, JNCI-ER, JNCI-QFX swm at emanon.com Knowledge is power. Power corrupts. Study hard and be Eeeeviiiil...... From george.herbert at gmail.com Thu Sep 12 22:26:43 2013 From: george.herbert at gmail.com (George William Herbert) Date: Thu, 12 Sep 2013 15:26:43 -0700 Subject: DNS Reliability In-Reply-To: References: Message-ID: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> On Sep 12, 2013, at 2:35 PM, Randy Bush wrote: >> Everything else remaining equal...is there a standard or expectation for >> DNS reliability? >> ... >> Measured in queries completed vs. queries lost. > > this is the wrong question. the protocol is designed assuming query > failures. > > randy I think it's part of the right answer. Capacity and server connectivity issues, what this metric will mostly measure, do matter. The other part, more likely to get you on CNN and Reddit and the front pages of the NY Times and WSJ, is the area represented by MTBF / MTTR / etc. how often is DNS for your domain DOWN - or WRONG - and how fast did you recover. The other subthread about routeability plays into that. For BIGPLACE environments, you should be considering how many AS numbers independently host DNS instances for you, in how many geographical regions, and do you have a backup registrar available spun up... -george william herbert Sent from Kangphone From ggm at algebras.org Thu Sep 12 22:34:25 2013 From: ggm at algebras.org (George Michaelson) Date: Fri, 13 Sep 2013 08:34:25 +1000 Subject: DNS Reliability In-Reply-To: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> References: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> Message-ID: we're already outside our operating envelope, if these community expectation figures are believable. a wise man once said to me that when setting formal conformance targets its a good idea to only set ones you can honestly achieve, otherwise you're setting yourself up to be measured to fail. I don't think that necessarily competes with 'aim high' ('be all you can be') but... On Fri, Sep 13, 2013 at 8:26 AM, George William Herbert < george.herbert at gmail.com> wrote: > > > On Sep 12, 2013, at 2:35 PM, Randy Bush wrote: > > >> Everything else remaining equal...is there a standard or expectation for > >> DNS reliability? > >> ... > >> Measured in queries completed vs. queries lost. > > > > this is the wrong question. the protocol is designed assuming query > > failures. > > > > randy > > I think it's part of the right answer. Capacity and server connectivity > issues, what this metric will mostly measure, do matter. > > The other part, more likely to get you on CNN and Reddit and the front > pages of the NY Times and WSJ, is the area represented by MTBF / MTTR / > etc. how often is DNS for your domain DOWN - or WRONG - and how fast did > you recover. > > The other subthread about routeability plays into that. For BIGPLACE > environments, you should be considering how many AS numbers independently > host DNS instances for you, in how many geographical regions, and do you > have a backup registrar available spun up... > > > -george william herbert > > > Sent from Kangphone > From randy at psg.com Thu Sep 12 22:39:42 2013 From: randy at psg.com (Randy Bush) Date: Thu, 12 Sep 2013 12:39:42 -1000 Subject: DNS Reliability In-Reply-To: References: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> Message-ID: > we're already outside our operating envelope not really. just some folk seem not to understand things such as udp datagrams and the dns protocols. randy From george.herbert at gmail.com Thu Sep 12 23:02:45 2013 From: george.herbert at gmail.com (George William Herbert) Date: Thu, 12 Sep 2013 16:02:45 -0700 Subject: DNS Reliability In-Reply-To: References: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> Message-ID: On Sep 12, 2013, at 3:39 PM, Randy Bush wrote: >> we're already outside our operating envelope > > not really. just some folk seem not to understand things such as udp > datagrams and the dns protocols. > > randy Statistically, UDP sometimes arrives after an internet wide round trip. Honest! The worry is bimodal. Most small sites, two or three servers, stop worrying. Most medium sites, watch your server load and run external monitoring. Most big sites are not sufficiently paranoid / redundant here. -george william herbert Sent from Kangphone From ggm at algebras.org Thu Sep 12 23:36:10 2013 From: ggm at algebras.org (George Michaelson) Date: Fri, 13 Sep 2013 09:36:10 +1000 Subject: DNS Reliability In-Reply-To: References: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> Message-ID: you removed a clause in that sentence randy: "we're already outside our operating envelope, if these community expectation figures are believable" there is a point to that clause. its the same as your answer in some respects. On Fri, Sep 13, 2013 at 8:39 AM, Randy Bush wrote: > > we're already outside our operating envelope > > not really. just some folk seem not to understand things such as udp > datagrams and the dns protocols. > > randy > From Valdis.Kletnieks at vt.edu Fri Sep 13 00:45:21 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Sep 2013 20:45:21 -0400 Subject: DNS Reliability In-Reply-To: Your message of "Thu, 12 Sep 2013 14:03:44 -0600." References: Message-ID: <70954.1379033121@turing-police.cc.vt.edu> On Thu, 12 Sep 2013 14:03:44 -0600, Phil Fagan said: > Everything else remaining equal...is there a standard or expectation for > DNS reliability? > > 98% > 99% > 99.5% > 99.9% > 99.99% > 99.999% > > Measured in queries completed vs. queries lost. > > Whats the consensus? Remember to factor in Duane Wessel's work that showed that something like 98% of the DNS traffic at the root servers was totally bogus? Maybe you need to factor in "broken queries not answered, and offenders slapped around with a large trout"? Because if it's busted requests you're sending towards the root, they're going to count against your completed/lost ratio in a really bad way. Anybody know if people have cleaned up their collective acts since Duane did that paper? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From LarrySheldon at cox.net Fri Sep 13 01:53:29 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 12 Sep 2013 20:53:29 -0500 Subject: DNS Reliability In-Reply-To: References: Message-ID: <52327019.7070600@cox.net> On 9/12/2013 3:25 PM, Phil Fagan wrote: > Its a good point about the anycast; 99.999% should be expected. A small choice of attitude-reflecting language. I expect 100.000% I'll accept 99.999% or better. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From morrowc.lists at gmail.com Fri Sep 13 02:00:54 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 12 Sep 2013 22:00:54 -0400 Subject: DNS Reliability In-Reply-To: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> References: <423D87CE-7B2F-47CF-BB9C-974B4DACF9D1@gmail.com> Message-ID: On Thu, Sep 12, 2013 at 6:26 PM, George William Herbert wrote: > The other subthread about routeability plays into that. For BIGPLACE environments, you should be considering how many AS numbers independently host DNS instances for you, in how many geographical regions, and do you have a backup registrar available spun up... here's an interesting point... if you are a BIGPLACE, do you want to trust your fate to some third party hosting your dns for you? What about how your internal name service stuff is managed? say you have a practice of using rsh to affect updates across your 4 main dns nodes, adding a 5th or Nth outside where rsh is not possible/desired .... means adding additional processes and cruft to your update process, is this acceptable? Take, for instance the FBI.gov domain 3 days ago, some set of updates happened, their ipv4 servers were answering with a consistent response, their ipv6 nodes were answering with a variety of not correct answers :( In the case of the FBI.gov domain, all of it is handled outside 'fbi.gov hands' (all servers hosted externally) but... -chris From brunner at nic-naa.net Fri Sep 13 02:32:44 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 12 Sep 2013 19:32:44 -0700 Subject: DNS Reliability In-Reply-To: References: Message-ID: <5232794C.9070601@nic-naa.net> On 9/12/13 1:39 PM, Rubens Kuhl wrote: > ICANN new gTLD agreements specified 100% availability for the service, > meaning at least 2 DNS IP addresses answered 95% of requests within 500 ms > (UDP) or 1500 ms (TCP) for 51+% of the probes, or 99% availability for a > single name server, defined as 1 DNS IP address. unless phil happens to be building out (or spec'ing out $provider's offered sla) for one of the happy thousand or so celebrants of 2014, a surprisingly large fraction of which are tenant plays on existing infrastructure, the bogie above, uninterpreted, is not a controlling authority. additionally, was phil asking for a metric for an authoritative server, serving a zone delegated directly from the iana root? was he asking for a metric for a caching server? and if the metric is "queries completed vs. queries lost", from where to where? (that is the "uninterpreted" bit from the bogie rubens quotes, as we did have to correct some assumptions of the requirement author -- where is the measurement being preformed? i'm with randy on this, dns is a service, the better question is what fails as query response degrades, in the presence of hierarchical caching and the protocol being used as designed under best effort of infrastructure and application. eric From mdavids at forfun.net Fri Sep 13 07:14:26 2013 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Fri, 13 Sep 2013 09:14:26 +0200 Subject: DNS Reliability In-Reply-To: <52327019.7070600@cox.net> References: <52327019.7070600@cox.net> Message-ID: <5232BB52.6050201@forfun.net> On 09/13/13 03:53, Larry Sheldon wrote: > On 9/12/2013 3:25 PM, Phil Fagan wrote: >> Its a good point about the anycast; 99.999% should be expected. > A small choice of attitude-reflecting language. > > I expect 100.000% > > I'll accept 99.999% or better. > It depends... define 'lost queries'. For example; is RRL included here or not (sometimes you want to deliberatly 'loose' queries). -- Marco From LarrySheldon at cox.net Fri Sep 13 14:00:16 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 13 Sep 2013 09:00:16 -0500 Subject: DNS Reliability In-Reply-To: References: <52327019.7070600@cox.net> Message-ID: <52331A70.7000400@cox.net> On 9/13/2013 2:14 AM, Marco Davids (Prive) wrote: > On 09/13/13 03:53, Larry Sheldon wrote: >> On 9/12/2013 3:25 PM, Phil Fagan wrote: >>> Its a good point about the anycast; 99.999% should be expected. >> A small choice of attitude-reflecting language. >> >> I expect 100.000% >> >> I'll accept 99.999% or better. >> > > It depends... define 'lost queries'. For example; is RRL included here > or not (sometimes you want to deliberatly 'loose' queries). I do not ever set any amount of failure as an objective. I usually have a specified tolerance for failure. If for some odd circumstance I wan to discard queries, that would involve knowing exactly what happened to them--not loosing them. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From philfagan at gmail.com Fri Sep 13 18:14:55 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 13 Sep 2013 12:14:55 -0600 Subject: DNS Reliability In-Reply-To: <52331A70.7000400@cox.net> References: <52327019.7070600@cox.net> <52331A70.7000400@cox.net> Message-ID: Tolerance for failure; I like it. Eric - I'm interested in an accepted norm of loss of queries made to the cache tier. Yes, when I provide a 'service' to a client (don't really care about SLA) i'm interested in what the accepted norm or guidance is on % loss on queries -- because this drives my architecture, right? Marco - I think 'lost queries' in this instance is simply, wait for it.....the full UDP session. Yes yes, session is bad to say, but service request completed through middle-boxes are tracked as sessions. So thats what I'm looking for; what is the general consesus for reliability all other things equal. Sure, you have the factor of UDP, retry, path, etc. etc. etc.....but I think Larry hit the nail on the head - whats my clients[aggregate of] tolerance before Evil ensues. On Fri, Sep 13, 2013 at 8:00 AM, Larry Sheldon wrote: > On 9/13/2013 2:14 AM, Marco Davids (Prive) wrote: > >> On 09/13/13 03:53, Larry Sheldon wrote: >> >>> On 9/12/2013 3:25 PM, Phil Fagan wrote: >>> >>>> Its a good point about the anycast; 99.999% should be expected. >>>> >>> A small choice of attitude-reflecting language. >>> >>> I expect 100.000% >>> >>> I'll accept 99.999% or better. >>> >>> >> It depends... define 'lost queries'. For example; is RRL included here >> or not (sometimes you want to deliberatly 'loose' queries). >> > > > > I do not ever set any amount of failure as an objective. I usually have a > specified tolerance for failure. If for some odd circumstance I wan to > discard queries, that would involve knowing exactly what happened to > them--not loosing them. > > > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > -- Phil Fagan Denver, CO 970-480-7618 From cscora at apnic.net Fri Sep 13 18:35:32 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Sep 2013 04:35:32 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201309131835.r8DIZWYq011373@thyme.rand.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, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. 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 . Routing Table Report 04:00 +10GMT Sat 14 Sep, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 466731 Prefixes after maximum aggregation: 188606 Deaggregation factor: 2.47 Unique aggregates announced to Internet: 232076 Total ASes present in the Internet Routing Table: 44957 Prefixes per ASN: 10.38 Origin-only ASes present in the Internet Routing Table: 35133 Origin ASes announcing only one prefix: 16260 Transit ASes present in the Internet Routing Table: 5898 Transit-only ASes present in the Internet Routing Table: 160 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 5814 Unregistered ASNs in the Routing Table: 1930 Number of 32-bit ASNs allocated by the RIRs: 5026 Number of 32-bit ASNs visible in the Routing Table: 3926 Prefixes from 32-bit ASNs in the Routing Table: 12187 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 424 Number of addresses announced to Internet: 2642434644 Equivalent to 157 /8s, 128 /16s and 90 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.0 Total number of prefixes smaller than registry allocations: 163699 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110762 Total APNIC prefixes after maximum aggregation: 33625 APNIC Deaggregation factor: 3.29 Prefixes being announced from the APNIC address blocks: 112750 Unique aggregates announced from the APNIC address blocks: 46637 APNIC Region origin ASes present in the Internet Routing Table: 4870 APNIC Prefixes per ASN: 23.15 APNIC Region origin ASes announcing only one prefix: 1219 APNIC Region transit ASes present in the Internet Routing Table: 833 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 673 Number of APNIC addresses announced to Internet: 727657280 Equivalent to 43 /8s, 95 /16s and 43 /24s Percentage of available APNIC address space announced: 85.0 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-63999, 131072-133631 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: 161603 Total ARIN prefixes after maximum aggregation: 81243 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 162192 Unique aggregates announced from the ARIN address blocks: 75506 ARIN Region origin ASes present in the Internet Routing Table: 15873 ARIN Prefixes per ASN: 10.22 ARIN Region origin ASes announcing only one prefix: 6016 ARIN Region transit ASes present in the Internet Routing Table: 1654 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 21 Number of ARIN addresses announced to Internet: 1071208192 Equivalent to 63 /8s, 217 /16s and 87 /24s Percentage of available ARIN address space announced: 56.7 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, 393216-394239 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: 118845 Total RIPE prefixes after maximum aggregation: 61298 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 122683 Unique aggregates announced from the RIPE address blocks: 79591 RIPE Region origin ASes present in the Internet Routing Table: 17413 RIPE Prefixes per ASN: 7.05 RIPE Region origin ASes announcing only one prefix: 8259 RIPE Region transit ASes present in the Internet Routing Table: 2807 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2392 Number of RIPE addresses announced to Internet: 657272548 Equivalent to 39 /8s, 45 /16s and 46 /24s Percentage of available RIPE address space announced: 95.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-200191 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: 51379 Total LACNIC prefixes after maximum aggregation: 9759 LACNIC Deaggregation factor: 5.26 Prefixes being announced from the LACNIC address blocks: 56230 Unique aggregates announced from the LACNIC address blocks: 25968 LACNIC Region origin ASes present in the Internet Routing Table: 2017 LACNIC Prefixes per ASN: 27.88 LACNIC Region origin ASes announcing only one prefix: 567 LACNIC Region transit ASes present in the Internet Routing Table: 376 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 834 Number of LACNIC addresses announced to Internet: 138838064 Equivalent to 8 /8s, 70 /16s and 128 /24s Percentage of available LACNIC address space announced: 82.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11842 Total AfriNIC prefixes after maximum aggregation: 2623 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 12452 Unique aggregates announced from the AfriNIC address blocks: 3987 AfriNIC Region origin ASes present in the Internet Routing Table: 657 AfriNIC Prefixes per ASN: 18.95 AfriNIC Region origin ASes announcing only one prefix: 199 AfriNIC Region transit ASes present in the Internet Routing Table: 139 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46560000 Equivalent to 2 /8s, 198 /16s and 115 /24s Percentage of available AfriNIC address space announced: 46.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 4766 2923 11561 924 Korea Telecom (KIX) 17974 2676 903 91 PT TELEKOMUNIKASI INDONESIA 7545 2072 321 112 TPG Internet Pty Ltd 4755 1771 390 190 TATA Communications formerly 9829 1549 1237 45 BSNL National Internet Backbo 9583 1232 92 505 Sify Limited 9498 1186 309 70 BHARTI Airtel Ltd. 4808 1159 2128 341 CNCGROUP IP network: China169 7552 1155 1080 13 Vietel Corporation 24560 1090 394 163 Bharti Airtel Ltd., Telemedia 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 6389 3068 3689 62 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 22773 2041 2933 124 Cox Communications, Inc. 1785 2011 679 125 PaeTec Communications, Inc. 20115 1678 1649 629 Charter Communications 4323 1617 1103 411 Time Warner Telecom 701 1531 11136 798 UUNET Technologies, Inc. 30036 1352 305 630 Mediacom Communications Corp 7018 1315 11261 827 AT&T WorldNet Services 11492 1222 218 365 Cable One 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 8402 1703 544 16 Corbina telecom 34984 1329 244 220 BILISIM TELEKOM 20940 1014 369 781 Akamai Technologies European 31148 981 43 20 FreeNet ISP 6830 894 2367 426 UPC Distribution Services 13188 847 99 70 Educational Network 8551 749 370 41 Bezeq International 12479 673 797 53 Uni2 Autonomous System 58113 541 55 339 LIR DATACENTER TELECOM SRL 35228 528 246 16 Avatar Broadband Limited 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 28573 3249 1722 97 NET Servicos de Comunicao S.A 10620 2559 418 246 TVCABLE BOGOTA 7303 1708 1133 225 Telecom Argentina Stet-France 18881 1430 844 20 Global Village Telecom 8151 1291 2782 391 UniNet S.A. de C.V. 11830 865 364 15 Instituto Costarricense de El 27947 840 94 92 Telconet S.A 6503 813 434 64 AVANTEL, S.A. 7738 780 1498 36 Telecomunicacoes da Bahia S.A 6147 740 376 21 Telefonica Del Peru 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 36998 1861 112 5 MOBITEL 24863 868 274 30 LINKdotNET AS number 6713 554 633 26 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 257 921 216 The Internet Solution 36992 222 501 28 Etisalat MISR 15706 221 32 6 Sudatel Internet Exchange Aut 29571 221 17 12 Ci Telecom Autonomous system 29975 191 667 21 Vodacom 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 28573 3249 1722 97 NET Servicos de Comunicao S.A 6389 3068 3689 62 bellsouth.net, inc. 4766 2923 11561 924 Korea Telecom (KIX) 17974 2676 903 91 PT TELEKOMUNIKASI INDONESIA 10620 2559 418 246 TVCABLE BOGOTA 7545 2072 321 112 TPG Internet Pty Ltd 18566 2065 382 184 Covad Communications 22773 2041 2933 124 Cox Communications, Inc. 1785 2011 679 125 PaeTec Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3068 3006 bellsouth.net, inc. 17974 2676 2585 PT TELEKOMUNIKASI INDONESIA 10620 2559 2313 TVCABLE BOGOTA 4766 2923 1999 Korea Telecom (KIX) 7545 2072 1960 TPG Internet Pty Ltd 22773 2041 1917 Cox Communications, Inc. 1785 2011 1886 PaeTec Communications, Inc. 18566 2065 1881 Covad Communications 36998 1861 1856 MOBITEL 8402 1703 1687 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.90.192.0/18 36086 Broad Communications Technolo 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.96.0/20 40676 Psychz Networks 23.91.160.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.160.0/19 36493 3757277 Canada Inc. (oa 295.c 23.91.164.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.168.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.172.0/22 36493 3757277 Canada Inc. (oa 295.c 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:11 /10:31 /11:93 /12:250 /13:479 /14:914 /15:1625 /16:12781 /17:6701 /18:11142 /19:22929 /20:32520 /21:35083 /22:49455 /23:43148 /24:247083 /25:839 /26:988 /27:484 /28:48 /29:78 /30:19 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1713 3068 bellsouth.net, inc. 8402 1427 1703 Corbina telecom 22773 1328 2041 Cox Communications, Inc. 30036 1212 1352 Mediacom Communications Corp 11492 1183 1222 Cable One 1785 1083 2011 PaeTec Communications, Inc. 6983 1025 1152 ITC^Deltacom 22561 930 1196 Digital Teleport, Inc Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:809 2:839 3:3 4:17 5:941 6:19 8:609 12:1889 13:3 14:868 15:11 16:3 17:11 18:19 20:21 23:389 24:1739 27:1564 31:1438 32:45 33:2 34:5 36:77 37:1846 38:903 39:3 40:179 41:3350 42:253 44:9 46:1989 47:4 49:670 50:837 52:12 54:37 55:7 57:26 58:1167 59:607 60:339 61:1421 62:1188 63:1984 64:4566 65:2364 66:4164 67:2073 68:1087 69:3298 70:865 71:496 72:2005 74:2549 75:330 76:304 77:1178 78:1054 79:620 80:1325 81:1029 82:646 83:582 84:583 85:1291 86:494 87:1040 88:559 89:1842 90:158 91:5656 92:605 93:1665 94:2072 95:1550 96:516 97:342 98:1038 99:44 100:31 101:606 103:3303 105:519 106:142 107:208 108:503 109:1881 110:961 111:1127 112:569 113:795 114:730 115:996 116:979 117:802 118:1156 119:1290 120:366 121:740 122:1869 123:1254 124:1382 125:1424 128:611 129:231 130:321 131:675 132:351 133:161 134:290 135:67 136:271 137:263 138:348 139:178 140:199 141:325 142:553 143:392 144:501 145:95 146:536 147:489 148:686 149:355 150:154 151:601 152:414 153:195 154:46 155:504 156:274 157:419 158:285 159:760 160:350 161:446 162:652 163:227 164:620 165:567 166:259 167:607 168:1047 169:125 170:1084 171:194 172:25 173:1603 174:522 175:498 176:1193 177:2263 178:1896 179:118 180:1530 181:722 182:1271 183:461 184:623 185:826 186:2491 187:1460 188:1880 189:1313 190:7087 192:6926 193:5652 194:4063 195:3332 196:1402 197:1004 198:4662 199:5420 200:6023 201:2538 202:8965 203:8918 204:4522 205:2628 206:2844 207:2884 208:4002 209:3605 210:2950 211:1555 212:2266 213:2050 214:928 215:99 216:5308 217:1655 218:623 219:313 220:1278 221:557 222:326 223:500 End of report From jfmezei_nanog at vaxination.ca Fri Sep 13 20:01:51 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Sep 2013 16:01:51 -0400 Subject: DNS Reliability In-Reply-To: <52327019.7070600@cox.net> References: <52327019.7070600@cox.net> Message-ID: <52336F2F.1030206@vaxination.ca> On 13-09-12 21:53, Larry Sheldon wrote: > I expect 100.000% > > I'll accept 99.999% or better. At these numbers, one has to start to count failover time. A "system" can be disaster tolerant but take 2 hours to recover fully, or it could also recover within a couple of seconds. It depends on architecture and available services. And in networking, you also need to consider internal and external routing update propagation times. From jabley at hopcount.ca Fri Sep 13 20:10:10 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 13 Sep 2013 16:10:10 -0400 Subject: DNS Reliability In-Reply-To: <52336F2F.1030206@vaxination.ca> References: <52327019.7070600@cox.net> <52336F2F.1030206@vaxination.ca> Message-ID: On 2013-09-13, at 16:01, Jean-Francois Mezei wrote: > On 13-09-12 21:53, Larry Sheldon wrote: > >> I expect 100.000% >> >> I'll accept 99.999% or better. > > At these numbers, one has to start to count failover time. Before really any part of this thread makes sense, you have to describe exactly what you mean by "available". Joe From bmanning at vacation.karoshi.com Fri Sep 13 20:15:09 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Sep 2013 20:15:09 +0000 Subject: DNS Reliability In-Reply-To: <52336F2F.1030206@vaxination.ca> References: <52327019.7070600@cox.net> <52336F2F.1030206@vaxination.ca> Message-ID: <20130913201509.GC18576@vacation.karoshi.com.> On Fri, Sep 13, 2013 at 04:01:51PM -0400, Jean-Francois Mezei wrote: > On 13-09-12 21:53, Larry Sheldon wrote: > > > I expect 100.000% > > > > I'll accept 99.999% or better. > > At these numbers, one has to start to count failover time. A "system" > can be disaster tolerant but take 2 hours to recover fully, or it could > also recover within a couple of seconds. It depends on architecture and > available services. And in networking, you also need to consider > internal and external routing update propagation times. > > from where? to where? what % of the Internet is _not_ reachable from my DNS service at any given time? why is that acceptable? and more importantly, who's job is it to fix/stablize the net so these "remote" locations can reach my DNS service? "we will answer 100% of the valid DNS queries we receive." /bill From cidr-report at potaroo.net Fri Sep 13 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Sep 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201309132200.r8DM003K050035@wattle.apnic.net> This report has been generated at Fri Sep 13 21:13:29 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-09-13 481151 272368 07-09-13 481017 272389 08-09-13 480918 272309 09-09-13 481062 272267 10-09-13 481035 272608 11-09-13 481628 272545 12-09-13 481404 272990 13-09-13 481601 273148 AS Summary 45125 Number of ASes in routing system 18565 Number of ASes announcing only one prefix 4176 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118059232 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Sep13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 481622 273180 208442 43.3% All ASes AS6389 3068 65 3003 97.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3250 468 2782 85.6% NET Servi?os de Comunica??o S.A. AS17974 2675 194 2481 92.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4176 2027 2149 51.5% WINDSTREAM - Windstream Communications Inc AS4766 2923 932 1991 68.1% KIXS-AS-KR Korea Telecom AS22773 2044 141 1903 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS3356 3242 1721 1521 46.9% LEVEL3 Level 3 Communications AS36998 1862 394 1468 78.8% SDN-MOBITEL AS4323 2957 1524 1433 48.5% TWTC - tw telecom holdings, inc. AS10620 2559 1158 1401 54.7% Telmex Colombia S.A. AS18881 1430 69 1361 95.2% Global Village Telecom AS7303 1708 457 1251 73.2% Telecom Argentina S.A. AS4755 1770 592 1178 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1188 138 1050 88.4% VIETEL-AS-AP Vietel Corporation AS22561 1196 212 984 82.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2011 1156 855 42.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 983 181 802 81.6% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1159 401 758 65.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS11830 866 117 749 86.5% Instituto Costarricense de Electricidad y Telecom. AS701 1532 802 730 47.7% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS7545 2076 1351 725 34.9% TPG-INTERNET-AP TPG Telecom Limited AS13977 850 143 707 83.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS6147 740 41 699 94.5% Telefonica del Peru S.A.A. AS8402 1671 975 696 41.7% CORBINA-AS OJSC "Vimpelcom" AS8151 1294 603 691 53.4% Uninet S.A. de C.V. AS855 733 55 678 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1152 483 669 58.1% ITCDELTA - ITC^Deltacom AS24560 1090 424 666 61.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7738 780 135 645 82.7% Telemar Norte Leste S.A. Total 55050 17427 37623 68.3% Top 30 total Possible Bogus Routes 23.92.128.0/17 AS42981 RES-PL RES.PL ISP S.C. 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 31.13.184.0/21 AS42981 RES-PL RES.PL ISP S.C. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 82.103.0.0/18 AS30901 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.200.188.0/22 AS44016 91.205.188.0/22 AS47983 91.207.178.0/23 AS48274 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.9.220.0/24 AS13230 103.9.221.0/24 AS13230 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 164.40.184.0/24 AS19821 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 181.120.0.0/14 AS23201 Telecel S.A. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.9.59.0/24 AS1257 TELE2 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 198.51.76.0/24 AS53934 SZW-INC - SUB-ZERO GROUP, INC. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.43.127.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.84.16.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.84.17.0/24 AS17781 XINHUA Xinhua News Agency 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.235.105.0/24 AS40344 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.225.0/24 AS3549 GBLX Global Crossing Ltd. 208.66.227.0/24 AS3549 GBLX Global Crossing Ltd. 208.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.87.144.0/21 AS21919 209.87.152.0/22 AS21919 209.87.156.0/24 AS21919 209.87.157.0/24 AS21919 209.87.158.0/24 AS21919 209.87.159.0/24 AS21919 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Sep 13 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Sep 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201309132200.r8DM019Q050048@wattle.apnic.net> BGP Update Report Interval: 05-Sep-13 -to- 12-Sep-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 42604 2.0% 44.7 -- BSNL-NIB National Internet Backbone 2 - AS8402 34467 1.6% 36.5 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS28624 33602 1.6% 154.1 -- Oops Telecom 4 - AS27738 31818 1.5% 55.1 -- Ecuadortelecom S.A. 5 - AS4766 25610 1.2% 8.8 -- KIXS-AS-KR Korea Telecom 6 - AS43418 23032 1.1% 338.7 -- ANTIDOT Pryama Mova TOV 7 - AS56042 20320 1.0% 725.7 -- CMNET-SHANXI-AP China Mobile communications corporation 8 - AS20940 19375 0.9% 57.0 -- AKAMAI-ASN1 Akamai International B.V. 9 - AS9416 18963 0.9% 2107.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 10 - AS28573 18913 0.9% 14.8 -- NET Servi?os de Comunica??o S.A. 11 - AS4775 16004 0.8% 4001.0 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS5800 15365 0.7% 73.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS9498 14993 0.7% 14.1 -- BBIL-AP BHARTI Airtel Ltd. 14 - AS9155 14228 0.7% 42.3 -- QNET QualityNet General Trading & Contracting Co. 15 - AS17974 11318 0.5% 4.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS36998 10974 0.5% 6.9 -- SDN-MOBITEL 17 - AS18403 10441 0.5% 20.4 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 18 - AS50710 10425 0.5% 43.4 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 19 - AS4434 10201 0.5% 377.8 -- ERX-RADNET1-AS PT Rahajasa Media Internet 20 - AS48612 9642 0.5% 964.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 8877 0.4% 8877.0 -- NOAA-AS - NOAA 2 - AS53229 8861 0.4% 8861.0 -- Industrias Arteb S.A 3 - AS19406 4494 0.2% 4494.0 -- TWRS-MA - Towerstream I, Inc. 4 - AS7202 8167 0.4% 4083.5 -- FAMU - Florida A & M University 5 - AS4775 16004 0.8% 4001.0 -- GLOBE-TELECOM-AS Globe Telecoms 6 - AS6174 7058 0.3% 3529.0 -- SPRINTLINK8 - Sprint 7 - AS37367 2850 0.1% 2850.0 -- CALLKEY 8 - AS32244 7287 0.3% 2429.0 -- LIQUID-WEB-INC - Liquid Web, Inc. 9 - AS9416 18963 0.9% 2107.0 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 10 - AS42334 4016 0.2% 2008.0 -- BBP-AS Broadband Plus s.a.l. 11 - AS19111 1555 0.1% 1555.0 -- NATURES-BOUN - NBTY, Inc. 12 - AS14287 9238 0.4% 1539.7 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - AS34344 4540 0.2% 1513.3 -- THE-PORT-OF-TILBURY-LONDON-LTD The Port Of Tilbury London Ltd 14 - AS55100 1447 0.1% 1447.0 -- GTCNA - The Glenmede Trust Company National Association 15 - AS27941 5572 0.3% 1393.0 -- CONSULNETWORK LTDA 16 - AS48068 1148 0.1% 1148.0 -- VISONIC Visonic Ltd 17 - AS49675 4460 0.2% 1115.0 -- SKBKONTUR-AS CJSC Production Company "SKB Kontur" 18 - AS48612 9642 0.5% 964.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 19 - AS47582 824 0.0% 824.0 -- KRAFT-S-TOGLIATTI Kraft-S JSC 20 - AS61033 814 0.0% 814.0 -- MALI-TEHNIC-AS MALI TEHNIC S.R.L. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 61.95.239.0/24 11442 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 202.154.17.0/24 10079 0.4% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 3 - 92.246.207.0/24 9627 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 4 - 203.118.224.0/21 9477 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 9459 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 8877 0.4% AS6629 -- NOAA-AS - NOAA 7 - 186.251.232.0/23 8861 0.4% AS53229 -- Industrias Arteb S.A 8 - 120.28.62.0/24 8188 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 222.127.0.0/24 7806 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 115.170.128.0/17 6207 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 11 - 214.26.204.0/24 4851 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - 103.249.162.0/24 4801 0.2% AS45634 -- SPARKSTATION-SG-AP 10 Science Park Road 13 - 69.38.178.0/24 4494 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 46.17.204.0/24 4456 0.2% AS49675 -- SKBKONTUR-AS CJSC Production Company "SKB Kontur" 15 - 64.187.64.0/23 4408 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 16 - 168.223.200.0/22 4108 0.2% AS7202 -- FAMU - Florida A & M University 17 - 168.223.206.0/23 4059 0.2% AS7202 -- FAMU - Florida A & M University 18 - 62.84.76.0/24 4013 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 19 - 195.242.86.0/24 3948 0.2% AS34344 -- THE-PORT-OF-TILBURY-LONDON-LTD The Port Of Tilbury London Ltd 20 - 109.161.64.0/20 3815 0.2% AS13118 -- ASN-YARTELECOM OJSC Rostelecom Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From pashdown at xmission.com Sat Sep 14 03:06:42 2013 From: pashdown at xmission.com (Pete Ashdown) Date: Fri, 13 Sep 2013 21:06:42 -0600 Subject: Urgent, need bandwidth in Blue Springs, Missouri Message-ID: <5233D2C2.2090403@xmission.com> I've got a customer's point-to-point 50M that has taken too long to install and is averaging 5M throughput. If someone can drop a solid 50-100M DIA in Blue Springs, Missouri, I'd like to hear from you. Email me directly. Thanks in advance. From niels=nanog at bakker.net Mon Sep 16 16:36:22 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 16 Sep 2013 18:36:22 +0200 Subject: DNS Reliability In-Reply-To: <20130913201509.GC18576@vacation.karoshi.com.> References: <52327019.7070600@cox.net> <52336F2F.1030206@vaxination.ca> <20130913201509.GC18576@vacation.karoshi.com.> Message-ID: <20130916163622.GC3108@burnout.tpb.net> * bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) [Fri 13 Sep 2013, 22:16 CEST]: > from where? to where? what % of the Internet is _not_ > reachable from my DNS service at any given time? why is > that acceptable? and more importantly, who's job is it to > fix/stablize the net so these "remote" locations can reach > my DNS service? > > "we will answer 100% of the valid DNS queries we receive." Is this thread even about authoritative or recursive DNS? -- Niels. -- From nick at foobar.org Mon Sep 16 16:47:36 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 16 Sep 2013 17:47:36 +0100 Subject: DNS Reliability In-Reply-To: <20130916163622.GC3108@burnout.tpb.net> References: <52327019.7070600@cox.net> <52336F2F.1030206@vaxination.ca> <20130913201509.GC18576@vacation.karoshi.com.> <20130916163622.GC3108@burnout.tpb.net> Message-ID: <52373628.70808@foobar.org> On 16/09/2013 17:36, Niels Bakker wrote: > Is this thread even about authoritative or recursive DNS? as far as I can tell, it's about Or something. Nick From uwcableguy at gmail.com Mon Sep 16 17:01:48 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Mon, 16 Sep 2013 12:01:48 -0500 Subject: Cymru Bogon AS path change Message-ID: Did anyone else notice that the path changed from 65332 to 65332 65331 earlier today? We certainly did when we starting advertising all the bogons to our ISP peers. Probably should have had an inbound AS path filter on that cymru peering... From nick at foobar.org Mon Sep 16 17:10:14 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 16 Sep 2013 18:10:14 +0100 Subject: Cymru Bogon AS path change In-Reply-To: References: Message-ID: <52373B76.6050303@foobar.org> On 16/09/2013 18:01, Ben Bartsch wrote: > We certainly did when we starting advertising all the bogons to our ISP > peers. Probably should have had an inbound AS path filter on that cymru > peering... better still, tag them all with a BGP community to make a note that they are bogons from Cymru (i.e. immediately identifiable throughout your network), and also tag them with no-export to ensure that they cannot propagate outside your asn. as-path filters are inefficient from several points of view. Nick From robt at cymru.com Mon Sep 16 17:23:43 2013 From: robt at cymru.com (Rabbi Rob Thomas) Date: Mon, 16 Sep 2013 13:23:43 -0400 Subject: Cymru Bogon AS path change In-Reply-To: References: Message-ID: <52373E9F.4090905@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, NANOGers. > Did anyone else notice that the path changed from 65332 to 65332 65331 > earlier today? My apologies! We had a configuration "oops" during a migration to a new back-end infrastructure. We're working through that now, and I believe we have it sorted. I'll send out a more gory detailed update in a bit. > We certainly did when we starting advertising all the bogons to our ISP > peers. Probably should have had an inbound AS path filter on that cymru > peering... Yes, please, great advice from both you and Nick. Our Juniper configuration templates have something along these lines already. I need to add the same to our Cisco configuration snippets. Feedback on the configuration snippets is always welcome! Be the first in your ASN to add your name to the contributor list. :) Again my apologies for any inconvenience or consternation this mishap has caused. Thanks, Rob. - -- Rabbi Rob Thomas Team Cymru https://www.team-cymru.org/ "Does this augment or diminish human liberty?" - William F. Buckley -----BEGIN PGP SIGNATURE----- iQCVAwUBUjc+n1kX3QAo5sgJAQL4EQP+MIuA0TXvDIAXfDa2/0cW0k2pSpQqXuYe 52bYEMMHQDDLY+1XTXYnwrGGE/bcAIjyz6Mj9Kz0eN4FqvwTa2Nt64OjsQe6+drr eJoCp2kxOlYamX+tHX8KSd3Ge/l91LAkBms3GoM0CbL7JtBo+OZoZRUdYPj3PXdq EBH8eDQNboc= =8piW -----END PGP SIGNATURE----- From robt at cymru.com Mon Sep 16 17:34:15 2013 From: robt at cymru.com (Rabbi Rob Thomas) Date: Mon, 16 Sep 2013 13:34:15 -0400 Subject: Cymru Bogon AS path change In-Reply-To: <52373E9F.4090905@cymru.com> References: <52373E9F.4090905@cymru.com> Message-ID: <52374117.3050408@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, NANOGers. > My apologies! We had a configuration "oops" during a migration to a new > back-end infrastructure. We're working through that now, and I believe > we have it sorted. I'll send out a more gory detailed update in a bit. We're moving from Cisco gear to bird routing software (http://bird.network.cz) and there was a misconfiguration in one of our route reflectors. We tested this extensively but in a limited Unfortunately we didn't notice it until we brought all of the changes online. Since we've been at this a while, we figured there would be a couple of interesting "features" that arose during the change. :) We sent out an announcement of the change window to our bogon peers. Ben, did we miss you? If so, I apologize and please let me know. We'll ensure you're on the list for the next update. I probably should have sent this along to a few lists such as NANOG. Here's the announcement for the benefit of all: - --- snip snip --- Dear bogon feed subscriber, You are receiving this note because you are peering with one or more of our bogon route servers via BGP. Please be informed that there will be a maintenance window for the bogon route server project on Monday, September 16th from 14:00 to 18:00 GMT. WHAT IS HAPPENING? We will be making some improvements to the code that we use to generate the BGP bogon feeds. These changes are being done to make our service compliant with the new "extended" allocation and assignment reports being offered by the Regional Internet Registries (RIRs). HOW WILL I BE AFFECTED? Your BGP peering session should not flap during this maintenance window. However, you may notice our bogon routes get withdrawn and re-announced several times as a result of internal changes we are making. When the maintenance window is complete the number of routes you receive over your peering session should be as follows: IPv4 Bogons: approximately 3,300 routes IPv6 Bogons: approximately 44,000 routes DO I NEED TO MAKE ANY CHANGES ON MY SIDE? No. None of the parameters for the BGP peering sessions will be changing. The only setting you may need to adjust is if you have configured a prefix limit for the number of routes you'll accept from us. However, since the number of advertised routes is decreasing even this change is likely unnecessary. WHY ARE YOU DOING THIS? The new RIR extended allocation reports make some minor changes to the status definitions for network resources. All IP resources are now defined as one of the following: available allocated assigned reserved The meaning of these definitions can be found here: We are updating our software to use the new extended reports for tracking RIR allocations. Under the new system, we will only announce prefixes that are marked 'available' as bogons, along with special netblocks that are identified in RFC 3330, RFC 4291 and similar documents. Because this definition is more strict than what we used for the previous report format the overall number of bogon routes will decrease. It will also make the chances of accidentally identifying an allocated prefix as 'bogon' much less likely. WHO DO I CONTACT IF I HAVE QUESTIONS? You can reach us at support at cymru.com or by any of the methods listed at http://www.team-cymru.org/About/contact.html. Thank you for participating in the bogon feed project and for your continued support. Sincerely, Team Cymru - --- snip snip --- We're a bit past our change window, and my apologies for that. We're almost at the finish line, however, so I'll beg your indulgences while we wind it up. Thank you as always for your patience and support! Thanks, Rob. - -- Rabbi Rob Thomas Team Cymru https://www.team-cymru.org/ "Does this augment or diminish human liberty?" - William F. Buckley -----BEGIN PGP SIGNATURE----- iQCVAwUBUjdBF1kX3QAo5sgJAQJa9wQAj/JN/HnWDmKreK28//aXvlrY3Qa4K9G6 VDzfZ+6WE5DHk5BQIpQgBkcTB7DW0/Bu9FEU2loipJAqlcscb6GfOLofgfKJ1YYp cnAcpXQ/q4aZhOXdu4+9Gn7ZYSzNtAGiANIaGbRQLHbwIcwH1/0Nj9ym7sYVLl9D MuZjQ1DXBSs= =xN5l -----END PGP SIGNATURE----- From robt at cymru.com Mon Sep 16 17:58:27 2013 From: robt at cymru.com (Rabbi Rob Thomas) Date: Mon, 16 Sep 2013 13:58:27 -0400 Subject: Cymru Bogon AS path change In-Reply-To: <52374117.3050408@cymru.com> References: <52373E9F.4090905@cymru.com> <52374117.3050408@cymru.com> Message-ID: <523746C3.7050405@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, NANOGers. > We're a bit past our change window, and my apologies for that. We're > almost at the finish line, however, so I'll beg your indulgences while > we wind it up. We've completed the change and all looks migrated and happy. The change window is now closed. If anyone comes across anything that looks awry, please reach out to us at support at cymru.com and we will address it immediately. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru https://www.team-cymru.org/ "Does this augment or diminish human liberty?" - William F. Buckley -----BEGIN PGP SIGNATURE----- iQCVAwUBUjdGw1kX3QAo5sgJAQLYbwP+M8CIa/jLE4MKNLCTHVN3+SrGZCMxtLdm mgA/Tmjs+n2xvAW9RscTiDIMR5fazniPZhk/5+o9POIw17EKKWfIAcOF7CT2mxxw hSNmuirFEJ0FWfM3bT4P4TWj0dKjLFlVIJEsByumIn6hgUSPOVyNy1YpU7I/VwE0 2SQLAIek1uA= =El22 -----END PGP SIGNATURE----- From goemon at anime.net Mon Sep 16 18:25:52 2013 From: goemon at anime.net (goemon at anime.net) Date: Mon, 16 Sep 2013 11:25:52 -0700 (PDT) Subject: rr.com contact please Message-ID: Can someone from rr.com please contact me. Your abuse desk seems to believe this netblock does not belong to you: network:Class-Name:network network:ID:NETBLK-ISRC-24.39.128.0-17 network:Auth-Area:24.39.128.0/17 network:Org-Name:Road Runner Commercial network:Tech-Contact:ipaddreg at rr.com network:Updated:2013-09-16 10:40:06 network:IP-Network:24.39.128.0/17 network:Admin-Contact:IPADD-ARIN network:IP-Network-Range:24.39.128.0 - 24.39.255.255 -Dan From sebastian at nzrs.net.nz Mon Sep 16 20:45:56 2013 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Tue, 17 Sep 2013 08:45:56 +1200 Subject: DNS Reliability In-Reply-To: <70954.1379033121@turing-police.cc.vt.edu> References: <70954.1379033121@turing-police.cc.vt.edu> Message-ID: <52376E04.6010809@nzrs.net.nz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/09/13 12:45, Valdis.Kletnieks at vt.edu wrote: > On Thu, 12 Sep 2013 14:03:44 -0600, Phil Fagan said: >> Everything else remaining equal...is there a standard or >> expectation for DNS reliability? >> >> 98% 99% 99.5% 99.9% 99.99% 99.999% >> >> Measured in queries completed vs. queries lost. >> >> Whats the consensus? > > Remember to factor in Duane Wessel's work that showed that > something like 98% of the DNS traffic at the root servers was > totally bogus? > > Maybe you need to factor in "broken queries not answered, and > offenders slapped around with a large trout"? Because if it's > busted requests you're sending towards the root, they're going to > count against your completed/lost ratio in a really bad way. > > Anybody know if people have cleaned up their collective acts since > Duane did that paper? > Wearing a different hat, I had the chance to rerun that analysis with data from 2008 (original paper is from 2003) and the number were still around 98% http://www.caida.org/publications/presentations/2008/wide_castro_root_servers/wide_castro_root_servers.pdf Cheers, - -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlI3bfYACgkQWyqRrHcQWTkagwCeOaShzFH1i8q9Y34/cybV6bUY qBYAn1A8JPgNJqH6mijUFN7+4ufybJqZ =X7UE -----END PGP SIGNATURE----- From mpetach at netflight.com Tue Sep 17 02:06:38 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 16 Sep 2013 19:06:38 -0700 Subject: rr.com contact please In-Reply-To: References: Message-ID: On Mon, Sep 16, 2013 at 11:25 AM, wrote: > Can someone from rr.com please contact me. Your abuse desk seems to > believe this netblock does not belong to you: > > network:Class-Name:network > network:ID:NETBLK-ISRC-24.39.**128.0-17 > network:Auth-Area:24.39.128.0/**17 > network:Org-Name:Road Runner Commercial > network:Tech-Contact:ipaddreg@**rr.com > network:Updated:2013-09-16 10:40:06 > network:IP-Network:24.39.128.**0/17 > network:Admin-Contact:IPADD-**ARIN > network:IP-Network-Range:24.**39.128.0 - 24.39.255.255 > > -Dan > > If they don't want it, I'll be happy to take it off their hands... Matt From telmnstr at 757.org Tue Sep 17 03:00:38 2013 From: telmnstr at 757.org (telmnstr at 757.org) Date: Mon, 16 Sep 2013 23:00:38 -0400 (EDT) Subject: Bandwidth for a weekend @ Gaylord National Harbor, DC metro area Message-ID: I help with an event at the Gaylord at National Harbor in Maryland. It's a music and video gaming festival. The network team for the event is looking for options on getting bandwidth for ~5 days across a weekend at the hotel. RF or handoff in building. The large array of clearwire modems isn't cutting it any more. Looking for pointers I can give them. Please email off-list. Thanks! - Ethan O'Toole From nathana at fsr.com Tue Sep 17 03:21:51 2013 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 16 Sep 2013 20:21:51 -0700 Subject: rr.com contact please In-Reply-To: References: Message-ID: On Sep 16, 2013, at 19:07, "Matthew Petach" wrote: > On Mon, Sep 16, 2013 at 11:25 AM, wrote: > >> Can someone from rr.com please contact me. Your abuse desk seems to >> believe this netblock does not belong to you: [snip] > > If they don't want it, I'll be happy to take it > off their hands... ...fight ya for it. -- Nathan From morrowc.lists at gmail.com Tue Sep 17 04:08:17 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2013 00:08:17 -0400 Subject: rr.com contact please In-Reply-To: References: Message-ID: On Mon, Sep 16, 2013 at 11:21 PM, Nathan Anderson wrote: > On Sep 16, 2013, at 19:07, "Matthew Petach" wrote: > >> On Mon, Sep 16, 2013 at 11:25 AM, wrote: >> >>> Can someone from rr.com please contact me. Your abuse desk seems to >>> believe this netblock does not belong to you: [snip] >> >> If they don't want it, I'll be happy to take it >> off their hands... > > ...fight ya for it. In sydney I bought a real knife I bet I win. From morrowc.lists at gmail.com Tue Sep 17 04:38:07 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2013 00:38:07 -0400 Subject: Bandwidth for a weekend @ Gaylord National Harbor, DC metro area In-Reply-To: References: Message-ID: the katsucon folks do this hotel yearly... maybe finding them would be useful? http://www.katsucon.com/ On Mon, Sep 16, 2013 at 11:00 PM, wrote: > I help with an event at the Gaylord at National Harbor in Maryland. It's a > music and video gaming festival. The network team for the event is looking > for options on getting bandwidth for ~5 days across a weekend at the hotel. > RF or handoff in building. > > The large array of clearwire modems isn't cutting it any more. > > Looking for pointers I can give them. Please email off-list. > > Thanks! > > - Ethan O'Toole > > > From m4rtntns at gmail.com Tue Sep 17 10:52:44 2013 From: m4rtntns at gmail.com (Martin T) Date: Tue, 17 Sep 2013 13:52:44 +0300 Subject: common method to count traffic volume on IX Message-ID: Hi, many Internet exchange points post publicly available graphs which describe aggregated traffic volumes on IX. For example: Netnod: http://www.netnod.se/ix-stats/sums/ AMS-IX: https://www.ams-ix.net/technical/statistics LINX: https://www.linx.net/pubtools/trafficstats.html Is there a common method to count this traffic on a switch-fabric? Just read all the switch interface "packets input" counters with an interval to get the aggregated input traffic and read all the switch interfaces "packets output" counters to get the aggregated output traffic? regards, Martin From swmike at swm.pp.se Tue Sep 17 10:58:48 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 17 Sep 2013 12:58:48 +0200 (CEST) Subject: common method to count traffic volume on IX In-Reply-To: References: Message-ID: On Tue, 17 Sep 2013, Martin T wrote: > Is there a common method to count this traffic on a switch-fabric? Just > read all the switch interface "packets input" counters with an interval > to get the aggregated input traffic and read all the switch interfaces > "packets output" counters to get the aggregated output traffic? Yes, as far as I have understood it's a sum of all traffic on all customer-facing ports. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Tue Sep 17 11:02:08 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 17 Sep 2013 12:02:08 +0100 Subject: common method to count traffic volume on IX In-Reply-To: References: Message-ID: <523836B0.80403@foobar.org> On 17/09/2013 11:52, Martin T wrote: > Is there a common method to count this traffic on a switch-fabric? > Just read all the switch interface "packets input" counters with an > interval to get the aggregated input traffic and read all the switch > interfaces "packets output" counters to get the aggregated output > traffic? most IXPs count this as the sum of all ingress packets over a period of 300 seconds. A small number of IXPs do different stuff, e.g. different sampling interval or counting traffic on inter-switch links. Nick From dustin at rseng.net Tue Sep 17 11:48:11 2013 From: dustin at rseng.net (Dustin Jurman) Date: Tue, 17 Sep 2013 07:48:11 -0400 Subject: Bandwidth for a weekend @ Gaylord National Harbor, DC metro area In-Reply-To: References: Message-ID: <6DFA43D2-0273-43EE-8BE4-C296A854E4FB@rseng.net> WISPA.ORG would be a good resource. Dustin Jurman C.E.O Rapid Systems Corporation 1211 North Westshore BLVD suite 711 Tampa, Fl 33607 "Building Better Infrastructure" On Sep 17, 2013, at 12:38 AM, "Christopher Morrow" wrote: > the katsucon folks do this hotel yearly... maybe finding them would be useful? > http://www.katsucon.com/ > > On Mon, Sep 16, 2013 at 11:00 PM, wrote: >> I help with an event at the Gaylord at National Harbor in Maryland. It's a >> music and video gaming festival. The network team for the event is looking >> for options on getting bandwidth for ~5 days across a weekend at the hotel. >> RF or handoff in building. >> >> The large array of clearwire modems isn't cutting it any more. >> >> Looking for pointers I can give them. Please email off-list. >> >> Thanks! >> >> - Ethan O'Toole > > From patrick at ianai.net Tue Sep 17 13:43:35 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 17 Sep 2013 09:43:35 -0400 Subject: common method to count traffic volume on IX In-Reply-To: <523836B0.80403@foobar.org> References: <523836B0.80403@foobar.org> Message-ID: <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> On Sep 17, 2013, at 07:02 , Nick Hilliard wrote: > On 17/09/2013 11:52, Martin T wrote: >> Is there a common method to count this traffic on a switch-fabric? >> Just read all the switch interface "packets input" counters with an >> interval to get the aggregated input traffic and read all the switch >> interfaces "packets output" counters to get the aggregated output >> traffic? > > most IXPs count this as the sum of all ingress packets over a period of 300 > seconds. A small number of IXPs do different stuff, e.g. different > sampling interval or counting traffic on inter-switch links. I am unaware of any IXP that uses a smaller sampling period (presumably in an attempt to make their IXP look bigger) other than DE-CIX. Is there another one? And yes, DE-CIX is more than well aware everyone thinks this is .. uh .. let's just call it "silly" for now, although most would use far more disparaging words. Which is probably why no serious IXP does it. -- TTFN, patrick -------------- 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: From ag4ve.us at gmail.com Tue Sep 17 14:29:49 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 17 Sep 2013 10:29:49 -0400 Subject: Bandwidth for a weekend @ Gaylord National Harbor, DC metro area In-Reply-To: <6DFA43D2-0273-43EE-8BE4-C296A854E4FB@rseng.net> References: <6DFA43D2-0273-43EE-8BE4-C296A854E4FB@rseng.net> Message-ID: I'm not sure of te topology around there, but you can get these 2.4Ghz dishes for *cheap* (I got one at a hamfest for $20 - spent as much on the rp-sma converter cost almost as much). If someone (or a colo) is near there, you might convince them to put up the same thing and work with that. I think you'd be ok with a amateur radio operator since you're non-profit (and should only need one since they'd be the control for the remote station). If you setup legistics and aren't the same weekend as Shmoo (I think you are) I can help with that setup and check the regs and use my callsign. On Tue, Sep 17, 2013 at 7:48 AM, Dustin Jurman wrote: > WISPA.ORG would be a good resource. > > Dustin Jurman C.E.O > Rapid Systems Corporation > 1211 North Westshore BLVD suite 711 > Tampa, Fl 33607 > "Building Better Infrastructure" > > On Sep 17, 2013, at 12:38 AM, "Christopher Morrow" < > morrowc.lists at gmail.com> wrote: > > > the katsucon folks do this hotel yearly... maybe finding them would be > useful? > > http://www.katsucon.com/ > > > > On Mon, Sep 16, 2013 at 11:00 PM, wrote: > >> I help with an event at the Gaylord at National Harbor in Maryland. > It's a > >> music and video gaming festival. The network team for the event is > looking > >> for options on getting bandwidth for ~5 days across a weekend at the > hotel. > >> RF or handoff in building. > >> > >> The large array of clearwire modems isn't cutting it any more. > >> > >> Looking for pointers I can give them. Please email off-list. > >> > >> Thanks! > >> > >> - Ethan O'Toole > > > > > > From nick at foobar.org Tue Sep 17 15:04:49 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 17 Sep 2013 16:04:49 +0100 Subject: common method to count traffic volume on IX In-Reply-To: <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> Message-ID: <52386F91.5020801@foobar.org> On 17/09/2013 14:43, Patrick W. Gilmore wrote: > And yes, DE-CIX is more than well aware everyone thinks this is .. uh .. > let's just call it "silly" for now, although most would use far more > disparaging words. Which is probably why no serious IXP does it. It's not silly - it's just not what everyone else does, so it's not possible to directly compare stats with other ixps. I'm all in favour of using short (but technically sensible) sampling intervals for internal monitoring, but there are good reasons to use 300s / ingress sum for prettypics intended for public consumption. Nick From mpetach at netflight.com Tue Sep 17 15:36:16 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 17 Sep 2013 08:36:16 -0700 Subject: rr.com contact please In-Reply-To: References: Message-ID: On Mon, Sep 16, 2013 at 9:08 PM, Christopher Morrow wrote: > On Mon, Sep 16, 2013 at 11:21 PM, Nathan Anderson wrote: > > On Sep 16, 2013, at 19:07, "Matthew Petach" > wrote: > > > >> On Mon, Sep 16, 2013 at 11:25 AM, wrote: > >> > >>> Can someone from rr.com please contact me. Your abuse desk seems to > >>> believe this netblock does not belong to you: [snip] > >> > >> If they don't want it, I'll be happy to take it > >> off their hands... > > > > ...fight ya for it. > > In sydney I bought a real knife I bet I win. > > Pshaw! Who brings a knife to an IP fight?[0] ;-P [0] http://tvtropes.org/pmwiki/pmwiki.php/Main/NeverBringAKnifeToAGunFight From m4rtntns at gmail.com Tue Sep 17 16:11:23 2013 From: m4rtntns at gmail.com (Martin T) Date: Tue, 17 Sep 2013 19:11:23 +0300 Subject: common method to count traffic volume on IX In-Reply-To: <52386F91.5020801@foobar.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: Thanks for all the replies! Nick, counting traffic on inter-switch links is kind of cheating, isn't it? I mean if "input bytes" and "output bytes" on all the ports facing the IX members are already counted, then counting traffic on links between the switches in fabric will count some of the traffic multiple times. Patrick, how does smaller sampling period help to show more traffic volume on switch fabric? Or do you mean that in case of shorter sampling periods the traffic peaks are not averaged out and thus peak in and peak out traffic levels remain higher? regards, Martin On 9/17/13, Nick Hilliard wrote: > On 17/09/2013 14:43, Patrick W. Gilmore wrote: >> And yes, DE-CIX is more than well aware everyone thinks this is .. uh .. >> let's just call it "silly" for now, although most would use far more >> disparaging words. Which is probably why no serious IXP does it. > > It's not silly - it's just not what everyone else does, so it's not > possible to directly compare stats with other ixps. I'm all in favour of > using short (but technically sensible) sampling intervals for internal > monitoring, but there are good reasons to use 300s / ingress sum for > prettypics intended for public consumption. > > Nick > > > From m4rtntns at gmail.com Tue Sep 17 16:21:41 2013 From: m4rtntns at gmail.com (Martin T) Date: Tue, 17 Sep 2013 19:21:41 +0300 Subject: common checks performed when passing on an IPv4 PA allocation from one end-customer to another Message-ID: Hi, when one end-customer has been using for example /24 IPv4 allocation for a while and returns this(for example changes an ISP) to LIR, then are there some good practices before handing out this same /24 to a new customer? I guess LIR should: 1) remove all the DNS PTR records, classless of classful delegations 2) check if some of the IP addresses are in DNSBL(maybe the previous customer was a spammer). Example with 93.184.216.0/24: $ for ip in {0..255}.216.184.93;\ > do for addr in \ > cbl.abuseat.org \ > dnsbl.inps.de \ > no-more-funn.moensted.dk \ > dnsbl.sorbs.net \ > bl.spamcannibal.org \ > bl.spamcop.net \ > psbl.surriel.com \ > dnsrbl.swinog.ch; \ > do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \ > echo "DNSBL-Alarm: $ip is listed on $addr"; done; done $ Anything else? regards, Martin From patrick at ianai.net Tue Sep 17 18:13:36 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 17 Sep 2013 14:13:36 -0400 Subject: common method to count traffic volume on IX In-Reply-To: <52386F91.5020801@foobar.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: <5557C1F5-D45C-49FA-989A-F955EDAFED0B@ianai.net> On Sep 17, 2013, at 11:04 , Nick Hilliard wrote: > On 17/09/2013 14:43, Patrick W. Gilmore wrote: >> And yes, DE-CIX is more than well aware everyone thinks this is .. uh .. >> let's just call it "silly" for now, although most would use far more >> disparaging words. Which is probably why no serious IXP does it. > > It's not silly We disagree. > it's just not what everyone else does I don't think anyone else does 2 minutes, but happy to be educated otherwise. > so it's not > possible to directly compare stats with other ixps. I'm all in favour of > using short (but technically sensible) sampling intervals for internal > monitoring, but there are good reasons to use 300s / ingress sum for > prettypics intended for public consumption. Your IXP (network, whatever), you decision. Use 2 second timers for all I care. Unfortunately, DE-CIX has done exactly what you said - compared themselves to other IXPs using that apples-to-oranges comparison. There are words for that sort of thing, but they are impolite, and I otherwise like the people at DE-CIX, so I shall let each NANOG-ite decide how to view such, um, tactics. -- TTFN, patrick -------------- 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: From patrick at ianai.net Tue Sep 17 18:15:14 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 17 Sep 2013 14:15:14 -0400 Subject: common method to count traffic volume on IX In-Reply-To: References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: On Sep 17, 2013, at 12:11 , Martin T wrote: > Thanks for all the replies! > > > Nick, > > counting traffic on inter-switch links is kind of cheating, isn't it? > I mean if "input bytes" and "output bytes" on all the ports facing the > IX members are already counted, then counting traffic on links between > the switches in fabric will count some of the traffic multiple times. > > > > Patrick, > > how does smaller sampling period help to show more traffic volume on > switch fabric? Or do you mean that in case of shorter sampling periods > the traffic peaks are not averaged out and thus peak in and peak out > traffic levels remain higher? The graph has a bigger peak, and DE-CIX has claimed "see, we are bigger" using such graphs. Not only did they not caveat the fact they were using a non-standard sampling method, they have refused to change when confronted or even say what their traffic would be with a 300 second timer. -- TTFN, patrick > On 9/17/13, Nick Hilliard wrote: >> On 17/09/2013 14:43, Patrick W. Gilmore wrote: >>> And yes, DE-CIX is more than well aware everyone thinks this is .. uh .. >>> let's just call it "silly" for now, although most would use far more >>> disparaging words. Which is probably why no serious IXP does it. >> >> It's not silly - it's just not what everyone else does, so it's not >> possible to directly compare stats with other ixps. I'm all in favour of >> using short (but technically sensible) sampling intervals for internal >> monitoring, but there are good reasons to use 300s / ingress sum for >> prettypics intended for public consumption. >> >> Nick >> >> >> > -------------- 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: From bicknell at ufp.org Tue Sep 17 18:51:53 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 17 Sep 2013 11:51:53 -0700 Subject: common method to count traffic volume on IX In-Reply-To: References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: <20130917185152.GA66624@ussenterprise.ufp.org> In a message written on Tue, Sep 17, 2013 at 07:11:23PM +0300, Martin T wrote: > counting traffic on inter-switch links is kind of cheating, isn't it? > I mean if "input bytes" and "output bytes" on all the ports facing the > IX members are already counted, then counting traffic on links between > the switches in fabric will count some of the traffic multiple times. Sounds like a marketing opportunity. customer--s1--s2--s3--s4--s5--s6--s7--s8--s9--s10--customer Presto, highest volume IX! Maybe I should patent that idea. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tom.taylor.stds at gmail.com Tue Sep 17 19:17:57 2013 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Tue, 17 Sep 2013 15:17:57 -0400 Subject: common method to count traffic volume on IX In-Reply-To: References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: <5238AAE5.20706@gmail.com> On 17/09/2013 2:15 PM, Patrick W. Gilmore wrote: > On Sep 17, 2013, at 12:11 , Martin T wrote: > >> Thanks for all the replies! >> >> >> Nick, >> >> counting traffic on inter-switch links is kind of cheating, isn't it? >> I mean if "input bytes" and "output bytes" on all the ports facing the >> IX members are already counted, then counting traffic on links between >> the switches in fabric will count some of the traffic multiple times. >> >> >> >> Patrick, >> >> how does smaller sampling period help to show more traffic volume on >> switch fabric? Or do you mean that in case of shorter sampling periods >> the traffic peaks are not averaged out and thus peak in and peak out >> traffic levels remain higher? > > The graph has a bigger peak, and DE-CIX has claimed "see, we are bigger" using such graphs. Not only did they not caveat the fact they were using a non-standard sampling method, they have refused to change when confronted or even say what their traffic would be with a 300 second timer. > That's easy to counter. just estimate some characteristics of the distribution from the sample, then apply extreme value theory to renormalize to 300 s. (My math background talking. I once got similar stuff written into an ITU-T recommendation for provisioning trunk groups based on limited traffic samples.) Tom T. From alter3d at alter3d.ca Tue Sep 17 19:21:27 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 17 Sep 2013 15:21:27 -0400 Subject: common method to count traffic volume on IX In-Reply-To: <20130917185152.GA66624@ussenterprise.ufp.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> Message-ID: <5238ABB7.1040403@alter3d.ca> On 9/17/2013 2:51 PM, Leo Bicknell wrote: > In a message written on Tue, Sep 17, 2013 at 07:11:23PM +0300, Martin T wrote: >> counting traffic on inter-switch links is kind of cheating, isn't it? >> I mean if "input bytes" and "output bytes" on all the ports facing the >> IX members are already counted, then counting traffic on links between >> the switches in fabric will count some of the traffic multiple times. > Sounds like a marketing opportunity. > > customer--s1--s2--s3--s4--s5--s6--s7--s8--s9--s10--customer > > Presto, highest volume IX! > > Maybe I should patent that idea. > "Why do you have 10 48-port switches, 239 VLANs, but only 2 peers?" "Uhh... for accounting reasons." From niels=nanog at bakker.net Tue Sep 17 20:15:23 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 17 Sep 2013 22:15:23 +0200 Subject: common method to count traffic volume on IX In-Reply-To: <20130917185152.GA66624@ussenterprise.ufp.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> Message-ID: <20130917201523.GD3108@burnout.tpb.net> >In a message written on Tue, Sep 17, 2013 at 07:11:23PM +0300, Martin T wrote: >>counting traffic on inter-switch links is kind of cheating, isn't >>it? I mean if "input bytes" and "output bytes" on all the ports >>facing the IX members are already counted, then counting traffic >>on links between the switches in fabric will count some of the >>traffic multiple times. I don't know of any IXP that does this. Industry standard is as you and others wrote before: the 5-minute counter difference on all customer-facing ports, publishing both input and output bps and pps. I guess MRTG is to 'blame' for these values more than anything. * bicknell at ufp.org (Leo Bicknell) [Tue 17 Sep 2013, 20:52 CEST]: >Sounds like a marketing opportunity. > >customer--s1--s2--s3--s4--s5--s6--s7--s8--s9--s10--customer > >Presto, highest volume IX! Highest latency too, and here's to hoping all those devices actually work - it'll sure be an interesting exercise to find out wat switch in the path dropped a frame - you might as well just multiply your stats to get the same effect -- Niels. From morrowc.lists at gmail.com Tue Sep 17 22:08:58 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2013 18:08:58 -0400 Subject: rr.com contact please In-Reply-To: References: Message-ID: On Tue, Sep 17, 2013 at 11:36 AM, Matthew Petach wrote: > On Mon, Sep 16, 2013 at 9:08 PM, Christopher Morrow > wrote: >> >> On Mon, Sep 16, 2013 at 11:21 PM, Nathan Anderson wrote: >> > On Sep 16, 2013, at 19:07, "Matthew Petach" >> > wrote: >> > >> >> On Mon, Sep 16, 2013 at 11:25 AM, wrote: >> >> >> >>> Can someone from rr.com please contact me. Your abuse desk seems to >> >>> believe this netblock does not belong to you: [snip] >> >> >> >> If they don't want it, I'll be happy to take it >> >> off their hands... >> > >> > ...fight ya for it. >> >> In sydney I bought a real knife I bet I win. >> > > Pshaw! Who brings a knife to an IP fight?[0] ;-P > > [0] http://tvtropes.org/pmwiki/pmwiki.php/Main/NeverBringAKnifeToAGunFight have to fight off the lawyers first, right? From m.hallgren at free.fr Tue Sep 17 23:24:29 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 18 Sep 2013 01:24:29 +0200 Subject: common method to count traffic volume on IX In-Reply-To: References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: <5238E4AD.9030103@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 17/09/2013 20:15, Patrick W. Gilmore a ?crit : Hi, Good reading, to get an idea: https://www1.ethz.ch/csg/people/dimitroc/papers/p95pam.pdf Section 3, mainly. Cheers, mh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlI45KgACgkQZNZ/rrgsqae9JQCghTqXy8+bL6eq95ZD/DHvbTCx izwAniJ1Fiq1zsbZmewT464eG/S4RinZ =R+r3 -----END PGP SIGNATURE----- From m.hallgren at free.fr Tue Sep 17 23:24:29 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 18 Sep 2013 01:24:29 +0200 Subject: common method to count traffic volume on IX In-Reply-To: References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> Message-ID: <5238E4AD.5020205@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 17/09/2013 20:15, Patrick W. Gilmore a ?crit : > On Sep 17, 2013, at 12:11 , Martin T wrote: > >> Thanks for all the replies! >> >> >> Nick, >> >> counting traffic on inter-switch links is kind of cheating, isn't it? >> I mean if "input bytes" and "output bytes" on all the ports facing the >> IX members are already counted, then counting traffic on links between >> the switches in fabric will count some of the traffic multiple times. >> >> >> >> Patrick, >> >> how does smaller sampling period help to show more traffic volume on >> switch fabric? Or do you mean that in case of shorter sampling periods >> the traffic peaks are not averaged out and thus peak in and peak out >> traffic levels remain higher? Hi, Good reading, to get an idea: https://www1.ethz.ch/csg/people/dimitroc/papers/p95pam.pdf Section 3, mainly. Cheers, mh >> > > The graph has a bigger peak, and DE-CIX has claimed "see, we are bigger" using such graphs. Not only did they not caveat the fact they were using a non-standard sampling method, they have refused to change when confronted or even say what their traffic would be with a 300 second timer. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlI45K0ACgkQZNZ/rrgsqaeSAQCfR93/ksBGa1KRW6P6zLR2cRwG 2fEAnRlZMtamameFoQgVdYZwTKD7Lb1b =UVol -----END PGP SIGNATURE----- From randy at psg.com Wed Sep 18 02:39:19 2013 From: randy at psg.com (Randy Bush) Date: Tue, 17 Sep 2013 16:39:19 -1000 Subject: common method to count traffic volume on IX In-Reply-To: References: Message-ID: somehow, a serious case of testosterone poisoning combined with insane goal drift has hit a number of the large european exchanges. instead of the goal being how well they serve their local communities, they have gone wild with sleazy means of having traffic contests, doing really sick attempts at techno-colonial expansion into foreign countries and continents, ... instead of running a public service, they think they are running competitive commercial enterprises. imiho, the members should be up in arms. if you are jealous of commercial expansion, then send your resume to equinix. sheesh! randy From NANOG at abcsupply.com Wed Sep 18 16:07:25 2013 From: NANOG at abcsupply.com (NANOG) Date: Wed, 18 Sep 2013 16:07:25 +0000 Subject: The block message is 521 DNSRBL: Blocked for abuse Message-ID: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> We recently purchased new IP addresses from ARIN, with plans on using one of them for our external and internal email delivery. We set up a reverse lookup and a SPF record for the newly purchased IP to prevent being classified as spam. We tested the functionality of the PTR and SPF record successfully using varies internet tools like dnsstuff.com, mxtoolbox.com, and kitterman.com. Unfortunately, when we send emails to any AT&T or Network Solutions hosted email we are being block as a spam abuser. I checked varies spam database tools and our IP addresses are not listed, but we are still being blocked by both AT&T and Network Solution. The block message is 521 DNSRBL: Blocked for abuse. In an attempt to be proactive, I contacted Network Solution and was told that each recipient would have to request we be whitelisted, and AT&T directed me to an online form that I submitted to be removed from the blacklist. Unfortunately, we are still not able to send emails to either AT&T or Network Solutions hosted emails. Our mail server IP address is 74.112.99.25, which resolves to mail.abcsupply.com. Does anyone have any suggestions on where to turn next? Is it possible they are blocking us based on old information from the previous IP address block owner? Any help tracking this down would be appreciated. Derrick Wash Microsoft Systems Administrator ABC Supply Company Inc Office: (608)368-2214 Fax: (608)363-0214 From hschiller at google.com Wed Sep 18 16:33:49 2013 From: hschiller at google.com (Heather Schiller) Date: Wed, 18 Sep 2013 12:33:49 -0400 Subject: mlb.com Geolocation clue/contact needed Message-ID: Anyone have a contact at mlb.com that could help resolve an ip geolocation issue? (Networking, db.. or someone who can help find the right folks) Alternatively, anyone know who mlb.com buys geolocation data from? It's related to their baseball game streaming/subscription service. Whitelisting individual users is not a scalable solution. offline answers are welcome too -- Thanks, --Heather From eugen at leitl.org Wed Sep 18 16:37:06 2013 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 18 Sep 2013 18:37:06 +0200 Subject: [liberationtech] Brazil Looks to Break from U.S.-Centric Internet Message-ID: <20130918163706.GY10405@leitl.org> ----- Forwarded message from Bill Woodcock ----- Date: Wed, 18 Sep 2013 09:25:13 -0700 From: Bill Woodcock To: liberationtech Subject: Re: [liberationtech] Brazil Looks to Break from U.S.-Centric Internet X-Mailer: Apple Mail (2.1508) Reply-To: liberationtech On Sep 18, 2013, at 8:28 AM, David Johnson wrote: > Interesting ... but is this even possible? > http://world.time.com/2013/09/18/brazil-looks-to-break-from-u-s-centric-internet/ Well, there are a bunch of different concepts being discussed. The primary one is localization of routing, which isn't just possible, it's best-practice, and something Brazil has been doing an excellent job of already for quite a few years. If you look at https://pch.net/applications/ixpdir/summary/ you'll see that they've got 23 active exchanges, which puts them second in the world after the U.S., with 77% annualized growth, compared to 10% in the U.S. If you look at the Brazil section of https://pch.net/ixpdir you'll see that almost all of that growth has been occurring since they made it an explicit policy goal in 2008, and began aggressively implementing IXP best-practices. At a governance level, Brazil is divided. The CGI, which decides and implements domestic Internet policy, is the agency responsible for all this growth and best-practices-following. As such, they've been largely aligned with OECD-country and Internet interests. The Brazilian federal government, on the other hand, sets foreign policy, interacts with the ITU, et cetera. And so although it has no appreciable influence over what happens _within_ the country, it's what's seen by other national governments in diplomatic circles. In Internet governance, Brazil tends toward this Brazil-India-South Africa axis, which doesn't particularly align with the Internet or OECD countries, unless by accident. This is the area that Internet folks are most worried about, since those three countries are second-tier thought-leaders in the ITU, and can swing a lot of developing-country votes in their respective regions. So Brazil is, in many ways, the U.S.' opposite: they do the right thing domestically, but say the wrong thing internationally. -Bill -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From mike at schuler.me Wed Sep 18 16:53:59 2013 From: mike at schuler.me (Michael Schuler) Date: Wed, 18 Sep 2013 11:53:59 -0500 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: <626899F1-7852-4D5F-B00F-23EA21D7E914@schuler.me> My experience in the past is that it can take a good amount of time for ATT to remove you from their black list. It's been as short as 24 - 48 hours and as long as a couple weeks and required follow up contact with support. They're a big company and they get a lot of requests. I've not dealt with Network Solutions or their RBL list as far as how to get whitelisted. But it sounds like they manage it in a way where the recipient has to accept email from you. It's probably not practical but can you contact the recipients on Network Solutions via another method to have them whitelist you? >From the sounds of t the IP address you purchased was previously used by a spammer and now you're paying the price for it. Perhaps there are contacts on this list from ATT/Network Solutions that can contact you off list to help you resolve that. Good luck! Mike Schuler a guy On Sep 18, 2013, at 11:07 AM, NANOG wrote: > We recently purchased new IP addresses from ARIN, with plans on using one of them for our external and internal email delivery. We set up a reverse lookup and a SPF record for the newly purchased IP to prevent being classified as spam. We tested the functionality of the PTR and SPF record successfully using varies internet tools like dnsstuff.com, mxtoolbox.com, and kitterman.com. Unfortunately, when we send emails to any AT&T or Network Solutions hosted email we are being block as a spam abuser. I checked varies spam database tools and our IP addresses are not listed, but we are still being blocked by both AT&T and Network Solution. The block message is 521 DNSRBL: Blocked for abuse. In an attempt to be proactive, I contacted Network Solution and was told that each recipient would have to request we be whitelisted, and AT&T directed me to an online form that I submitted to be removed from the blacklist. Unfortunately, we are still not able to send emails to either AT&T or Network Solutions hosted emails. Our mail server IP address is 74.112.99.25, which resolves to mail.abcsupply.com. Does anyone have any suggestions on where to turn next? Is it possible they are blocking us based on old information from the previous IP address block owner? Any help tracking this down would be appreciated. > > > Derrick Wash > Microsoft Systems Administrator > ABC Supply Company Inc > Office: (608)368-2214 > Fax: (608)363-0214 > > > From jleq96 at gmail.com Wed Sep 18 16:59:13 2013 From: jleq96 at gmail.com (John LeCoque) Date: Wed, 18 Sep 2013 11:59:13 -0500 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: I would say the first step is to find an immediate workaround for your end users - maybe bring up a VM on AWS or some other cloud provider to use as an SMTP relay while you work out the blacklist issue. If you run into blacklist issues after that, you may want to take a very close look at your outbound mailflow to make sure your organization isn't sending out messages that could be categorized as spam. Getting IPs removed from a provider blacklist can be time consuming. You may be lucky enough to reach a clueful contact at the providers you mentioned on this list - but if you don't, you will have to navigate the removal process with each provider that has blacklisted you. On Wed, Sep 18, 2013 at 11:07 AM, NANOG wrote: > We recently purchased new IP addresses from ARIN, with plans on using one > of them for our external and internal email delivery. We set up a reverse > lookup and a SPF record for the newly purchased IP to prevent being > classified as spam. We tested the functionality of the PTR and SPF record > successfully using varies internet tools like dnsstuff.com, mxtoolbox.com, > and kitterman.com. Unfortunately, when we send emails to any AT&T or > Network Solutions hosted email we are being block as a spam abuser. I > checked varies spam database tools and our IP addresses are not listed, but > we are still being blocked by both AT&T and Network Solution. The block > message is 521 DNSRBL: Blocked for abuse. In an attempt to be proactive, I > contacted Network Solution and was told that each recipient would have to > request we be whitelisted, and AT&T directed me to an online form that I > submitted to be removed from the blacklist. Unfortunately, we are still > not able to send emails to either AT&T or Network Solutions hosted emails. > Our mail server IP address is 74.112.99.25, which resolves to > mail.abcsupply.com. Does anyone have any suggestions on where to turn > next? Is it possible they are blocking us based on old information from > the previous IP address block owner? Any help tracking this down would be > appreciated. > > > Derrick Wash > Microsoft Systems Administrator > ABC Supply Company Inc > Office: (608)368-2214 > Fax: (608)363-0214 > > From jmamodio at gmail.com Wed Sep 18 17:04:54 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 18 Sep 2013 12:04:54 -0500 Subject: [liberationtech] Brazil Looks to Break from U.S.-Centric Internet In-Reply-To: <20130918163706.GY10405@leitl.org> References: <20130918163706.GY10405@leitl.org> Message-ID: LOL, we'll move the taps one layer down ... -J On Wed, Sep 18, 2013 at 11:37 AM, Eugen Leitl wrote: > ----- Forwarded message from Bill Woodcock ----- > > Date: Wed, 18 Sep 2013 09:25:13 -0700 > From: Bill Woodcock > To: liberationtech > Subject: Re: [liberationtech] Brazil Looks to Break from U.S.-Centric > Internet > X-Mailer: Apple Mail (2.1508) > Reply-To: liberationtech > > > On Sep 18, 2013, at 8:28 AM, David Johnson > wrote: > > > Interesting ... but is this even possible? > > > http://world.time.com/2013/09/18/brazil-looks-to-break-from-u-s-centric-internet/ > > Well, there are a bunch of different concepts being discussed. The > primary one is localization of routing, which isn't just possible, it's > best-practice, and something Brazil has been doing an excellent job of > already for quite a few years. If you look at > https://pch.net/applications/ixpdir/summary/ you'll see that they've got > 23 active exchanges, which puts them second in the world after the U.S., > with 77% annualized growth, compared to 10% in the U.S. If you look at the > Brazil section of https://pch.net/ixpdir you'll see that almost all of > that growth has been occurring since they made it an explicit policy goal > in 2008, and began aggressively implementing IXP best-practices. > > At a governance level, Brazil is divided. The CGI, which decides and > implements domestic Internet policy, is the agency responsible for all this > growth and best-practices-following. As such, they've been largely aligned > with OECD-country and Internet interests. The Brazilian federal > government, on the other hand, sets foreign policy, interacts with the ITU, > et cetera. And so although it has no appreciable influence over what > happens _within_ the country, it's what's seen by other national > governments in diplomatic circles. In Internet governance, Brazil tends > toward this Brazil-India-South Africa axis, which doesn't particularly > align with the Internet or OECD countries, unless by accident. This is the > area that Internet folks are most worried about, since those three > countries are second-tier thought-leaders in the ITU, and can swing a lot > of developing-country votes in their respective regions. So Brazil is, in > many ways, the U.S.' opposite: they do the right thing domestically, but > say the wrong thing internationally. > > -Bill > > > > > > > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > companys at stanford.edu. > > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 > From woody at pch.net Wed Sep 18 17:15:02 2013 From: woody at pch.net (Bill Woodcock) Date: Wed, 18 Sep 2013 10:15:02 -0700 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: On Sep 18, 2013, at 9:07 AM, NANOG wrote: > We recently purchased new IP addresses from ARIN No, actually, you didn't. You were assigned the use of the addresses, based on need. Just as a radio station does not "purchase" spectrum. https://www.arin.net/policy/nrpm.html#four3 > Our mail server IP address is 74.112.99.25. Is it possible they are blocking us based on old information from the previous IP address block owner? Quite likely, yes. John LeCoque's suggestions seemed quite sound: > I would say the first step is to find an immediate workaround for your end > users - maybe bring up a VM on AWS or some other cloud provider to use as > an SMTP relay while you work out the blacklist issue. If you run into > blacklist issues after that, you may want to take a very close look at your > outbound mailflow to make sure your organization isn't sending out messages > that could be categorized as spam. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bicknell at ufp.org Wed Sep 18 17:23:12 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Sep 2013 12:23:12 -0500 Subject: common method to count traffic volume on IX In-Reply-To: <20130917201523.GD3108@burnout.tpb.net> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> Message-ID: <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> On Sep 17, 2013, at 3:15 PM, Niels Bakker wrote: > I don't know of any IXP that does this. Industry standard is as you and others wrote before: the 5-minute counter difference on all customer-facing ports, publishing both input and output bps and pps. > I guess MRTG is to 'blame' for these values more than anything. Serious question, at an IXP shouldn't IN = OUT nearly perfectly? Most exchanges do everything possible to eliminate broadcast packets, and they don't allow multicast on the unicast VLAN's. So properly behaved you have a bunch of routers speaking unicast to each other. The only way to get a difference is if there is packet loss, IN - loss = OUT. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From zachary.mcgibbon+nanog at gmail.com Wed Sep 18 17:38:42 2013 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 18 Sep 2013 13:38:42 -0400 Subject: iOS 7 update traffic Message-ID: So iOS 7 just came out, here's the spike in our graphs going to our ISP here at McGill, anyone else noticing a big spike? [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - TenGigabitEthernet0/7] Zachary McGibbon From Jean-Francois.TremblayING at videotron.com Wed Sep 18 17:47:57 2013 From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com) Date: Wed, 18 Sep 2013 13:47:57 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: > > Our mail server IP address is 74.112.99.25. Is it possible they > are blocking us based on old information from the previous IP > address block owner? > > Quite likely, yes. https://www.arin.net/resources/whowas/ Found it to be of use for this type of question. Registration required. Geolocation information often needs updating for these "recycled" ranges. /JF From zachary.mcgibbon+nanog at gmail.com Wed Sep 18 17:53:15 2013 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 18 Sep 2013 13:53:15 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: Hmm.. seems my image was stripped. I'm trying imgur for the first time so here's our graph: http://i.imgur.com/OrtjJXF.jpg On Wed, Sep 18, 2013 at 1:38 PM, Zachary McGibbon < zachary.mcgibbon+nanog at gmail.com> wrote: > So iOS 7 just came out, here's the spike in our graphs going to our ISP > here at McGill, anyone else noticing a big spike? > > [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - > TenGigabitEthernet0/7] > > Zachary McGibbon > From achatz at forthnetgroup.gr Wed Sep 18 17:59:33 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 18 Sep 2013 20:59:33 +0300 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <5239EA05.8050303@forthnetgroup.gr> We also noticed an interesting spike (+ ~40%), mostly in akamai. The same happened on previous iOS too. -- Tassos Zachary McGibbon wrote on 18/9/2013 20:38: > So iOS 7 just came out, here's the spike in our graphs going to our ISP > here at McGill, anyone else noticing a big spike? > > [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - > TenGigabitEthernet0/7] > > Zachary McGibbon > From edward.dore at freethought-internet.co.uk Wed Sep 18 18:09:02 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 18 Sep 2013 19:09:02 +0100 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <8C118032-3382-4ACB-8D68-75A3A76E0D5B@freethought-internet.co.uk> Various EU IXPs are showing spikes of various sizes at the moment LINX: http://cl.ly/image/3n1521432S1R LONAP: http://cl.ly/image/0W2K0q3p3f2h AMS-IX: http://cl.ly/image/0r0J2b331E2A DE-CIX: http://cl.ly/image/0D1B181N103A Akamai (who I believe Apple use for at least some of their CDN delivery) are also showing a nice hotspot in Europe at the moment: http://www.akamai.com/html/technology/dataviz1.html (screenshot for posterity: http://cl.ly/image/0f3W2g3P2D3g) Edward Dore Freethought Internet On 18 Sep 2013, at 18:53, Zachary McGibbon wrote: > Hmm.. seems my image was stripped. I'm trying imgur for the first time so > here's our graph: > > http://i.imgur.com/OrtjJXF.jpg > > > On Wed, Sep 18, 2013 at 1:38 PM, Zachary McGibbon < > zachary.mcgibbon+nanog at gmail.com> wrote: > >> So iOS 7 just came out, here's the spike in our graphs going to our ISP >> here at McGill, anyone else noticing a big spike? >> >> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >> TenGigabitEthernet0/7] >> >> Zachary McGibbon >> From uwcableguy at gmail.com Wed Sep 18 18:10:19 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Wed, 18 Sep 2013 13:10:19 -0500 Subject: iOS 7 update traffic In-Reply-To: <5239EA05.8050303@forthnetgroup.gr> References: <5239EA05.8050303@forthnetgroup.gr> Message-ID: We are seeing Akamai traffic up about 100-300% since noon CDT. Seeing similar increased from our participants - colleges and universities mainly. AS32440 -ben On Wed, Sep 18, 2013 at 12:59 PM, Tassos Chatzithomaoglou < achatz at forthnetgroup.gr> wrote: > We also noticed an interesting spike (+ ~40%), mostly in akamai. > The same happened on previous iOS too. > > -- > Tassos > > Zachary McGibbon wrote on 18/9/2013 20:38: > > So iOS 7 just came out, here's the spike in our graphs going to our ISP > > here at McGill, anyone else noticing a big spike? > > > > [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - > > TenGigabitEthernet0/7] > > > > Zachary McGibbon > > > > > From josh.hoppes at gmail.com Wed Sep 18 18:19:00 2013 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Wed, 18 Sep 2013 13:19:00 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <5239EA05.8050303@forthnetgroup.gr> Message-ID: Our local Akamai cluster has pegged it's 1G uplink a few times, and we are hitting our 1G Equinix IX link pretty hard as well. On Wed, Sep 18, 2013 at 1:10 PM, Ben Bartsch wrote: > We are seeing Akamai traffic up about 100-300% since noon CDT. Seeing > similar increased from our participants - colleges and universities mainly. > > AS32440 > > -ben > > > On Wed, Sep 18, 2013 at 12:59 PM, Tassos Chatzithomaoglou < > achatz at forthnetgroup.gr> wrote: > >> We also noticed an interesting spike (+ ~40%), mostly in akamai. >> The same happened on previous iOS too. >> >> -- >> Tassos >> >> Zachary McGibbon wrote on 18/9/2013 20:38: >> > So iOS 7 just came out, here's the spike in our graphs going to our ISP >> > here at McGill, anyone else noticing a big spike? >> > >> > [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >> > TenGigabitEthernet0/7] >> > >> > Zachary McGibbon >> > >> >> >> From sam at themerritts.org Wed Sep 18 18:21:03 2013 From: sam at themerritts.org (Sam Hayes Merritt, III) Date: Wed, 18 Sep 2013 13:21:03 -0500 (CDT) Subject: iOS 7 update traffic In-Reply-To: References: <5239EA05.8050303@forthnetgroup.gr> Message-ID: > We are seeing Akamai traffic up about 100-300% since noon CDT. Seeing > similar increased from our participants - colleges and universities mainly. Ours is not so much Akamai as Limelight. Spiked to about 7 times normal. sam From bedard.phil at gmail.com Wed Sep 18 18:32:36 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 18 Sep 2013 14:32:36 -0400 Subject: iOS 7 update traffic In-Reply-To: Message-ID: Large US MSO. Our overall traffic is up about 20% compared to this time yesterday, which equates to ~120Gbps. Mostly Akamai. -Phil On 9/18/13 1:38 PM, "Zachary McGibbon" wrote: >So iOS 7 just came out, here's the spike in our graphs going to our ISP >here at McGill, anyone else noticing a big spike? > >[image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >TenGigabitEthernet0/7] > >Zachary McGibbon From wbailey at satelliteintelligencegroup.com Wed Sep 18 18:36:19 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 18 Sep 2013 18:36:19 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: Do you guys not have a local akamai node?? Seems like maybe @gilmore could help you out, that's a pretty intense surge for software updates. Our stuff gets hit, but nothing like this (our networks usually don't exceed 40mbps over satellite). The MSO I used to work at had a fairly large akamai cache in Anchorage, AK. May be worth looking into if you guys haven't already. On 9/18/13 11:32 AM, "Phil Bedard" wrote: >Large US MSO. > >Our overall traffic is up about 20% compared to this time yesterday, which >equates to ~120Gbps. Mostly Akamai. > >-Phil > > > > > > >On 9/18/13 1:38 PM, "Zachary McGibbon" >wrote: > >>So iOS 7 just came out, here's the spike in our graphs going to our ISP >>here at McGill, anyone else noticing a big spike? >> >>[image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>TenGigabitEthernet0/7] >> >>Zachary McGibbon > > > From streiner at cluebyfour.org Wed Sep 18 18:22:16 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 18 Sep 2013 14:22:16 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: <5239EA05.8050303@forthnetgroup.gr> References: <5239EA05.8050303@forthnetgroup.gr> Message-ID: On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > We also noticed an interesting spike (+ ~40%), mostly in akamai. > The same happened on previous iOS too. I see it here, too. At its peak, our traffic levels were roughly double what we would see on a normal weekday. jms > Zachary McGibbon wrote on 18/9/2013 20:38: >> So iOS 7 just came out, here's the spike in our graphs going to our ISP >> here at McGill, anyone else noticing a big spike? >> >> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >> TenGigabitEthernet0/7] >> >> Zachary McGibbon >> > > > From tmetzinger at verizon.net Wed Sep 18 22:41:22 2013 From: tmetzinger at verizon.net (Timothy Metzinger) Date: Wed, 18 Sep 2013 18:41:22 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse Message-ID: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> Here's a thought. Would it be possible to set up a process where ARIN, as part of reselling IP addresses, either issues a certificate of transfer that the new owner can use to prove to the ISPs that he's a new owner and not the old evil spammer, or ARIN publishes a list of IP assignments that can be used by ISPs to provisionally remove them from blocked lists? I sympathize with the original poster, it's sort of like buying a used car, only to find out the previous owner was the drunk driver who ran over your next door neighbor's dog. From trelane at trelane.net Wed Sep 18 22:46:40 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 18 Sep 2013 18:46:40 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> Message-ID: <523A2D50.1030805@trelane.net> On 9/18/2013 6:41 PM, Timothy Metzinger wrote: > Here's a thought. Would it be possible to set up a process where ARIN, as > part of reselling IP addresses, either issues a certificate of transfer that > the new owner can use to prove to the ISPs that he's a new owner and not the > old evil spammer, or ARIN publishes a list of IP assignments that can be > used by ISPs to provisionally remove them from blocked lists? > > I sympathize with the original poster, it's sort of like buying a used car, > only to find out the previous owner was the drunk driver who ran over your > next door neighbor's dog. > > I used to run the AHBL and ARIN used to contact us when they recycled IP space. We always removed when contacted by ARIN. Andrew From bross at pobox.com Wed Sep 18 22:50:47 2013 From: bross at pobox.com (Brandon Ross) Date: Wed, 18 Sep 2013 18:50:47 -0400 (EDT) Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> Message-ID: On Wed, 18 Sep 2013, Timothy Metzinger wrote: > Here's a thought. Would it be possible to set up a process where ARIN, as > part of reselling IP addresses, either issues a certificate of transfer that > the new owner can use to prove to the ISPs that he's a new owner and not the > old evil spammer, or ARIN publishes a list of IP assignments that can be > used by ISPs to provisionally remove them from blocked lists? That sounds like a great idea! We should make it an electronic certificate, though, so that anyone who wants to know can look it up online. And it should show the contact info of the new owner and the date the record was created/updated. It would be a great way to find out WHOIS using a particular address block. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From niels=nanog at bakker.net Wed Sep 18 22:55:27 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 19 Sep 2013 00:55:27 +0200 Subject: common method to count traffic volume on IX In-Reply-To: <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> Message-ID: <20130918225526.GE3108@burnout.tpb.net> * bicknell at ufp.org (Leo Bicknell) [Wed 18 Sep 2013, 19:23 CEST]: >On Sep 17, 2013, at 3:15 PM, Niels Bakker wrote: >>I don't know of any IXP that does this. Industry standard is as >>you and others wrote before: the 5-minute counter difference on >>all customer-facing ports, publishing both input and output bps >>and pps. I guess MRTG is to 'blame' for these values more than >>anything. > >Serious question, at an IXP shouldn't IN = OUT nearly perfectly? Ding ding ding! And that's why honest IXPs graph both, to show that they have no packet loss on their inter-switch links. (Or, much more likely, measurement errors due to wrong config for the grapher) -- Niels. From tammy-lists at wiztech.biz Wed Sep 18 22:55:28 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 18 Sep 2013 16:55:28 -0600 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A2D50.1030805@trelane.net> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> Message-ID: <523A2F60.2030504@wiztech.biz> On 9/18/13 4:46 PM, Andrew D Kirch wrote: > On 9/18/2013 6:41 PM, Timothy Metzinger wrote: >> Here's a thought. Would it be possible to set up a process where >> ARIN, as >> part of reselling IP addresses, either issues a certificate of >> transfer that >> the new owner can use to prove to the ISPs that he's a new owner and >> not the >> old evil spammer, or ARIN publishes a list of IP assignments that can be >> used by ISPs to provisionally remove them from blocked lists? >> >> I sympathize with the original poster, it's sort of like buying a used >> car, >> only to find out the previous owner was the drunk driver who ran over >> your >> next door neighbor's dog. >> >> > I used to run the AHBL and ARIN used to contact us when they recycled IP > space. We always removed when contacted by ARIN. > > Andrew > ARIN hasnt contacted us for this since i've been involved with the ahbl for ~5 years. just a FYI. From nick at foobar.org Wed Sep 18 22:59:35 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 18 Sep 2013 23:59:35 +0100 Subject: common method to count traffic volume on IX In-Reply-To: <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> Message-ID: <523A3057.7040201@foobar.org> On 18/09/2013 18:23, Leo Bicknell wrote: > Serious question, at an IXP shouldn't IN = OUT nearly perfectly? if you host multicast on your unicast peering lan, then this will be affected by the unicast:multicast ratio and the number of recipient ports. Most networks which support multicast will also support multicast pruning, so in reality this counts for very little. Most IXPs rely on unicast flooding to determine forwarding paths, which adds a little to the outbound numbers. So on these IXPs, outbound aggregate is usually a tiny amount larger than inbound aggregate. The larger the network, the smaller this effect. And on networks which precompute forwarding paths, the in and out aggregate figures will be equal +/- counter entropy. Nick From niels=nanog at bakker.net Wed Sep 18 23:03:17 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 19 Sep 2013 01:03:17 +0200 Subject: common method to count traffic volume on IX In-Reply-To: References: Message-ID: <20130918230317.GF3108@burnout.tpb.net> * randy at psg.com (Randy Bush) [Wed 18 Sep 2013, 04:39 CEST]: >somehow, a serious case of testosterone poisoning combined with insane >goal drift has hit a number of the large european exchanges. instead of >the goal being how well they serve their local communities, they have >gone wild with sleazy means of having traffic contests, doing really >sick attempts at techno-colonial expansion into foreign countries and >continents, ... instead of running a public service, they think they >are running competitive commercial enterprises. imiho, the members >should be up in arms. > >if you are jealous of commercial expansion, then send your resume to >equinix. sheesh! Wow Randy, you really misunderstand the situation in Europe and the reasons behind the horizon expansions, and I'm surprised by your advocacy of American hegemony in a market where that really doesn't exist (those of independent not-for-profit internet exchanges). If only you worked for a company that allowed you input into the decision processes of all these member-driven associations! -- Niels. From trelane at trelane.net Wed Sep 18 23:07:34 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 18 Sep 2013 19:07:34 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A2F60.2030504@wiztech.biz> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> Message-ID: <523A3236.1090009@trelane.net> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >> I used to run the AHBL and ARIN used to contact us when they recycled IP >> space. We always removed when contacted by ARIN. >> >> Andrew >> > ARIN hasnt contacted us for this since i've been involved with the ahbl > for ~5 years. > just a FYI. Well, it'd seem we found the problem then. Andrew From sf at lists.esoteric.ca Wed Sep 18 23:10:35 2013 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Wed, 18 Sep 2013 19:10:35 -0400 Subject: common method to count traffic volume on IX In-Reply-To: <20130918225526.GE3108@burnout.tpb.net> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> <20130918225526.GE3108@burnout.tpb.net> Message-ID: <523A32EB.8080807@lists.esoteric.ca> > Ding ding ding! And that's why honest IXPs graph both, to show that > they have no packet loss on their inter-switch links. It depends on what is being measured. At TorIX we'll see deviations between in/out on our aggregate graph. As we combine all peer ports to form the aggregate graph, any large deviations are almost always due to peers who have reached capacity limits on their port (which is not always port speed, btw, always include their transport behind the port). Another common reason is the difference in measurement times across all ports. http://www.torix.ca/stats.php -- Stephen On 18/09/2013 6:55 PM, Niels Bakker wrote: > * bicknell at ufp.org (Leo Bicknell) [Wed 18 Sep 2013, 19:23 CEST]: >> On Sep 17, 2013, at 3:15 PM, Niels Bakker wrote: >>> I don't know of any IXP that does this. Industry standard is as you >>> and others wrote before: the 5-minute counter difference on all >>> customer-facing ports, publishing both input and output bps and pps. >>> I guess MRTG is to 'blame' for these values more than anything. >> >> Serious question, at an IXP shouldn't IN = OUT nearly perfectly? > > Ding ding ding! And that's why honest IXPs graph both, to show that > they have no packet loss on their inter-switch links. > > (Or, much more likely, measurement errors due to wrong config for the > grapher) > > > -- Niels. > From trelane at trelane.net Wed Sep 18 23:30:40 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 18 Sep 2013 19:30:40 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A342B.5070408@wiztech.biz> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> Message-ID: <523A37A0.4030907@trelane.net> On 9/18/2013 7:15 PM, Tammy Firefly wrote: > On 9/18/13 5:07 PM, Andrew D Kirch wrote: >> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >>>> I used to run the AHBL and ARIN used to contact us when they recycled IP >>>> space. We always removed when contacted by ARIN. >>>> >>>> Andrew >>>> >>> ARIN hasnt contacted us for this since i've been involved with the ahbl >>> for ~5 years. >>> just a FYI. >> Well, it'd seem we found the problem then. >> >> Andrew >> > Ive know ARIN is a problem for a lotta years andrew :P When we > contacted them and asked them to do it again we got told its against > policies blablablabla. > (replying to list with Tammy's permission) This is pathetic. ARIN is supposed to be working as a steward of this IP space. When you have policies that make it more difficult to use the IP space this isn't even remotely close to stewardship. It's pathetic, with the policy making a quick turn around of releasing old IP space when you get an allocation, that ARIN is leaving innocent third parties who have paid ARIN large sums of money for this space. ARIN, frankly you can suck it. It's time to grow up and behave how you were intended to. Andrew From nick at foobar.org Wed Sep 18 23:38:04 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 19 Sep 2013 00:38:04 +0100 Subject: common method to count traffic volume on IX In-Reply-To: <20130918225526.GE3108@burnout.tpb.net> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> <20130918225526.GE3108@burnout.tpb.net> Message-ID: <523A395C.8080408@foobar.org> On 18/09/2013 23:55, Niels Bakker wrote: > Ding ding ding! And that's why honest IXPs graph both, to show that they > have no packet loss on their inter-switch links. If in > out, it's not necessarily inter-switch packet loss. The difference between the two will also include packet loss for same-switch egress traffic on customer ports. Nick From dmiller at tiggee.com Thu Sep 19 00:10:44 2013 From: dmiller at tiggee.com (David Miller) Date: Wed, 18 Sep 2013 20:10:44 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A37A0.4030907@trelane.net> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> <523A37A0.4030907@trelane.net> Message-ID: <523A4104.4000403@tiggee.com> On 9/18/2013 7:30 PM, Andrew D Kirch wrote: > On 9/18/2013 7:15 PM, Tammy Firefly wrote: >> On 9/18/13 5:07 PM, Andrew D Kirch wrote: >>> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >>>>> I used to run the AHBL and ARIN used to contact us when they >>>>> recycled IP >>>>> space. We always removed when contacted by ARIN. >>>>> >>>>> Andrew >>>>> >>>> ARIN hasnt contacted us for this since i've been involved with the ahbl >>>> for ~5 years. >>>> just a FYI. >>> Well, it'd seem we found the problem then. >>> >>> Andrew >>> >> Ive know ARIN is a problem for a lotta years andrew :P When we >> contacted them and asked them to do it again we got told its against >> policies blablablabla. >> > (replying to list with Tammy's permission) > This is pathetic. ARIN is supposed to be working as a steward of this > IP space. When you have policies that make it more difficult to use the > IP space this isn't even remotely close to stewardship. It's pathetic, > with the policy making a quick turn around of releasing old IP space > when you get an allocation, that ARIN is leaving innocent third parties > who have paid ARIN large sums of money for this space. > ARIN, frankly you can suck it. It's time to grow up and behave how you > were intended to. > > Andrew > If only there was a way for anyone to get a daily report of number resource allocations... https://lmddgtfy.net/?q=daily%20internet%20number%20resource%20allocation%20report First link. -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From tammy-lists at wiztech.biz Thu Sep 19 00:14:12 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 18 Sep 2013 18:14:12 -0600 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A4104.4000403@tiggee.com> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> <523A37A0.4030907@trelane.net> <523A4104.4000403@tiggee.com> Message-ID: <523A41D4.1090608@wiztech.biz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/18/13 6:10 PM, David Miller wrote: > > > On 9/18/2013 7:30 PM, Andrew D Kirch wrote: >> On 9/18/2013 7:15 PM, Tammy Firefly wrote: >>> On 9/18/13 5:07 PM, Andrew D Kirch wrote: >>>> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >>>>>> I used to run the AHBL and ARIN used to contact us when >>>>>> they recycled IP space. We always removed when contacted >>>>>> by ARIN. >>>>>> >>>>>> Andrew >>>>>> >>>>> ARIN hasnt contacted us for this since i've been involved >>>>> with the ahbl for ~5 years. just a FYI. >>>> Well, it'd seem we found the problem then. >>>> >>>> Andrew >>>> >>> Ive know ARIN is a problem for a lotta years andrew :P When >>> we contacted them and asked them to do it again we got told its >>> against policies blablablabla. >>> >> (replying to list with Tammy's permission) This is pathetic. >> ARIN is supposed to be working as a steward of this IP space. >> When you have policies that make it more difficult to use the IP >> space this isn't even remotely close to stewardship. It's >> pathetic, with the policy making a quick turn around of releasing >> old IP space when you get an allocation, that ARIN is leaving >> innocent third parties who have paid ARIN large sums of money for >> this space. ARIN, frankly you can suck it. It's time to grow up >> and behave how you were intended to. >> >> Andrew >> > > If only there was a way for anyone to get a daily report of number > resource allocations... > > https://lmddgtfy.net/?q=daily%20internet%20number%20resource%20allocation%20report > > First link. > > -DMM > Yeah were not gonna wade thru PDF hell to do that. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSOkHUAAoJEHJ/lMQe1SM0u7UH/3WtRf+Cmv8+8e5qxleoQkMa EBjQlbNxvcOBTPn6mqqiRMBY43hVPzOgmf7UjbhbtQBmXVD+w/f/2IWtuOSL1S3Z OYroMCQ+3zot4VvQprH0yeIF2byPYbTXKAxlRLjcZaauv+vIty+vuIrXP276ezip 6iGJxzgSL80hfPNtpaqb2MWkxxl3le8BDjAZoBt8WbU8mR1wHrYtDqgY0sSEzC6c vPzpxMuSk/VynKXIn0Tz8+1DWpHdPTbxdurBfXFTMuAcpt5M215odffLUauv88TS TuRcENZhpKnGZnyeyf9xMvZ70sibfAIulIAsm3BTnoqncuz5/112MCpnPUMFhek= =Plpi -----END PGP SIGNATURE----- From tammy-lists at wiztech.biz Thu Sep 19 00:16:42 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 18 Sep 2013 18:16:42 -0600 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A4104.4000403@tiggee.com> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> <523A37A0.4030907@trelane.net> <523A4104.4000403@tiggee.com> Message-ID: <523A426A.5080008@wiztech.biz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/18/13 6:10 PM, David Miller wrote: > > > On 9/18/2013 7:30 PM, Andrew D Kirch wrote: >> On 9/18/2013 7:15 PM, Tammy Firefly wrote: >>> On 9/18/13 5:07 PM, Andrew D Kirch wrote: >>>> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >>>>>> I used to run the AHBL and ARIN used to contact us when >>>>>> they recycled IP space. We always removed when contacted >>>>>> by ARIN. >>>>>> >>>>>> Andrew >>>>>> >>>>> ARIN hasnt contacted us for this since i've been involved >>>>> with the ahbl for ~5 years. just a FYI. >>>> Well, it'd seem we found the problem then. >>>> >>>> Andrew >>>> >>> Ive know ARIN is a problem for a lotta years andrew :P When >>> we contacted them and asked them to do it again we got told its >>> against policies blablablabla. >>> >> (replying to list with Tammy's permission) This is pathetic. >> ARIN is supposed to be working as a steward of this IP space. >> When you have policies that make it more difficult to use the IP >> space this isn't even remotely close to stewardship. It's >> pathetic, with the policy making a quick turn around of releasing >> old IP space when you get an allocation, that ARIN is leaving >> innocent third parties who have paid ARIN large sums of money for >> this space. ARIN, frankly you can suck it. It's time to grow up >> and behave how you were intended to. >> >> Andrew >> > > If only there was a way for anyone to get a daily report of number > resource allocations... > > https://lmddgtfy.net/?q=daily%20internet%20number%20resource%20allocation%20report > > First link. > > -DMM > Those also are statistics not actual IP block numbers being deallocated/allocated. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSOkJqAAoJEHJ/lMQe1SM0PlIH/0DXHqPkIaVIh0poaj5w0oDM Y/PrbpMu16D+ga2HR0KQtrWglNacOg+VxDikTJMgYYhDmscVd8Y+inCyQpAW4ok6 2MaZeKMf5PEkkBkWh2M7703ljQ6ajDae+xTKJgXM0A4CaEkKlFgjxJ9t3+Wad+BC c5Xso50sVbeT0PG0Xd/6BHchg6kZUhm0IwPHBaD2RwIbydYiDpDKcu2zehBTNhO+ 0wjxXmysAC5opFdyR9sjpDvlXWyPDNqhG3pikEMwFY2HGPZLoq1h1iUdUA/QW5Hi J1eVi96wuNdywr6Kp8F3w7ADSldaAwUqr9mvYxI4EwbzMzjwmj28+68xYTXWxrE= =cuK7 -----END PGP SIGNATURE----- From me at staticsafe.ca Thu Sep 19 00:25:00 2013 From: me at staticsafe.ca (staticsafe) Date: Wed, 18 Sep 2013 20:25:00 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A426A.5080008@wiztech.biz> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> <523A37A0.4030907@trelane.net> <523A4104.4000403@tiggee.com> <523A426A.5080008@wiztech.biz> Message-ID: <523A445C.7000900@staticsafe.ca> On 9/18/2013 8:16 PM, Tammy Firefly wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Those also are statistics not actual IP block numbers being > deallocated/allocated. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.20 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJSOkJqAAoJEHJ/lMQe1SM0PlIH/0DXHqPkIaVIh0poaj5w0oDM > Y/PrbpMu16D+ga2HR0KQtrWglNacOg+VxDikTJMgYYhDmscVd8Y+inCyQpAW4ok6 > 2MaZeKMf5PEkkBkWh2M7703ljQ6ajDae+xTKJgXM0A4CaEkKlFgjxJ9t3+Wad+BC > c5Xso50sVbeT0PG0Xd/6BHchg6kZUhm0IwPHBaD2RwIbydYiDpDKcu2zehBTNhO+ > 0wjxXmysAC5opFdyR9sjpDvlXWyPDNqhG3pikEMwFY2HGPZLoq1h1iUdUA/QW5Hi > J1eVi96wuNdywr6Kp8F3w7ADSldaAwUqr9mvYxI4EwbzMzjwmj28+68xYTXWxrE= > =cuK7 > -----END PGP SIGNATURE----- > http://lists.arin.net/mailman/listinfo/arin-issued -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. It is not logical. Please don't CC me! I'm subscribed to whatever list I just posted on. From randy at psg.com Thu Sep 19 00:32:05 2013 From: randy at psg.com (Randy Bush) Date: Wed, 18 Sep 2013 14:32:05 -1000 Subject: common method to count traffic volume on IX In-Reply-To: <20130918230317.GF3108@burnout.tpb.net> References: <20130918230317.GF3108@burnout.tpb.net> Message-ID: >> somehow, a serious case of testosterone poisoning combined with insane >> goal drift has hit a number of the large european exchanges. instead of >> the goal being how well they serve their local communities, they have >> gone wild with sleazy means of having traffic contests, doing really >> sick attempts at techno-colonial expansion into foreign countries and >> continents, ... instead of running a public service, they think they >> are running competitive commercial enterprises. imiho, the members >> should be up in arms. >> >> if you are jealous of commercial expansion, then send your resume to >> equinix. sheesh! > > Wow Randy, you really misunderstand the situation in Europe and the > reasons behind the horizon expansions, and I'm surprised by your > advocacy of American hegemony in a market where that really doesn't > exist (those of independent not-for-profit internet exchanges). yes, the american hegemony in angola, kenya, hong kong, ... you gotta love the amsix hkg charlie foxtrot. trying to open up the us market by going to the states to enter it is a fun adventure. but as it's a rather crowded market, it's not for the faint of heart. but it is a market that would benefit from a bit more competition. and puhleeze get more competition into tokyo, jeez! but i think it is crazy for a local european exchange to take on the white man's burden of exporting freedom to virginia (or wherever), especially without bombing it first. randy From kamtha at ak-labs.net Thu Sep 19 00:38:08 2013 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Wed, 18 Sep 2013 20:38:08 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: <20130919003808.GA98805@ak-labs.net> Quite unfortunate.. These days, when allocated 'new' IPV4 space you really have to do a little homework to make sure it 'clean'. I would suggest that you run your CIDR block through http://multirbl.valli.org/lookup/. IF it's mostly clean and not on hardcore lists such as SpamHaus ROKSO, then there's hope. Whatever lists your netblock is on you will just have to contact thier abuse dept. and explain your predicament and stay on top of it. Sounds like you are well on your way to doing that.. Good luck. Carlos. On Wed, Sep 18, 2013 at 04:07:25PM +0000, NANOG wrote: > We recently purchased new IP addresses from ARIN, with plans on using one of them for our external and internal email delivery. We set up a reverse lookup and a SPF record for the newly purchased IP to prevent being classified as spam. We tested the functionality of the PTR and SPF record successfully using varies internet tools like dnsstuff.com, mxtoolbox.com, and kitterman.com. Unfortunately, when we send emails to any AT&T or Network Solutions hosted email we are being block as a spam abuser. I checked varies spam database tools and our IP addresses are not listed, but we are still being blocked by both AT&T and Network Solution. The block message is 521 DNSRBL: Blocked for abuse. In an attempt to be proactive, I contacted Network Solution and was told that each recipient would have to request we be whitelisted, and AT&T directed me to an online form that I submitted to be removed from the blacklist. Unfortunately, we are still not able to send emails to either AT&T or Network Solutions hosted emails. Our mail server IP address is 74.112.99.25, which resolves to mail.abcsupply.com. Does anyone have any suggestions on where to turn next? Is it possible they are blocking us based on old information from the previous IP address block owner? Any help tracking this down would be appreciated. > > > Derrick Wash > Microsoft Systems Administrator > ABC Supply Company Inc > Office: (608)368-2214 > Fax: (608)363-0214 From dmiller at tiggee.com Thu Sep 19 00:40:17 2013 From: dmiller at tiggee.com (David Miller) Date: Wed, 18 Sep 2013 20:40:17 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A426A.5080008@wiztech.biz> References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <523A2D50.1030805@trelane.net> <523A2F60.2030504@wiztech.biz> <523A3236.1090009@trelane.net> <523A342B.5070408@wiztech.biz> <523A37A0.4030907@trelane.net> <523A4104.4000403@tiggee.com> <523A426A.5080008@wiztech.biz> Message-ID: <523A47F1.2070504@tiggee.com> On 9/18/2013 8:16 PM, Tammy Firefly wrote: > On 9/18/13 6:10 PM, David Miller wrote: > > >> On 9/18/2013 7:30 PM, Andrew D Kirch wrote: >>> On 9/18/2013 7:15 PM, Tammy Firefly wrote: >>>> On 9/18/13 5:07 PM, Andrew D Kirch wrote: >>>>> On 9/18/2013 6:55 PM, Tammy Firefly wrote: >>>>>>> I used to run the AHBL and ARIN used to contact us when >>>>>>> they recycled IP space. We always removed when contacted >>>>>>> by ARIN. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>> ARIN hasnt contacted us for this since i've been involved >>>>>> with the ahbl for ~5 years. just a FYI. >>>>> Well, it'd seem we found the problem then. >>>>> >>>>> Andrew >>>>> >>>> Ive know ARIN is a problem for a lotta years andrew :P When >>>> we contacted them and asked them to do it again we got told its >>>> against policies blablablabla. >>>> >>> (replying to list with Tammy's permission) This is pathetic. >>> ARIN is supposed to be working as a steward of this IP space. >>> When you have policies that make it more difficult to use the IP >>> space this isn't even remotely close to stewardship. It's >>> pathetic, with the policy making a quick turn around of releasing >>> old IP space when you get an allocation, that ARIN is leaving >>> innocent third parties who have paid ARIN large sums of money for >>> this space. ARIN, frankly you can suck it. It's time to grow up >>> and behave how you were intended to. >>> >>> Andrew >>> > >> If only there was a way for anyone to get a daily report of number >> resource allocations... > >> https://lmddgtfy.net/?q=daily%20internet%20number%20resource%20allocation%20report > >> First link. > >> -DMM > > > Those also are statistics not actual IP block numbers being > deallocated/allocated. > > The Status Reports (PDFs) down the page are statistics, updated quarterly. At the top of the page is the delegated-extended daily report. "The file delegated-extended contains a daily updated report of the distribution of Internet number resources. The resources reported are: IPv4 address ranges (IPv4) IPv6 address ranges (IPv6) Autonomous System Numbers (ASNs)" That file is text. The lines for IPv4 look like: apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A9173591|e-stats apnic|CN|ipv4|1.0.1.0|256|20110414|assigned|A92E1062|e-stats apnic|CN|ipv4|1.0.2.0|512|20110414|assigned|A92E1062|e-stats The Readme file explains the fields: http://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt 4th field is start IP 5th field is number of IPs in block 6th field is date of allocation/assignment I would think that file might be parsed, compared to RBL listings, and if listing date (or last bad behavior date) < allocation/assignment date - then remove listing. -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From johnl at iecc.com Thu Sep 19 01:02:10 2013 From: johnl at iecc.com (John Levine) Date: 19 Sep 2013 01:02:10 -0000 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <523A37A0.4030907@trelane.net> Message-ID: <20130919010210.11321.qmail@joyce.lan> >This is pathetic. ARIN is supposed to be working as a steward of this >IP space. When you have policies that make it more difficult to use the >IP space this isn't even remotely close to stewardship. It's pathetic, Unfortunately, a surprising number of "new" IP space owners turn out to be the sleazy old IP space owners under a differnt fake name. R's, John From randy at psg.com Thu Sep 19 01:16:03 2013 From: randy at psg.com (Randy Bush) Date: Wed, 18 Sep 2013 15:16:03 -1000 Subject: common method to count traffic volume on IX In-Reply-To: References: <20130918230317.GF3108@burnout.tpb.net> Message-ID: > you gotta love the amsix hkg charlie foxtrot. and how is that working out financially for the amsix members, the folk in the amsterdam area the amsix purportedly serves, niels? randy From trelane at trelane.net Thu Sep 19 02:31:31 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 18 Sep 2013 22:31:31 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <20130919010210.11321.qmail@joyce.lan> References: <20130919010210.11321.qmail@joyce.lan> Message-ID: <523A6203.8090504@trelane.net> On 9/18/2013 9:02 PM, John Levine wrote: >> This is pathetic. ARIN is supposed to be working as a steward of this >> IP space. When you have policies that make it more difficult to use the >> IP space this isn't even remotely close to stewardship. It's pathetic, > Unfortunately, a surprising number of "new" IP space owners turn out > to be the sleazy old IP space owners under a differnt fake name. > > R's, > John or put another way, spammers lie. Andrew From marka at isc.org Thu Sep 19 02:46:04 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 19 Sep 2013 12:46:04 +1000 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: Your message of "Wed, 18 Sep 2013 22:31:31 -0400." <523A6203.8090504@trelane.net> References: <20130919010210.11321.qmail@joyce.lan> <523A6203.8090504@trelane.net> Message-ID: <20130919024604.69F776FB858@rock.dv.isc.org> In message <523A6203.8090504 at trelane.net>, Andrew D Kirch writes: > On 9/18/2013 9:02 PM, John Levine wrote: > >> This is pathetic. ARIN is supposed to be working as a steward of this > >> IP space. When you have policies that make it more difficult to use the > >> IP space this isn't even remotely close to stewardship. It's pathetic, > > Unfortunately, a surprising number of "new" IP space owners turn out > > to be the sleazy old IP space owners under a differnt fake name. > > > > R's, > > John > or put another way, spammers lie. > > Andrew Which is irrelevent to removing a address block on the basis of a RIR recording that the block has been reallocated. A reallocation already goes through a quarantine period though that may get shorter as time goes on. A transfer on the other hand doesn't. There may be some use in recording whether a address block is transfered or allocated. Note I'm not sure if the allocation date gets updated on a transfer or not. There may be some use in recording when a address block is quarantined. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sh.vahabzadeh at gmail.com Thu Sep 19 05:05:18 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Thu, 19 Sep 2013 08:35:18 +0330 Subject: anybody from Amsterdam Internet Exchange (ams-ix) to help? Message-ID: Hello Everybody, Is there anybody from Amsterdam IX here? I have some questions about concept of IXP. If anybody else have enough information about IXP's please give me message off the list. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From henk.steenman at ams-ix.net Thu Sep 19 05:33:12 2013 From: henk.steenman at ams-ix.net (Henk Steenman) Date: Thu, 19 Sep 2013 07:33:12 +0200 Subject: anybody from Amsterdam Internet Exchange (ams-ix) to help? In-Reply-To: References: Message-ID: Dear Shahab, Please conact me directly kind regards - Henk Steenman, AMS-IX On 19 sep. 2013, at 07:05, Shahab Vahabzadeh wrote: > Hello Everybody, > Is there anybody from Amsterdam IX here? > I have some questions about concept of IXP. > If anybody else have enough information about IXP's please give me message > off the list. > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From neil at domino.org Thu Sep 19 11:09:51 2013 From: neil at domino.org (Neil J. McRae) Date: Thu, 19 Sep 2013 11:09:51 +0000 Subject: common method to count traffic volume on IX In-Reply-To: Message-ID: Randy, On 18/09/2013 03:39, "Randy Bush" wrote: >somehow, a serious case of testosterone poisoning combined with insane >goal drift has hit a number of the large european exchanges. instead of >the goal being how well they serve their local communities, they have >gone wild with sleazy means of having traffic contests, doing really >sick attempts at techno-colonial expansion into foreign countries and >continents, ... instead of running a public service, they think they >are running competitive commercial enterprises. imiho, the members >should be up in arms. I find this rant hilarious given your position during the attempted commercial buy out of the London Internet Exchange! Others might class it as rubbish! The European exchanges are responding to a demand that is being created by US operators (many of which are members), there is a gap that is perceived that the model used in Europe (quite successfully I would add) may fill. By all means, if there are other companies that can fill this demand they should get their plans rolling. As for local communities - the Internet itself is a local community which we all do our best to serve. >if you are jealous of commercial expansion, then send your resume to >equinix. Sheesh! I've sent them mine but they said my approach to commercial expansion was too aggressive! Oh dear! ;) Regaards, Neil. (oh and yes I am a non-exec of the LINX but I'm speaking personally (but you knew that already right?)) From niels=nanog at bakker.net Thu Sep 19 11:32:44 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 19 Sep 2013 13:32:44 +0200 Subject: common method to count traffic volume on IX In-Reply-To: References: <20130918230317.GF3108@burnout.tpb.net> Message-ID: <20130919113244.GG3108@burnout.tpb.net> * randy at psg.com (Randy Bush) [Thu 19 Sep 2013, 03:16 CEST]: >> you gotta love the amsix hkg charlie foxtrot. >and how is that working out financially for the amsix members, >the folk in the amsterdam area the amsix purportedly serves, >niels? All relevant paperwork including business plans was made available to the full membership and you can download it at my.ams-ix.net. I know you're a busy man so the tl;dr is that by encouraging local peering more networks will start to peer, and by partnering with one or more local carriers those new networks as well as established players in those markets can connect to the home exchange point too, increasing value for all connected parties. Also, what Neil J. McRae said in his email in this thread. Regards, -- Niels. From niels=nanog at bakker.net Thu Sep 19 11:36:48 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 19 Sep 2013 13:36:48 +0200 Subject: common method to count traffic volume on IX In-Reply-To: <523A395C.8080408@foobar.org> References: <523836B0.80403@foobar.org> <855E5BCC-60EC-43DF-9BBD-FF1C5F0727D3@ianai.net> <52386F91.5020801@foobar.org> <20130917185152.GA66624@ussenterprise.ufp.org> <20130917201523.GD3108@burnout.tpb.net> <007332D0-B603-4319-8B22-A22D979F7797@ufp.org> <20130918225526.GE3108@burnout.tpb.net> <523A395C.8080408@foobar.org> Message-ID: <20130919113648.GH3108@burnout.tpb.net> * nick at foobar.org (Nick Hilliard) [Thu 19 Sep 2013, 01:38 CEST]: >On 18/09/2013 23:55, Niels Bakker wrote: >>Ding ding ding! And that's why honest IXPs graph both, to show >>that they have no packet loss on their inter-switch links. >If in > out, it's not necessarily inter-switch packet loss. The >difference between the two will also include packet loss for >same-switch egress traffic on customer ports. That's absolutely true, I was a bit too glib in the quoted mail. -- Niels. From will at harg.net Thu Sep 19 12:00:34 2013 From: will at harg.net (Will Hargrave) Date: Thu, 19 Sep 2013 13:00:34 +0100 Subject: common method to count traffic volume on IX In-Reply-To: <20130919113244.GG3108@burnout.tpb.net> References: <20130918230317.GF3108@burnout.tpb.net> <20130919113244.GG3108@burnout.tpb.net> Message-ID: <12044A03-DA6F-41DE-AD9C-5C81F5E2F1CE@harg.net> On 19 Sep 2013, at 12:32, Niels Bakker wrote: > I know you're a busy man so the tl;dr is that by encouraging local peering more networks will start to peer, and by partnering with one or more local carriers those new networks as well as established players in those markets can connect to the home exchange point too, increasing value for all connected parties. But isn't this all just neo-colonialism? Establish a market in the colony, but ensure through restrictive trade practices that all trade routes lead back via the mother country. Or can I buy myself connectivity to AMS-IX Amsterdam when i'm present at the LINX Harare exchange? Will From sthaug at nethelp.no Thu Sep 19 12:51:27 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 19 Sep 2013 14:51:27 +0200 (CEST) Subject: common method to count traffic volume on IX In-Reply-To: <12044A03-DA6F-41DE-AD9C-5C81F5E2F1CE@harg.net> References: <20130919113244.GG3108@burnout.tpb.net> <12044A03-DA6F-41DE-AD9C-5C81F5E2F1CE@harg.net> Message-ID: <20130919.145127.74686956.sthaug@nethelp.no> > But isn't this all just neo-colonialism? Establish a market in the colony, but ensure through restrictive trade practices that all trade routes lead back via the mother country. > > Or can I buy myself connectivity to AMS-IX Amsterdam when i'm present at the LINX Harare exchange? There are multiple providers offering remote access to LINX, AMS-IX and probably several other European IXes. We're using one of these ourselves. I have no specific info on LINX Harare :-) Steinar Haug, AS 2116 From rsk at gsp.org Thu Sep 19 15:21:10 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 19 Sep 2013 11:21:10 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: References: <3CD2C55A8CD6E74EB451AC934C8CCD319EA4C742@MBLocal02.abcsupply.com> Message-ID: <20130919152109.GA27595@gsp.org> On Wed, Sep 18, 2013 at 11:59:13AM -0500, John LeCoque wrote: > I would say the first step is to find an immediate workaround for your end > users - maybe bring up a VM on AWS or some other cloud provider to use as > an SMTP relay while you work out the blacklist issue. Not a good idea. It's a best practice to refuse *all* email traffic out of Amazon's cloud because (a) it's a prodigous source of spam and other forms of abuse and (b) Amazon absolutely refuses to lift a finger to address the problem. (Just try submitting an abuse report and notice all the hoop-jumping they've put in the way in a quite obvious, deliberate attempt to make it as difficult as possible.) ---rsk From hannigan at gmail.com Thu Sep 19 15:43:43 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 19 Sep 2013 11:43:43 -0400 Subject: common method to count traffic volume on IX In-Reply-To: References: Message-ID: One other important point to note. Anyone can turn up an exchange in N/A and be supported by the same. So far, only the current cadre of IXP's have stepped up to help. US entities are instead busy acquiring meet- me rooms to further box us all in even more. http://www.datacenterknowledge.com/archives/2013/09/17/cologix-acquires-jax-meet-me-room/ Best, -M< On Thursday, September 19, 2013, Neil J. McRae wrote: > Randy, > > On 18/09/2013 03:39, "Randy Bush" wrote: > > >somehow, a serious case of testosterone poisoning combined with insane > >goal drift has hit a number of the large european exchanges. instead of > >the goal being how well they serve their local communities, they have > >gone wild with sleazy means of having traffic contests, doing really > >sick attempts at techno-colonial expansion into foreign countries and > >continents, ... instead of running a public service, they think they > >are running competitive commercial enterprises. imiho, the members > >should be up in arms. > > I find this rant hilarious given your position during the attempted > commercial buy out of the London Internet Exchange! Others might class it > as rubbish! > > The European exchanges are responding to a demand that is being created by > US operators (many of which are members), there is a gap that is perceived > that the model used in Europe (quite successfully I would add) may fill. > By all means, if there are other companies that can fill this demand they > should get their plans rolling. > > As for local communities - the Internet itself is a local community which > we all do our best to serve. > > >if you are jealous of commercial expansion, then send your resume to > >equinix. Sheesh! > > I've sent them mine but they said my approach to commercial expansion was > too aggressive! Oh dear! ;) > > Regaards, > Neil. > (oh and yes I am a non-exec of the LINX but I'm speaking personally (but > you knew that already right?)) > > > > From betty at newnog.org Thu Sep 19 16:04:32 2013 From: betty at newnog.org (Betty Burke ) Date: Thu, 19 Sep 2013 12:04:32 -0400 Subject: [NANOG-announce] NANOG 59 Reminders Message-ID: Colleagues: I write to share a few NANOG meeting reminders: - Routing Fundamentals, NANOGs first Education class, will take place Sunday October 6, 2013. The Class registration fee includes a one-day pass to attend NANOG 59. Be sure to pass along the information to those who may not be on the NANOG list and could benefit from our NANOG experience. - NANOG 59 , Oct. 7-9, 2013, is full of great content, check out the agendatopics list posted by the NANOG Program Committee. Early next week, the PC will be posting the preliminary agenda with times and speakers. - If you have not yet secured your room, do not delay. The Sheraton Wild Horse will be a fabulous place for our meeting. A free shuttle service will be available on Monday and Tuesday evenings. Thanks to our sponsors, we also have a full slate of evening socials. - Do not delay, register today, and take advantage of registration fee savings. The current registration rate will expire on Friday, September 20, 2013. You can register, manage your registration, and retrieve receipts from the NANOG portal (ARO). You can easily create a new account, or recover your password . - Be sure to Join NANOG today and receive a $25 discount on standard registration fees for any NANOG - conference as well as have a voice in guiding future NANOG activities. - NANOGs Fall meeting also includes the important election process. If you are onsite or remote, please participate through service and voting in the 2013 NANOG Elections process. Of note, the nominations for Board Candidatesalso expires on Friday, September 20, 2013. - Lastly, a few NANOG 59 Sponsorship opportunitiesremain. If interested send a note to marketing at nanog.org, or visit our online sponsorship form. A member of the Development Committee will be sure to follow-up. We look forward to seeing many of you at NANOG 59! Should you have any questions, please send them along to nanog-support at nanog.org. All best. Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From Yi.Chu at sprint.com Thu Sep 19 16:47:23 2013 From: Yi.Chu at sprint.com (Chu, Yi [NTK]) Date: Thu, 19 Sep 2013 16:47:23 +0000 Subject: Yahoo contact Message-ID: I have an issue with Yahoo geolocator for an IP block. Anybody from yahoo, please contact me offline. Yi Chu IP Engineering Sprint (703) 592-4850 ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From dwessels at verisign.com Thu Sep 19 17:30:36 2013 From: dwessels at verisign.com (Wessels, Duane) Date: Thu, 19 Sep 2013 17:30:36 +0000 Subject: .gov DNSSEC operational message Message-ID: <8D363212-5A6C-4F1E-8916-A37BCF32B58D@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note that as of today, the .gov zone's transition from algorithm 7 to 8 is now complete. Duane W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSOzJ+AAoJEGyZpGmowJiNrssIAKIO9Sd/+ALFEwMDC8xMx4XH xd98ii4ZH5FdnXnWURv0oaPqz5D9lMziXiPzIYyJ9AgMSUeqBxWRCYk+1SluGUM3 U2XHGCJy53LuF4cXa6UmfWSPu7YIWnMDKNy2GtTKQB5s+SsUWjz3CdFEyh5X3idq eR6Bihww0nuJs5HZvB9l1IDH3CuDcGhpgWYsJ2x9FjmNyTpKylJ+4UNnIfz3chGk st6gK2PBZKTApCoLxgO0yHJ2iJZLXARrDCudy7dqtUdyaGqEpBWwdoexxVpHv2gj ZGilU3+LqlTt0SPzCLgNkdIHuf/0c/dVnTjjkgIa/YQRpqAY39ZiHftKISpImt0= =IWe3 -----END PGP SIGNATURE----- From nick at flhsi.com Thu Sep 19 17:23:11 2013 From: nick at flhsi.com (Nick Olsen) Date: Thu, 19 Sep 2013 13:23:11 -0400 Subject: iOS 7 update traffic Message-ID: <7744bfd2$201d27d6$520203ce$@flhsi.com> We also saw a huge spike in traffic. Still pretty high today as well. We saw a ~60% above average hit yesterday, And we're at ~20-30% above average today as well. Being an android user, It didn't dawn on me until some of the IOS users in the office started jumping up and down about IOS7 Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Justin M. Streiner" Sent: Wednesday, September 18, 2013 6:19 PM To: "NANOG" Subject: Re: iOS 7 update traffic On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > We also noticed an interesting spike (+ ~40%), mostly in akamai. > The same happened on previous iOS too. I see it here, too. At its peak, our traffic levels were roughly double what we would see on a normal weekday. jms > Zachary McGibbon wrote on 18/9/2013 20:38: >> So iOS 7 just came out, here's the spike in our graphs going to our ISP >> here at McGill, anyone else noticing a big spike? >> >> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >> TenGigabitEthernet0/7] >> >> Zachary McGibbon >> > > > From fergdawgster at mykolab.com Thu Sep 19 17:58:24 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 19 Sep 2013 10:58:24 -0700 Subject: iOS 7 update traffic In-Reply-To: <523B3B15.5090603@people.ops-trust.net> References: <523B3B15.5090603@people.ops-trust.net> Message-ID: <523B3B40.5070309@mykolab.com> Can someone please explain to a non-Apple person what the hell happened that started generating so much traffic? Perhaps I missed it in this thread, but I would be curious to know what iOS 7 implemented that caused this... Thanks in adavnce, - ferg On 9/19/2013 10:23 AM, Nick Olsen wrote: > We also saw a huge spike in traffic. Still pretty high today as well. > We saw a ~60% above average hit yesterday, And we're at ~20-30% above > average today as well. > Being an android user, It didn't dawn on me until some of the IOS users in > the office started jumping up and down about IOS7 > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Justin M. Streiner" > Sent: Wednesday, September 18, 2013 6:19 PM > To: "NANOG" > Subject: Re: iOS 7 update traffic > > On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > >> We also noticed an interesting spike (+ ~40%), mostly in akamai. >> The same happened on previous iOS too. > > I see it here, too. At its peak, our traffic levels were roughly double > what we would see on a normal weekday. > > jms > >> Zachary McGibbon wrote on 18/9/2013 20:38: >>> So iOS 7 just came out, here's the spike in our graphs going to our ISP >>> here at McGill, anyone else noticing a big spike? >>> >>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>> TenGigabitEthernet0/7] >>> >>> Zachary McGibbon >>> >> >> >> > > > > -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From swmike at swm.pp.se Thu Sep 19 18:05:59 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 19 Sep 2013 20:05:59 +0200 (CEST) Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: On Thu, 19 Sep 2013, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 megabytes for ipad. There are quite a few devices out there times these amounts to download... -- Mikael Abrahamsson email: swmike at swm.pp.se From darrenoc at outlook.com Thu Sep 19 18:06:25 2013 From: darrenoc at outlook.com (Darren O'Connor) Date: Thu, 19 Sep 2013 19:06:25 +0100 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net>, <523B3B40.5070309@mykolab.com> Message-ID: It was released Thanks Darren http://www.mellowd.co.uk/ccie > Date: Thu, 19 Sep 2013 10:58:24 -0700 > From: fergdawgster at mykolab.com > To: nanog at nanog.org > Subject: Re: iOS 7 update traffic > > > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... > > Thanks in adavnce, > > - ferg > > On 9/19/2013 10:23 AM, Nick Olsen wrote: > > > We also saw a huge spike in traffic. Still pretty high today as well. > > We saw a ~60% above average hit yesterday, And we're at ~20-30% above > > average today as well. > > Being an android user, It didn't dawn on me until some of the IOS users in > > the office started jumping up and down about IOS7 > > Nick Olsen > > Network Operations (855) FLSPEED x106 > > > > ---------------------------------------- > > From: "Justin M. Streiner" > > Sent: Wednesday, September 18, 2013 6:19 PM > > To: "NANOG" > > Subject: Re: iOS 7 update traffic > > > > On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > > > >> We also noticed an interesting spike (+ ~40%), mostly in akamai. > >> The same happened on previous iOS too. > > > > I see it here, too. At its peak, our traffic levels were roughly double > > what we would see on a normal weekday. > > > > jms > > > >> Zachary McGibbon wrote on 18/9/2013 20:38: > >>> So iOS 7 just came out, here's the spike in our graphs going to our ISP > >>> here at McGill, anyone else noticing a big spike? > >>> > >>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - > >>> TenGigabitEthernet0/7] > >>> > >>> Zachary McGibbon > >>> > >> > >> > >> > > > > > > > > > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com > > From jabley at hopcount.ca Thu Sep 19 18:06:59 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 19 Sep 2013 14:06:59 -0400 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <6D2F2773-9AE8-43D8-912E-5B1398D426E4@hopcount.ca> On 2013-09-19, at 13:58, Paul Ferguson wrote: > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... I think the inference is that iOS 7 caused the extra traffic by being available for download. There are just a lot of Apple devices, and they tend to get upgraded more promptly than other platforms (e.g. on release day). We saw a similar phenomenon tracking downloads of the root zone DNSSEC trust anchor from data.iana.org -- we now see three million downloads per month, and pretty much all of those are iOS devices (or other devices impersonating them, which seems unlikely). Joe From tshaw at oitc.com Thu Sep 19 18:07:13 2013 From: tshaw at oitc.com (TR Shaw) Date: Thu, 19 Sep 2013 14:07:13 -0400 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: Major update & provides many of 5S functionality to the 5, 4S, & 4 On Sep 19, 2013, at 1:58 PM, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... > > Thanks in adavnce, > > - ferg > > On 9/19/2013 10:23 AM, Nick Olsen wrote: > >> We also saw a huge spike in traffic. Still pretty high today as well. >> We saw a ~60% above average hit yesterday, And we're at ~20-30% above >> average today as well. >> Being an android user, It didn't dawn on me until some of the IOS users in >> the office started jumping up and down about IOS7 >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Justin M. Streiner" >> Sent: Wednesday, September 18, 2013 6:19 PM >> To: "NANOG" >> Subject: Re: iOS 7 update traffic >> >> On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: >> >>> We also noticed an interesting spike (+ ~40%), mostly in akamai. >>> The same happened on previous iOS too. >> >> I see it here, too. At its peak, our traffic levels were roughly double >> what we would see on a normal weekday. >> >> jms >> >>> Zachary McGibbon wrote on 18/9/2013 20:38: >>>> So iOS 7 just came out, here's the spike in our graphs going to our ISP >>>> here at McGill, anyone else noticing a big spike? >>>> >>>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>>> TenGigabitEthernet0/7] >>>> >>>> Zachary McGibbon >>>> >>> >>> >>> >> >> >> >> > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com > > From streiner at cluebyfour.org Thu Sep 19 14:13:07 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Sep 2013 10:13:07 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: On Thu, 19 Sep 2013, Paul Ferguson wrote: > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... I think this was just the traffic to download iOS 7 to everyones' relevant Apple devices. I don't know how large the update was (maybe a few hundred MB per device?), but I guess everyone got the notification or their devices started automatically downloading around the same time. The vast majority of the traffic here (large .edu) happened between about 1 and 5 PM yesterday. jms From patrick at ianai.net Thu Sep 19 18:09:57 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 19 Sep 2013 14:09:57 -0400 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <9BA6CF05-9B75-42E0-AFB1-C5B9371D323B@ianai.net> Composed on a virtual keyboard, please forgive typos. On Sep 19, 2013, at 13:58, Paul Ferguson wrote: > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... BING for "ios adoption rate" (one estimate is 29% in 16 hours), multiply by # of iThings, multiply by size of iOS, divide by # of seconds in estimate. As for why so many users upgrade so fast, that's a harder question. It could be iThing users are more willing to believe the fruit company's advertising (hype) . Could be that the device tells them to upgrade so they do. It is also at least partially due to the fact all iThings are upgradable (within a certain age horizon). Hope that gives you something to chew on, even if it doesn't answer the question. -- TTFN, patrick > On 9/19/2013 10:23 AM, Nick Olsen wrote: > >> We also saw a huge spike in traffic. Still pretty high today as well. >> We saw a ~60% above average hit yesterday, And we're at ~20-30% above >> average today as well. >> Being an android user, It didn't dawn on me until some of the IOS users in >> the office started jumping up and down about IOS7 >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Justin M. Streiner" >> Sent: Wednesday, September 18, 2013 6:19 PM >> To: "NANOG" >> Subject: Re: iOS 7 update traffic >> >> On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: >> >>> We also noticed an interesting spike (+ ~40%), mostly in akamai. >>> The same happened on previous iOS too. >> >> I see it here, too. At its peak, our traffic levels were roughly double >> what we would see on a normal weekday. >> >> jms >> >>> Zachary McGibbon wrote on 18/9/2013 20:38: >>>> So iOS 7 just came out, here's the spike in our graphs going to our ISP >>>> here at McGill, anyone else noticing a big spike? >>>> >>>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>>> TenGigabitEthernet0/7] >>>> >>>> Zachary McGibbon > > > -- > Paul Ferguson > Vice President, Threat Intelligence > Internet Identity, Tacoma, Washington USA > IID --> "Connect and Collaborate" --> www.internetidentity.com > > From wbailey at satelliteintelligencegroup.com Thu Sep 19 18:11:11 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 18:11:11 +0000 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : Why does apple feel it is okay to send every mobile device an update on a single day? Never mind the fact that we are we ones on the last mile responsible for getting it to their customers, 1gb per sub is pretty serious.. Why are they not caching at their head ends, dslams, etc? Sent from my Mobile Device. -------- Original message -------- From: Mikael Abrahamsson Date: 09/19/2013 11:08 AM (GMT-08:00) To: Paul Ferguson Cc: NANOG Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 megabytes for ipad. There are quite a few devices out there times these amounts to download... -- Mikael Abrahamsson email: swmike at swm.pp.se From tshaw at oitc.com Thu Sep 19 18:12:27 2013 From: tshaw at oitc.com (TR Shaw) Date: Thu, 19 Sep 2013 14:12:27 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <1D11CDEC-833B-4CCE-80D2-F1A4AF279438@oitc.com> Haven't updated my iPad yet but the iPhone update size was 1.12GB On Sep 19, 2013, at 2:05 PM, Mikael Abrahamsson wrote: > On Thu, 19 Sep 2013, Paul Ferguson wrote: > >> >> Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... > > The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 megabytes for ipad. There are quite a few devices out there times these amounts to download... > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From sethm at rollernet.us Thu Sep 19 18:12:44 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 19 Sep 2013 11:12:44 -0700 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <523B3E9C.8020405@rollernet.us> On 9/19/13 10:58 AM, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... iOS 7 itself was implemented. ~Seth From nick at flhsi.com Thu Sep 19 18:14:31 2013 From: nick at flhsi.com (Nick Olsen) Date: Thu, 19 Sep 2013 14:14:31 -0400 Subject: iOS 7 update traffic Message-ID: <3d061613$e048184$9de81aa$@flhsi.com> IOS7 was released (Yesterday?). Due to the large number of IOS devices out in the world. Some network operators experienced large spikes in traffic as each device was updated (Downloading the update). You see the same thing happen when new software is released from people like Microsoft. Or, If you're a gamer. When a new game is released on a digitally delivered platform like Steam or EA's Origin. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Paul Ferguson" Sent: Thursday, September 19, 2013 1:58 PM To: nick at flhsi.com, nanog at nanog.org Subject: Re: iOS 7 update traffic Can someone please explain to a non-Apple person what the hell happened that started generating so much traffic? Perhaps I missed it in this thread, but I would be curious to know what iOS 7 implemented that caused this... Thanks in adavnce, - ferg On 9/19/2013 10:23 AM, Nick Olsen wrote: > We also saw a huge spike in traffic. Still pretty high today as well. > We saw a ~60% above average hit yesterday, And we're at ~20-30% above > average today as well. > Being an android user, It didn't dawn on me until some of the IOS users in > the office started jumping up and down about IOS7 > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Justin M. Streiner" > Sent: Wednesday, September 18, 2013 6:19 PM > To: "NANOG" > Subject: Re: iOS 7 update traffic > > On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > >> We also noticed an interesting spike (+ ~40%), mostly in akamai. >> The same happened on previous iOS too. > > I see it here, too. At its peak, our traffic levels were roughly double > what we would see on a normal weekday. > > jms > >> Zachary McGibbon wrote on 18/9/2013 20:38: >>> So iOS 7 just came out, here's the spike in our graphs going to our ISP >>> here at McGill, anyone else noticing a big spike? >>> >>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>> TenGigabitEthernet0/7] >>> >>> Zachary McGibbon >>> >> >> >> > > > > -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From fergdawgster at mykolab.com Thu Sep 19 18:14:30 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 19 Sep 2013 11:14:30 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <523B3F06.3040005@mykolab.com> Okay, that makes sense. Just wanted to ensure it wasn't something more sinister. Thanks, - ferg On 9/19/2013 11:05 AM, Mikael Abrahamsson wrote: > On Thu, 19 Sep 2013, Paul Ferguson wrote: > >> >> Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... > > The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 > megabytes for ipad. There are quite a few devices out there times these > amounts to download... > -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From bedard.phil at gmail.com Thu Sep 19 18:16:06 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 19 Sep 2013 14:16:06 -0400 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> Message-ID: Tens of millions of devices multiplied times a fairly large download = lots of bandwidth. It has an appreciable affect on the worldwide Internet. I would love to see some aggregate statistics. With most phones the carrier takes care of doing phone software updates and rollouts over a period of time since they all have customized versions of Android/Windows Phone/etc. Apple controls their phone software so they just hit the switch at a certain data/time and let as many people update as their servers can handle. Not to mention all the IPads which they chose to update at the same time. Last time around we saw a sustained increase in traffic for about a week after the release date. -Phil On 9/19/13 1:58 PM, "Paul Ferguson" wrote: > >Can someone please explain to a non-Apple person what the hell happened >that started generating so much traffic? Perhaps I missed it in this >thread, but I would be curious to know what iOS 7 implemented that >caused this... > >Thanks in adavnce, > >- ferg > >On 9/19/2013 10:23 AM, Nick Olsen wrote: > >> We also saw a huge spike in traffic. Still pretty high today as well. >> We saw a ~60% above average hit yesterday, And we're at ~20-30% above >> average today as well. >> Being an android user, It didn't dawn on me until some of the IOS users >>in >> the office started jumping up and down about IOS7 >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Justin M. Streiner" >> Sent: Wednesday, September 18, 2013 6:19 PM >> To: "NANOG" >> Subject: Re: iOS 7 update traffic >> >> On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: >> >>> We also noticed an interesting spike (+ ~40%), mostly in akamai. >>> The same happened on previous iOS too. >> >> I see it here, too. At its peak, our traffic levels were roughly double >> what we would see on a normal weekday. >> >> jms >> >>> Zachary McGibbon wrote on 18/9/2013 20:38: >>>> So iOS 7 just came out, here's the spike in our graphs going to our >>>>ISP >>>> here at McGill, anyone else noticing a big spike? >>>> >>>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>>> TenGigabitEthernet0/7] >>>> >>>> Zachary McGibbon >>>> >>> >>> >>> >> >> >> >> > > >-- >Paul Ferguson >Vice President, Threat Intelligence >Internet Identity, Tacoma, Washington USA >IID --> "Connect and Collaborate" --> www.internetidentity.com > > From swmike at swm.pp.se Thu Sep 19 18:16:29 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 19 Sep 2013 20:16:29 +0200 (CEST) Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: On Thu, 19 Sep 2013, Warren Bailey wrote: > Why does apple feel it is okay to send every mobile device an update on a single day? They don't, these are users who actively goes into the software upgrade menu and pressing "upgrade". I believe the nagging won't start for quite some time. -- Mikael Abrahamsson email: swmike at swm.pp.se From hhoffman at ip-solutions.net Thu Sep 19 18:18:23 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 19 Sep 2013 14:18:23 -0400 Subject: iOS 7 update traffic Message-ID: They implemented fanboy-lust which :-) Paul Ferguson wrote: > >Can someone please explain to a non-Apple person what the hell happened >that started generating so much traffic? Perhaps I missed it in this >thread, but I would be curious to know what iOS 7 implemented that >caused this... > >Thanks in adavnce, > >- ferg > >On 9/19/2013 10:23 AM, Nick Olsen wrote: > >> We also saw a huge spike in traffic. Still pretty high today as well. >> We saw a ~60% above average hit yesterday, And we're at ~20-30% above >> average today as well. >> Being an android user, It didn't dawn on me until some of the IOS users in >> the office started jumping up and down about IOS7 >> Nick Olsen >> Network Operations (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Justin M. Streiner" >> Sent: Wednesday, September 18, 2013 6:19 PM >> To: "NANOG" >> Subject: Re: iOS 7 update traffic >> >> On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: >> >>> We also noticed an interesting spike (+ ~40%), mostly in akamai. >>> The same happened on previous iOS too. >> >> I see it here, too. At its peak, our traffic levels were roughly double >> what we would see on a normal weekday. >> >> jms >> >>> Zachary McGibbon wrote on 18/9/2013 20:38: >>>> So iOS 7 just came out, here's the spike in our graphs going to our ISP >>>> here at McGill, anyone else noticing a big spike? >>>> >>>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - >>>> TenGigabitEthernet0/7] >>>> >>>> Zachary McGibbon >>>> >>> >>> >>> >> >> >> >> > > >-- >Paul Ferguson >Vice President, Threat Intelligence >Internet Identity, Tacoma, Washington USA >IID --> "Connect and Collaborate" --> www.internetidentity.com > > From wbailey at satelliteintelligencegroup.com Thu Sep 19 18:22:50 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 18:22:50 +0000 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , Message-ID: I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's sequentially. That way, you do not.. 1. Murder your last mike packet network, which is your bandwidth bottleneck. 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. 3. Anger your paying customers who would like to use packet data successfully on an ios download day. These people (Apple) represent themselves as smart guys, but their actions reflect otherwise. I bet this would be a larger deal to Nanog people if your Internet stopped working as the result of 100% Linux adoption. That is very close to what this is.. Tens of millions of people trying to update their 13 ios devices at the same time. Who owns a single ios device? A household could do 5-10gb worth of updates in a single day.. I personally do not own an ios device, and I see close to 3 gigs worth of update traffic at my house. These things are everywhere, and this problem will not stop. Sent from my Mobile Device. -------- Original message -------- From: Mikael Abrahamsson Date: 09/19/2013 11:16 AM (GMT-08:00) To: Warren Bailey Cc: Paul Ferguson ,NANOG Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013, Warren Bailey wrote: > Why does apple feel it is okay to send every mobile device an update on a single day? They don't, these are users who actively goes into the software upgrade menu and pressing "upgrade". I believe the nagging won't start for quite some time. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Thu Sep 19 18:29:03 2013 From: randy at psg.com (Randy Bush) Date: Thu, 19 Sep 2013 08:29:03 -1000 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: > Can someone please explain to a non-Apple person what the hell happened > that started generating so much traffic? Perhaps I missed it in this > thread, but I would be curious to know what iOS 7 implemented that > caused this... all the borders and highlights from the discarded skeuomorphisms cloged up the intertubes bigtime randy From sparctacus at gmail.com Thu Sep 19 18:31:22 2013 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 19 Sep 2013 11:31:22 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: Apple actually tries to rate-limit the notifications to prevent this, but you can just manually go check and hit the upgrade button yourself. It's pretty well-known that Apple likes to release ~10am, so tens (hundreds?) of millions of users did just that. Since this update is available for all iThingies made in the last 4-ish years that means a lot of extra traffic. On Thu, Sep 19, 2013 at 7:13 AM, Justin M. Streiner wrote: > On Thu, 19 Sep 2013, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... >> > > I think this was just the traffic to download iOS 7 to everyones' relevant > Apple devices. I don't know how large the update was (maybe a few hundred > MB per device?), but I guess everyone got the notification or their devices > started automatically downloading around the same time. The vast majority > of the traffic here (large .edu) happened between about 1 and 5 PM > yesterday. > > jms > > From sparctacus at gmail.com Thu Sep 19 18:36:36 2013 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 19 Sep 2013 11:36:36 -0700 Subject: iOS 7 update traffic In-Reply-To: <1D11CDEC-833B-4CCE-80D2-F1A4AF279438@oitc.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1D11CDEC-833B-4CCE-80D2-F1A4AF279438@oitc.com> Message-ID: My iPhone4 was about 600MB IIRC. My iPad mini was about that. I have about 7 iDevices between everyone in my immediate family. FWIW not a single one has actually received the notification yet. I've only manually done my 2 devices. I'm waiting to see how long it takes before I get the 'official' notification of an update on the others. On Thu, Sep 19, 2013 at 11:12 AM, TR Shaw wrote: > Haven't updated my iPad yet but the iPhone update size was 1.12GB > > On Sep 19, 2013, at 2:05 PM, Mikael Abrahamsson wrote: > > > On Thu, 19 Sep 2013, Paul Ferguson wrote: > > > >> > >> Can someone please explain to a non-Apple person what the hell happened > >> that started generating so much traffic? Perhaps I missed it in this > >> thread, but I would be curious to know what iOS 7 implemented that > >> caused this... > > > > The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 > megabytes for ipad. There are quite a few devices out there times these > amounts to download... > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > From nanog at namor.ca Thu Sep 19 18:37:19 2013 From: nanog at namor.ca (nanog at namor.ca) Date: Thu, 19 Sep 2013 13:37:19 -0500 (CDT) Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: On Thu, 19 Sep 2013, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think > of a single provider who does not oversubscribe their access platform... > Which leads me to this question : > > Why does apple feel it is okay to send every mobile device an update on > a single day? > > Never mind the fact that we are we ones on the last mile responsible for > getting it to their customers, 1gb per sub is pretty serious.. Why are > they not caching at their head ends, dslams, etc? As far as I was aware, it was at least staggered throughout the day, so there's some concession. Also a reason to have some CDNs in any large deployment, I guess. I saw a spike in our Akamai traffic, but only slight. > Sent from my Mobile Device. From mikea at mikea.ath.cx Thu Sep 19 18:41:05 2013 From: mikea at mikea.ath.cx (Mike A) Date: Thu, 19 Sep 2013 13:41:05 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <20130919184105.GB38693@mikea.ath.cx> On Thu, Sep 19, 2013 at 06:11:11PM +0000, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think of a > single provider who does not oversubscribe their access platform... Which > leads me to this question : > > Why does apple feel it is okay to send every mobile device an update on a > single day? > > Never mind the fact that we are we ones on the last mile responsible for > getting it to their customers, 1gb per sub is pretty serious.. Why are they > not caching at their head ends, dslams, etc? They didn't make it available to everyone on the same day. My iphone 5 didn't see it until today; I looked yesterday, and it wasn't available for that device. I'm busily contributing to the network stress now. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From jabley at hopcount.ca Thu Sep 19 18:42:12 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 19 Sep 2013 14:42:12 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: <61F956AA-C5B6-4BBE-8213-67964E818F2D@hopcount.ca> On 2013-09-19, at 14:11, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : > > Why does apple feel it is okay to send every mobile device an update on a single day? How is this different from the flash crowds caused by hockey championships, or football games, or any of the other things that generate a lot of simultaneous interest every once in a while? > Never mind the fact that we are we ones on the last mile responsible for getting it to their customers, 1gb per sub is pretty serious.. Why are they not caching at their head ends, dslams, etc? Given that the code is signed, I'm surprised that iDevices that have already upgraded the hard way don't advertise a "update available" service on local networks. Individual devices don't care where the updates come from, so long as the signatures are good. You'd think that'd have the potential to improve the user experience as well as avoid jamming the tubes, especially in highly multi-user environments like university campuses; it could probably halve the network load in a significant number of home networks, too. Joe From james.cutler at consultant.com Thu Sep 19 18:43:30 2013 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 19 Sep 2013 14:43:30 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: <79A1CA2E-72EE-4396-AEE9-D496514EF81A@consultant.com> On Sep 19, 2013, at 2:11 PM, Warren Bailey wrote: > Why does apple feel it is okay to send every mobile device an update on a single day? Apple does not "send" updates. The user device must request an update. --As a side note, IOS 7 fixes/improves iDevices in multiple areas, making it a compelling upgrade. James R. Cutler james.cutler at consultant.com From wbailey at satelliteintelligencegroup.com Thu Sep 19 18:44:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 18:44:15 +0000 Subject: iOS 7 update traffic In-Reply-To: <61F956AA-C5B6-4BBE-8213-67964E818F2D@hopcount.ca> Message-ID: http://images.mirror.co.uk/upl/m4/jun2011/6/0/image-5-for-riots-break-out-a fter-vancouver-canucks-lose-the-nhl-stanley-cup-playoffs-to-the-boston-brui ns-gallery-116084753.jpg Good example of the flash crowds post hockey championship It's not all butterflies, Abley.. LOL On 9/19/13 11:42 AM, "Joe Abley" wrote: > >On 2013-09-19, at 14:11, Warren Bailey > wrote: > >> I don't see how operators could tolerate this, honestly. I can't think >>of a single provider who does not oversubscribe their access platform... >>Which leads me to this question : >> >> Why does apple feel it is okay to send every mobile device an update on >>a single day? > >How is this different from the flash crowds caused by hockey >championships, or football games, or any of the other things that >generate a lot of simultaneous interest every once in a while? > >> Never mind the fact that we are we ones on the last mile responsible >>for getting it to their customers, 1gb per sub is pretty serious.. Why >>are they not caching at their head ends, dslams, etc? > >Given that the code is signed, I'm surprised that iDevices that have >already upgraded the hard way don't advertise a "update available" >service on local networks. Individual devices don't care where the >updates come from, so long as the signatures are good. > >You'd think that'd have the potential to improve the user experience as >well as avoid jamming the tubes, especially in highly multi-user >environments like university campuses; it could probably halve the >network load in a significant number of home networks, too. > > >Joe > From wbailey at satelliteintelligencegroup.com Thu Sep 19 18:46:49 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 18:46:49 +0000 Subject: iOS 7 update traffic In-Reply-To: <79A1CA2E-72EE-4396-AEE9-D496514EF81A@consultant.com> Message-ID: A line, is a line, is a line, is a line. There's no difference. Updates are available to all devices on a "download day", and providers networks are drastically reduced in capacity as a result. Apple does not cut them checks to serve it up, why should that traffic be more important than anything else? I'd DSCP updates to best effort hell and tell Apple I'd like a small share of the revenue they've gained from all the devices *I* am responsible for updating. They're not getting these updates OTA often, they actually advocate (shocking, AT&T wanting to save bandwidth) using your home Wi-Fi to download it. Providers can handle peaks, but SURGES begin to cause problems quickly. On narrowband pipes, we actually KILL updates.. They screw us that hard. On 9/19/13 11:43 AM, "Cutler James R" wrote: >On Sep 19, 2013, at 2:11 PM, Warren Bailey > wrote: > >> Why does apple feel it is okay to send every mobile device an update on >>a single day? > >Apple does not "send" updates. The user device must request an update. > >--As a side note, IOS 7 fixes/improves iDevices in multiple areas, making >it a compelling upgrade. > > > > >James R. Cutler >james.cutler at consultant.com > > > > > > From freimer at freimer.org Thu Sep 19 18:48:49 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 19 Sep 2013 18:48:49 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: Why should Apple care if providers have oversubscribed lines or not? As far as I know, Akamai delivers most of the data anyway, so it is not coming all from Apple. I don't know for sure, but I doubt they have enough bandwidth themselves to saturate so many links concurrently. Apple also does not push the updates, it is pulled to the device when the users tell the device to retrieve it. So blame your users, not Apple. It is also my understanding that any updates they do push are staged so they all don't go out the same time. On 9/19/13 2:11 PM, "Warren Bailey" wrote: >I don't see how operators could tolerate this, honestly. I can't think of >a single provider who does not oversubscribe their access platform... >Which leads me to this question : > >Why does apple feel it is okay to send every mobile device an update on a >single day? > >Never mind the fact that we are we ones on the last mile responsible for >getting it to their customers, 1gb per sub is pretty serious.. Why are >they not caching at their head ends, dslams, etc? > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: Mikael Abrahamsson >Date: 09/19/2013 11:08 AM (GMT-08:00) >To: Paul Ferguson >Cc: NANOG >Subject: Re: iOS 7 update traffic > > >On Thu, 19 Sep 2013, Paul Ferguson wrote: > >> >> Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... > >The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 >megabytes for ipad. There are quite a few devices out there times these >amounts to download... > >-- >Mikael Abrahamsson email: swmike at swm.pp.se > From patrick at ianai.net Thu Sep 19 18:50:09 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 19 Sep 2013 14:50:09 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <16BC3517-2A8F-4415-9B99-7CB5238A6472@ianai.net> Composed on a virtual keyboard, please forgive typos. On Sep 19, 2013, at 14:11, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : > > Why does apple feel it is okay to send every mobile device an update on a single day? That question makes no sense to me. Turn that around: Why would Apple think that is not OK? > Never mind the fact that we are we ones on the last mile responsible for getting it to their customers, 1gb per sub is pretty serious.. Why are they not caching at their head ends, dslams, etc? Most providers are offered a cache for free (there is a minimum traffic volume, but it is not even as large as Netflix's requirements). Every provider, regardless of traffic, is offered peering for free. What was the problem again? -- TTFN, patrick > -------- Original message -------- > From: Mikael Abrahamsson > Date: 09/19/2013 11:08 AM (GMT-08:00) > To: Paul Ferguson > Cc: NANOG > Subject: Re: iOS 7 update traffic > > > On Thu, 19 Sep 2013, Paul Ferguson wrote: > >> >> Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... > > The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 > megabytes for ipad. There are quite a few devices out there times these > amounts to download... > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From Valdis.Kletnieks at vt.edu Thu Sep 19 18:51:21 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Sep 2013 14:51:21 -0400 Subject: iOS 7 update traffic In-Reply-To: Your message of "Thu, 19 Sep 2013 18:11:11 -0000." References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: <15759.1379616681@turing-police.cc.vt.edu> On Thu, 19 Sep 2013 18:11:11 -0000, Warren Bailey said: > Why does apple feel it is okay to send every mobile device an update on a single day? How is Patch Tuesday any different? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu Sep 19 18:52:51 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 18:52:51 +0000 Subject: iOS 7 update traffic In-Reply-To: References: , Message-ID: My.. Our.. Users expect one thing.. Internet. It is our job to make that happen. When a electronics manufacturer decides to enable updates for all of their phones world wide.. It breaks things. When the Internet breaks, it is my fault. Your Apple update sucked because of me.. There is no "it must be apple", as you pointed out earlier. I'm simply saying.. It's a dick move to globally enable updates on a single day and tell ISP's to deal with it. Sent from my Mobile Device. -------- Original message -------- From: Fred Reimer Date: 09/19/2013 11:48 AM (GMT-08:00) To: Warren Bailey ,Mikael Abrahamsson ,Paul Ferguson Cc: NANOG Subject: Re: iOS 7 update traffic Why should Apple care if providers have oversubscribed lines or not? As far as I know, Akamai delivers most of the data anyway, so it is not coming all from Apple. I don't know for sure, but I doubt they have enough bandwidth themselves to saturate so many links concurrently. Apple also does not push the updates, it is pulled to the device when the users tell the device to retrieve it. So blame your users, not Apple. It is also my understanding that any updates they do push are staged so they all don't go out the same time. On 9/19/13 2:11 PM, "Warren Bailey" wrote: >I don't see how operators could tolerate this, honestly. I can't think of >a single provider who does not oversubscribe their access platform... >Which leads me to this question : > >Why does apple feel it is okay to send every mobile device an update on a >single day? > >Never mind the fact that we are we ones on the last mile responsible for >getting it to their customers, 1gb per sub is pretty serious.. Why are >they not caching at their head ends, dslams, etc? > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: Mikael Abrahamsson >Date: 09/19/2013 11:08 AM (GMT-08:00) >To: Paul Ferguson >Cc: NANOG >Subject: Re: iOS 7 update traffic > > >On Thu, 19 Sep 2013, Paul Ferguson wrote: > >> >> Can someone please explain to a non-Apple person what the hell happened >> that started generating so much traffic? Perhaps I missed it in this >> thread, but I would be curious to know what iOS 7 implemented that >> caused this... > >The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 >megabytes for ipad. There are quite a few devices out there times these >amounts to download... > >-- >Mikael Abrahamsson email: swmike at swm.pp.se > From hardenrm at uchicago.edu Thu Sep 19 19:06:38 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Thu, 19 Sep 2013 19:06:38 +0000 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , Message-ID: <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> To be honest, I don't see this as a problem at all. Use it as an excuse to upgrade your pipes, talk Akamai or CDN of choice into putting a cache on your network, or implement your own caching solution. As operators of the Internet we should be looking for ways to enable things like this, not be up in arms at Apple for releasing an update to their phone OS or making it available in a way that's inconvenient to our oversubscription policies. As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. This isn't a new phenomenon. I realize some of you are too cool for Apple, but paying attention to traffic trends and keeping abreast of how new software releases might affect your utilization is part of properly running a network. /Ryan Ryan Harden Senior Network Engineer University of Chicago - AS160 P: 773-834-5441 On Sep 19, 2013, at 1:22 PM, Warren Bailey wrote: > I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's sequentially. That way, you do not.. > > 1. Murder your last mike packet network, which is your bandwidth bottleneck. > > 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. > > 3. Anger your paying customers who would like to use packet data successfully on an ios download day. > > These people (Apple) represent themselves as smart guys, but their actions reflect otherwise. I bet this would be a larger deal to Nanog people if your Internet stopped working as the result of 100% Linux adoption. That is very close to what this is.. Tens of millions of people trying to update their 13 ios devices at the same time. Who owns a single ios device? A household could do 5-10gb worth of updates in a single day.. > > I personally do not own an ios device, and I see close to 3 gigs worth of update traffic at my house. These things are everywhere, and this problem will not stop. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Mikael Abrahamsson > Date: 09/19/2013 11:16 AM (GMT-08:00) > To: Warren Bailey > Cc: Paul Ferguson ,NANOG > Subject: Re: iOS 7 update traffic > > > On Thu, 19 Sep 2013, Warren Bailey wrote: > >> Why does apple feel it is okay to send every mobile device an update on a single day? > > They don't, these are users who actively goes into the software upgrade > menu and pressing "upgrade". > > I believe the nagging won't start for quite some time. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Thu Sep 19 19:07:45 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Sep 2013 15:07:45 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: The attitude in this email I have encountered elsewhere. Apple pays for bandwidth, customers pay for access. Not sure why their release strategy is so highly critiqued. Microsoft and others have their own strategies for incremental downloads, caching, etc.. Apple has theirs. Seems like most consumers want the update and are actively fetching it vs having older software live forever and not be updated. Overall I see this as a win. Jared Mauch > On Sep 19, 2013, at 2:11 PM, Warren Bailey wrote: > > I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : > > Why does apple feel it is okay to send every mobile device an update on a single day? From freimer at freimer.org Thu Sep 19 19:10:17 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 19 Sep 2013 19:10:17 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: O.K., I understand. Yes, for the average user I suppose they would blame their ISP. I was making the wrong assumption that people understood how the Internet works. At the same time, people would probably be more upset, at least the Apple fanboys, if they metered the updates and some people had to wait two or three weeks for their update to keep the traffic manageable. The only general news stories I see in a quick search are complaints that the downloads are slow, not that the general Internet is slow because of the downloads? From: Warren Bailey Reply-To: Warren Bailey Date: Thursday, September 19, 2013 2:52 PM To: Fred Reimer , Mikael Abrahamsson , Paul Ferguson Cc: NANOG Subject: Re: iOS 7 update traffic >My.. Our.. Users expect one thing.. > >Internet. > >It is our job to make that happen. When a electronics manufacturer >decides to enable updates for all of their phones world wide.. It breaks >things. > > >When the Internet breaks, it is my fault. Your Apple update sucked >because of me.. There is no "it must be apple", as you pointed out >earlier. I'm simply saying.. It's a dick move to globally enable updates >on a single day and tell ISP's to deal with it. > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: Fred Reimer >Date: 09/19/2013 11:48 AM (GMT-08:00) >To: Warren Bailey ,Mikael >Abrahamsson ,Paul Ferguson > >Cc: NANOG >Subject: Re: iOS 7 update traffic > > > >Why should Apple care if providers have oversubscribed lines or not? As >far as I know, Akamai delivers most of the data anyway, so it is not >coming all from Apple. I don't know for sure, but I doubt they have >enough bandwidth themselves to saturate so many links concurrently. Apple >also does not push the updates, it is pulled to the device when the users >tell the device to retrieve it. So blame your users, not Apple. It is >also my understanding that any updates they do push are staged so they all >don't go out the same time. > >On 9/19/13 2:11 PM, "Warren Bailey" > wrote: > >>I don't see how operators could tolerate this, honestly. I can't think of >>a single provider who does not oversubscribe their access platform... >>Which leads me to this question : >> >>Why does apple feel it is okay to send every mobile device an update on a >>single day? >> >>Never mind the fact that we are we ones on the last mile responsible for >>getting it to their customers, 1gb per sub is pretty serious.. Why are >>they not caching at their head ends, dslams, etc? >> >> >>Sent from my Mobile Device. >> >> >>-------- Original message -------- >>From: Mikael Abrahamsson >>Date: 09/19/2013 11:08 AM (GMT-08:00) >>To: Paul Ferguson >>Cc: NANOG >>Subject: Re: iOS 7 update traffic >> >> >>On Thu, 19 Sep 2013, Paul Ferguson wrote: >> >>> >>> Can someone please explain to a non-Apple person what the hell happened >>> that started generating so much traffic? Perhaps I missed it in this >>> thread, but I would be curious to know what iOS 7 implemented that >>> caused this... >> >>The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 >>megabytes for ipad. There are quite a few devices out there times these >>amounts to download... >> >>-- >>Mikael Abrahamsson email: swmike at swm.pp.se >> From wbailey at satelliteintelligencegroup.com Thu Sep 19 19:11:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 19:11:21 +0000 Subject: iOS 7 update traffic In-Reply-To: <15759.1379616681@turing-police.cc.vt.edu> Message-ID: Patch Tuesday is not 1gb per patch. On 9/19/13 11:51 AM, "Valdis.Kletnieks at vt.edu" wrote: >On Thu, 19 Sep 2013 18:11:11 -0000, Warren Bailey said: > >> Why does apple feel it is okay to send every mobile device an update on >>a single day? > >How is Patch Tuesday any different? From nrollo at kw-corp.com Thu Sep 19 18:34:32 2013 From: nrollo at kw-corp.com (Nolan Rollo) Date: Thu, 19 Sep 2013 18:34:32 +0000 Subject: car2.Detroit1.Level3.net Message-ID: Does anyone know of an issue involving car2.Detroit1.Level3.net and its handoffs? We have been experiencing about 25% packet loss this week which resulted in an outage from 19/Sep/2013 13:52 to 19/Sep/2013 14:01 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.0.1 2 3 ms 2 ms 2 ms d233-64-65-227.dim.wideopenwest.com [64.233.227.65] 3 666 ms 705 ms 530 ms ge-7-43.car2.Detroit1.Level3.net [4.53.74.109] 4 * * * Request timed out. 5 * * * Request timed out. Nolan Rollo VoIP Engineer Main: 517.223.3610x114 Fax: 517.223.4120 www.kw-corp.com From gcarr at us.ntt.net Thu Sep 19 18:07:01 2013 From: gcarr at us.ntt.net (Garrison Carr) Date: Thu, 19 Sep 2013 11:07:01 -0700 Subject: iOS 7 update traffic In-Reply-To: <523B3B40.5070309@mykolab.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <00a401ceb563$0a4e0c80$1eea2580$@us.ntt.net> Apple pushed out a new software upgrade for their user interface...a pretty big upgrade, all the iphone users are downloading it congesting the network. Garrison Carr This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT America makes no warranty that this email is error or virus free. Thank you . -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at mykolab.com] Sent: Thursday, September 19, 2013 10:58 AM To: NANOG Subject: Re: iOS 7 update traffic Can someone please explain to a non-Apple person what the hell happened that started generating so much traffic? Perhaps I missed it in this thread, but I would be curious to know what iOS 7 implemented that caused this... Thanks in adavnce, - ferg On 9/19/2013 10:23 AM, Nick Olsen wrote: > We also saw a huge spike in traffic. Still pretty high today as well. > We saw a ~60% above average hit yesterday, And we're at ~20-30% above > average today as well. > Being an android user, It didn't dawn on me until some of the IOS > users in the office started jumping up and down about IOS7 Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Justin M. Streiner" > Sent: Wednesday, September 18, 2013 6:19 PM > To: "NANOG" > Subject: Re: iOS 7 update traffic > > On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: > >> We also noticed an interesting spike (+ ~40%), mostly in akamai. >> The same happened on previous iOS too. > > I see it here, too. At its peak, our traffic levels were roughly > double what we would see on a normal weekday. > > jms > >> Zachary McGibbon wrote on 18/9/2013 20:38: >>> So iOS 7 just came out, here's the spike in our graphs going to our >>> ISP here at McGill, anyone else noticing a big spike? >>> >>> [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) >>> - TenGigabitEthernet0/7] >>> >>> Zachary McGibbon >>> >> >> >> > > > > -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From ml at kenweb.org Thu Sep 19 19:18:00 2013 From: ml at kenweb.org (ML) Date: Thu, 19 Sep 2013 15:18:00 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523B4DE8.9030504@kenweb.org> On 9/18/2013 1:38 PM, Zachary McGibbon wrote: > So iOS 7 just came out, here's the spike in our graphs going to our ISP > here at McGill, anyone else noticing a big spike? > > [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - > TenGigabitEthernet0/7] > > Zachary McGibbon Traffic was +1Gbps more than usual during that time on 9/18 From wbailey at satelliteintelligencegroup.com Thu Sep 19 19:18:29 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 19:18:29 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: How about add a cache in your time capsule/thing that everyone connects to? I mean, would it be THAT hard to enable a bonjour update server on an apple router/computer/whatever and serve things up locally from there? I've had many replies to this email already, and people are talking about upgrading bandwidth and CDN's. We own and operate a satellite data network. It is narrow band.. It is very expensive. Oversub matters.. Time slots matter. When we (industry, collectively) have to deal with hundreds of gigs worth of traffic it's a tough day. I just can't understand why these big boys have forgotten most of the planet doesn't have a 1000000gbps pipe anywhere near them, a lot of the earth actually doesn't have communications infrastructure at all. The quick "WE HAVE ENOUGH INTERNETS NOW" doesn't apply to every system, nor does it explain why an update needs to be sent relentlessly to individual devices (requested or not) over the course of a product's evolution. Things are not created equal amongst internet providers, a transponder (90mbps ish) runs us close to 160k a month and that's not including gear costs, teleport, etc. We strive to provide a great customer experience, and when "Hardware Maker X" decides to roll updates .. It can screw us. In this case, can means absolutely will happen. My .02. Not trying to start a flame thing or tell people what's what.. Just trying to get a point across. You don't need to send things individually now.. We live in the future.. We should act like it. On 9/19/13 12:10 PM, "Fred Reimer" wrote: >O.K., I understand. Yes, for the average user I suppose they would blame >their ISP. I was making the wrong assumption that people understood how >the Internet works. At the same time, people would probably be more >upset, at least the Apple fanboys, if they metered the updates and some >people had to wait two or three weeks for their update to keep the traffic >manageable. The only general news stories I see in a quick search are >complaints that the downloads are slow, not that the general Internet is >slow because of the downloads? > > >From: Warren Bailey >Reply-To: Warren Bailey >Date: Thursday, September 19, 2013 2:52 PM >To: Fred Reimer , Mikael Abrahamsson >, Paul Ferguson >Cc: NANOG >Subject: Re: iOS 7 update traffic > > >>My.. Our.. Users expect one thing.. >> >>Internet. >> >>It is our job to make that happen. When a electronics manufacturer >>decides to enable updates for all of their phones world wide.. It breaks >>things. >> >> >>When the Internet breaks, it is my fault. Your Apple update sucked >>because of me.. There is no "it must be apple", as you pointed out >>earlier. I'm simply saying.. It's a dick move to globally enable updates >>on a single day and tell ISP's to deal with it. >> >> >>Sent from my Mobile Device. >> >> >>-------- Original message -------- >>From: Fred Reimer >>Date: 09/19/2013 11:48 AM (GMT-08:00) >>To: Warren Bailey ,Mikael >>Abrahamsson ,Paul Ferguson >> >>Cc: NANOG >>Subject: Re: iOS 7 update traffic >> >> >> >>Why should Apple care if providers have oversubscribed lines or not? As >>far as I know, Akamai delivers most of the data anyway, so it is not >>coming all from Apple. I don't know for sure, but I doubt they have >>enough bandwidth themselves to saturate so many links concurrently. >>Apple >>also does not push the updates, it is pulled to the device when the users >>tell the device to retrieve it. So blame your users, not Apple. It is >>also my understanding that any updates they do push are staged so they >>all >>don't go out the same time. >> >>On 9/19/13 2:11 PM, "Warren Bailey" >> wrote: >> >>>I don't see how operators could tolerate this, honestly. I can't think >>>of >>>a single provider who does not oversubscribe their access platform... >>>Which leads me to this question : >>> >>>Why does apple feel it is okay to send every mobile device an update on >>>a >>>single day? >>> >>>Never mind the fact that we are we ones on the last mile responsible for >>>getting it to their customers, 1gb per sub is pretty serious.. Why are >>>they not caching at their head ends, dslams, etc? >>> >>> >>>Sent from my Mobile Device. >>> >>> >>>-------- Original message -------- >>>From: Mikael Abrahamsson >>>Date: 09/19/2013 11:08 AM (GMT-08:00) >>>To: Paul Ferguson >>>Cc: NANOG >>>Subject: Re: iOS 7 update traffic >>> >>> >>>On Thu, 19 Sep 2013, Paul Ferguson wrote: >>> >>>> >>>> Can someone please explain to a non-Apple person what the hell >>>>happened >>>> that started generating so much traffic? Perhaps I missed it in this >>>> thread, but I would be curious to know what iOS 7 implemented that >>>> caused this... >>> >>>The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 >>>megabytes for ipad. There are quite a few devices out there times these >>>amounts to download... >>> >>>-- >>>Mikael Abrahamsson email: swmike at swm.pp.se >>> > From Valdis.Kletnieks at vt.edu Thu Sep 19 19:22:35 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Sep 2013 15:22:35 -0400 Subject: iOS 7 update traffic In-Reply-To: Your message of "Thu, 19 Sep 2013 19:11:21 -0000." References: Message-ID: <18491.1379618555@turing-police.cc.vt.edu> (merging 2 replies) On Thu, 19 Sep 2013 19:11:21 -0000, Warren Bailey said: > Patch Tuesday is not 1gb per patch. It is those months a service pack comes out. On Thu, 19 Sep 2013 18:22:50 -0000, Warren Bailey said: > These people (Apple) represent themselves as smart guys, but their actions reflect otherwise. No - their actions *are* those of smart guys. They knew damned well that they didn't need to add capacity, because the chances that they'll lose an iOS customer to Android over slow update speeds is infinitesimal. In other words, they successfully made the bandwidth consumption an externality. (What, like you don't look at *your* network and wonder "How can I stick somebody else with the cost of XYZ?". :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From cloos at jhcloos.com Thu Sep 19 19:26:19 2013 From: cloos at jhcloos.com (James Cloos) Date: Thu, 19 Sep 2013 15:26:19 -0400 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> (Timothy Metzinger's message of "Wed, 18 Sep 2013 18:41:22 -0400") References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> Message-ID: >>>>> "TM" == Timothy Metzinger writes: TM> or ARIN publishes a list of IP assignments that can be TM> used by ISPs to provisionally remove them from blocked lists? Arin publishes all new assignments to : List-Help: List-Subscribe: , -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From freimer at freimer.org Thu Sep 19 19:36:58 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 19 Sep 2013 19:36:58 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: Woah there. I think you are crossing another line, or at least opening another topic of discussion, when you start talking about transit or last mile providers charging companies for bandwidth that their customers are already paying for. I'd suggest a subject change if we want to open a discussion on that topic. On 9/19/13 2:46 PM, "Warren Bailey" wrote: >A line, is a line, is a line, is a line. > >There's no difference. Updates are available to all devices on a "download >day", and providers networks are drastically reduced in capacity as a >result. Apple does not cut them checks to serve it up, why should that >traffic be more important than anything else? I'd DSCP updates to best >effort hell and tell Apple I'd like a small share of the revenue they've >gained from all the devices *I* am responsible for updating. They're not >getting these updates OTA often, they actually advocate (shocking, AT&T >wanting to save bandwidth) using your home Wi-Fi to download it. Providers >can handle peaks, but SURGES begin to cause problems quickly. On >narrowband pipes, we actually KILL updates.. They screw us that hard. > >On 9/19/13 11:43 AM, "Cutler James R" wrote: > >>On Sep 19, 2013, at 2:11 PM, Warren Bailey >> wrote: >> >>> Why does apple feel it is okay to send every mobile device an update on >>>a single day? >> >>Apple does not "send" updates. The user device must request an update. >> >>--As a side note, IOS 7 fixes/improves iDevices in multiple areas, making >>it a compelling upgrade. >> >> >> >> >>James R. Cutler >>james.cutler at consultant.com >> >> >> >> >> >> > > From gabe at teksavvy.ca Thu Sep 19 19:38:57 2013 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Thu, 19 Sep 2013 15:38:57 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523B52D1.6000003@teksavvy.ca> On 13-09-19 02:46 PM, Warren Bailey wrote: > A line, is a line, is a line, is a line. > > There's no difference. Updates are available to all devices on a "download > day", and providers networks are drastically reduced in capacity as a > result. Apple does not cut them checks to serve it up, why should that > traffic be more important than anything else? I'd DSCP updates to best > effort hell and tell Apple I'd like a small share of the revenue they've > gained from all the devices *I* am responsible for updating. They're not > getting these updates OTA often, they actually advocate (shocking, AT&T > wanting to save bandwidth) using your home Wi-Fi to download it. Providers > can handle peaks, but SURGES begin to cause problems quickly. On > narrowband pipes, we actually KILL updates.. They screw us that hard. You fail at internet, please try again later. From ryan at hack.net Thu Sep 19 19:40:15 2013 From: ryan at hack.net (Ryan Brooks) Date: Thu, 19 Sep 2013 14:40:15 -0500 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523B531F.7090906@hack.net> Sounds like a great plan. You could do it for Netflix, Hulu, amazon, Walmart, etc. Get a piece of the action. Am I talking to Verizon? On 9/19/13 1:46 PM, Warren Bailey wrote: > A line, is a line, is a line, is a line. > > There's no difference. Updates are available to all devices on a "download > day", and providers networks are drastically reduced in capacity as a > result. Apple does not cut them checks to serve it up, why should that > traffic be more important than anything else? I'd DSCP updates to best > effort hell and tell Apple I'd like a small share of the revenue they've > gained from all the devices *I* am responsible for updating. They're not > getting these updates OTA often, they actually advocate (shocking, AT&T > wanting to save bandwidth) using your home Wi-Fi to download it. Providers > can handle peaks, but SURGES begin to cause problems quickly. On > narrowband pipes, we actually KILL updates.. They screw us that hard. > From jethro.binks at strath.ac.uk Thu Sep 19 19:41:56 2013 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Thu, 19 Sep 2013 20:41:56 +0100 (BST) Subject: iOS 7 update traffic In-Reply-To: <79A1CA2E-72EE-4396-AEE9-D496514EF81A@consultant.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, <79A1CA2E-72EE-4396-AEE9-D496514EF81A@consultant.com> Message-ID: On Thu, 19 Sep 2013, Cutler James R wrote: > --As a side note, IOS 7 fixes/improves iDevices in multiple areas, > making it a compelling upgrade. That's supposed to be the nature of upgrades. If that's where the matter ended then you'd have no argument. The problem is when it comes to the new bugs that get introduced, and whether they affect features you care about. I'm holding back until next week :) (And after previous bitter experience with over-the-air upgrade, I've downloaded it through iTunes to a desktop and will upgrade it by wire at my leisure). Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From merlyn at geeks.org Thu Sep 19 19:51:40 2013 From: merlyn at geeks.org (Doug McIntyre) Date: Thu, 19 Sep 2013 14:51:40 -0500 Subject: iOS 7 update traffic In-Reply-To: <61F956AA-C5B6-4BBE-8213-67964E818F2D@hopcount.ca> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <61F956AA-C5B6-4BBE-8213-67964E818F2D@hopcount.ca> Message-ID: <20130919195140.GA44021@geeks.org> On Thu, Sep 19, 2013 at 02:42:12PM -0400, Joe Abley wrote: > Given that the code is signed, I'm surprised that iDevices that have already upgraded the hard way don't advertise a "update available" service on local networks. Individual devices don't care where the updates come from, so long as the signatures are good. Going the other way, Apple will have local update caching as part of MDM for iOS 7 when it is fully upgraded and rolled out to support iOS for enterprises. But the big push with BYOD is that employees manage their own iDevices.. From jared at puck.nether.net Thu Sep 19 19:54:48 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Sep 2013 15:54:48 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: I might agree if there were no warning, but this has happened a few times a year for many years. It's a predictable pattern and well known. It will last about a week and taper off. Jared Mauch > On Sep 19, 2013, at 2:52 PM, Warren Bailey wrote: > > It's a dick move to globally enable updates on a single day and tell ISP's to deal with it. From dorian at blackrose.org Thu Sep 19 18:41:26 2013 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 19 Sep 2013 14:41:26 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <20130919184126.GC32378@blackrose.org> On Thu, Sep 19, 2013 at 06:52:51PM +0000, Warren Bailey wrote: > My.. Our.. Users expect one thing.. > > Internet. Isn't the ability to download something that they want part of the Internet thing that users expect from their service providers? -dorian From hermann at gmail.com Thu Sep 19 19:55:31 2013 From: hermann at gmail.com (Hermann) Date: Thu, 19 Sep 2013 16:55:31 -0300 Subject: anybody from datashack.net ? Message-ID: Is there anybody from datashack.net here? I'm having a lot of problems with them and they are not responding my emails. Thanks From freimer at freimer.org Thu Sep 19 20:08:03 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 19 Sep 2013 20:08:03 +0000 Subject: iOS 7 update traffic In-Reply-To: <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: I certainly don't want to put words in his mouth, but I thin Warren's problem is that he can't upgrade his pipes. Physics limits the bandwidth available, as I think he is a satellite provider. My argument is that if I'm a satellite user I should be well aware, particularly because this is not a new phenomenon, that there are times when my bandwidth will suck. It is what it is. On 9/19/13 3:06 PM, "Ryan Harden" wrote: >To be honest, I don't see this as a problem at all. Use it as an excuse >to upgrade your pipes, talk Akamai or CDN of choice into putting a cache >on your network, or implement your own caching solution. As operators of >the Internet we should be looking for ways to enable things like this, >not be up in arms at Apple for releasing an update to their phone OS or >making it available in a way that's inconvenient to our oversubscription >policies. > >As a side note, how are some of you not aware of this? This has happened >with every single Apple OS update since the iPhone was released in 2007. >This isn't a new phenomenon. I realize some of you are too cool for >Apple, but paying attention to traffic trends and keeping abreast of how >new software releases might affect your utilization is part of properly >running a network. > >/Ryan > >Ryan Harden >Senior Network Engineer >University of Chicago - AS160 >P: 773-834-5441 > > > > >On Sep 19, 2013, at 1:22 PM, Warren Bailey > wrote: > >> I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's >>sequentially. That way, you do not.. >> >> 1. Murder your last mike packet network, which is your bandwidth >>bottleneck. >> >> 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. >> >> 3. Anger your paying customers who would like to use packet data >>successfully on an ios download day. >> >> These people (Apple) represent themselves as smart guys, but their >>actions reflect otherwise. I bet this would be a larger deal to Nanog >>people if your Internet stopped working as the result of 100% Linux >>adoption. That is very close to what this is.. Tens of millions of >>people trying to update their 13 ios devices at the same time. Who owns >>a single ios device? A household could do 5-10gb worth of updates in a >>single day.. >> >> I personally do not own an ios device, and I see close to 3 gigs worth >>of update traffic at my house. These things are everywhere, and this >>problem will not stop. >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: Mikael Abrahamsson >> Date: 09/19/2013 11:16 AM (GMT-08:00) >> To: Warren Bailey >> Cc: Paul Ferguson ,NANOG >> Subject: Re: iOS 7 update traffic >> >> >> On Thu, 19 Sep 2013, Warren Bailey wrote: >> >>> Why does apple feel it is okay to send every mobile device an update >>>on a single day? >> >> They don't, these are users who actively goes into the software upgrade >> menu and pressing "upgrade". >> >> I believe the nagging won't start for quite some time. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se > From streiner at cluebyfour.org Thu Sep 19 16:14:22 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Sep 2013 12:14:22 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: On Thu, 19 Sep 2013, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think > of a single provider who does not oversubscribe their access platform... > Which leads me to this question : The vast majority of the traffic I saw was served from the Akamai farm at an upstream provider, so the pain that was felt 'on the backbone' was mitigated somewhat by that. jms From jeroen at mompl.net Thu Sep 19 20:11:30 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 19 Sep 2013 13:11:30 -0700 Subject: iOS 7 update traffic In-Reply-To: <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: <523B5A72.7080705@mompl.net> On 09/19/2013 12:06 PM, Ryan Harden wrote: > As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. The difference is there are now a "couple" more million devices out there than there were in 2007. And in 2007 there was just the one phone, now you have tablets and what have you. > This isn't a new phenomenon. I realize some of you are too cool for Apple Lame low ball remark, however I thought it was the opposite, Apple==coolness? Regards, Jeroen -- Earthquake Magnitude: 5.3 Date: 2013-09-19 17:25:09.350 UTC Location: 19km ESE of Ishikawa, Japan Latitude: 37.0716; Longitude: 140.6495 Depth: 22.22 km | e-quake.org From sf at lists.esoteric.ca Thu Sep 19 20:18:13 2013 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 19 Sep 2013 16:18:13 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <523B5C05.2000000@lists.esoteric.ca> +1 If you do not/cannot have an Akamai cache, connect to an IX that does, and make sure you've got the capacity. My own rule of thumb is have 2x the capacity of your average *peak* traffic on an IX. When big events happen, whether it is news, sporting or a major software update, that extra capacity will be sorely needed. At TorIX, most peers traffic jumped by the same percentage that others have bandied about on this thread. One peer jumped almost 100%, but they had the right port speed and thus no issues (at least on the Exchange). Compared to transit in Canada, IX peering is dirt cheap, and pays dividends. -- Stephen On 19/09/2013 3:07 PM, Jared Mauch wrote: > The attitude in this email I have encountered elsewhere. Apple pays for bandwidth, customers pay for access. Not sure why their release strategy is so highly critiqued. Microsoft and others have their own strategies for incremental downloads, caching, etc.. Apple has theirs. > > Seems like most consumers want the update and are actively fetching it vs having older software live forever and not be updated. Overall I see this as a win. > > Jared Mauch > >> On Sep 19, 2013, at 2:11 PM, Warren Bailey wrote: >> >> I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : >> >> Why does apple feel it is okay to send every mobile device an update on a single day? > From wbailey at satelliteintelligencegroup.com Thu Sep 19 20:18:32 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 20:18:32 +0000 Subject: iOS 7 update traffic In-Reply-To: Message-ID: Absolutely correct. Large file updates etc are not an issue for wide band communications networks. If you have 10mbps to your house with a 30ms delay to your first hop.. You're sitting pretty. If you have a 1mbps/512kbps pipe with a built in 750ms latency, things get a little more complicated. Add in the fact that our bandwidth is insanely expensive (link budgets put 1mbps are at about 1MHz *1bits/hz* which costs roughly $3800 a month in sky access ONLY). We have some challenges, and we try (sometimes actually succeed) to get data from point A to point B in an acceptable time frame. The issue is.. When a user begins to EXCEED their general usage things in contention land get pretty hairy. If my 500 remote locations are running on 10MHz worth of capacity (about 10mbps down, 2mbps up) at a 10:1 or 20:1 oversub things get tight sometimes. Imagine an entire user base trying to update their electronic devices on something that feels like 56k. All things on the internet are not created equal, and I can accept that. I can accept that I/we have challenges, but I would figure that those of you who had easier lives would want to share that ease with us who are doing things a little differently. I'm not saying poor us, we need love.. I'm just saying.. I would really appreciate if those of you in the industry who are responsible for these types of scenarios could think about the people who are paying a lot of money, for a very little amount of bandwidth. We don't tier our service by usage cap, but if Apple/Microsoft/whoever increases their update rate we may have to end up looking at something like that. Big files, over a little pipe, with little margin for improvement, is hard. It wouldn't be *THAT* hard to help out those who are trying to make communications available to a much larger customer base than a traditional ISP. Group Hug. //warren On 9/19/13 1:08 PM, "Fred Reimer" wrote: >I certainly don't want to put words in his mouth, but I thin Warren's >problem is that he can't upgrade his pipes. Physics limits the bandwidth >available, as I think he is a satellite provider. My argument is that if >I'm a satellite user I should be well aware, particularly because this is >not a new phenomenon, that there are times when my bandwidth will suck. >It is what it is. > > >On 9/19/13 3:06 PM, "Ryan Harden" wrote: > >>To be honest, I don't see this as a problem at all. Use it as an excuse >>to upgrade your pipes, talk Akamai or CDN of choice into putting a cache >>on your network, or implement your own caching solution. As operators of >>the Internet we should be looking for ways to enable things like this, >>not be up in arms at Apple for releasing an update to their phone OS or >>making it available in a way that's inconvenient to our oversubscription >>policies. >> >>As a side note, how are some of you not aware of this? This has happened >>with every single Apple OS update since the iPhone was released in 2007. >>This isn't a new phenomenon. I realize some of you are too cool for >>Apple, but paying attention to traffic trends and keeping abreast of how >>new software releases might affect your utilization is part of properly >>running a network. >> >>/Ryan >> >>Ryan Harden >>Senior Network Engineer >>University of Chicago - AS160 >>P: 773-834-5441 >> >> >> >> >>On Sep 19, 2013, at 1:22 PM, Warren Bailey >> wrote: >> >>> I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's >>>sequentially. That way, you do not.. >>> >>> 1. Murder your last mike packet network, which is your bandwidth >>>bottleneck. >>> >>> 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. >>> >>> 3. Anger your paying customers who would like to use packet data >>>successfully on an ios download day. >>> >>> These people (Apple) represent themselves as smart guys, but their >>>actions reflect otherwise. I bet this would be a larger deal to Nanog >>>people if your Internet stopped working as the result of 100% Linux >>>adoption. That is very close to what this is.. Tens of millions of >>>people trying to update their 13 ios devices at the same time. Who owns >>>a single ios device? A household could do 5-10gb worth of updates in a >>>single day.. >>> >>> I personally do not own an ios device, and I see close to 3 gigs worth >>>of update traffic at my house. These things are everywhere, and this >>>problem will not stop. >>> >>> >>> Sent from my Mobile Device. >>> >>> >>> -------- Original message -------- >>> From: Mikael Abrahamsson >>> Date: 09/19/2013 11:16 AM (GMT-08:00) >>> To: Warren Bailey >>> Cc: Paul Ferguson ,NANOG >>> Subject: Re: iOS 7 update traffic >>> >>> >>> On Thu, 19 Sep 2013, Warren Bailey wrote: >>> >>>> Why does apple feel it is okay to send every mobile device an update >>>>on a single day? >>> >>> They don't, these are users who actively goes into the software upgrade >>> menu and pressing "upgrade". >>> >>> I believe the nagging won't start for quite some time. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se >> > From sf at lists.esoteric.ca Thu Sep 19 20:19:43 2013 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 19 Sep 2013 16:19:43 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523B5C5F.3050701@lists.esoteric.ca> Microsoft Windows 8.1 is due out in October.. don't be so sure :) -- Stephen On 19/09/2013 3:11 PM, Warren Bailey wrote: > Patch Tuesday is not 1gb per patch. > > On 9/19/13 11:51 AM, "Valdis.Kletnieks at vt.edu" > wrote: > >> On Thu, 19 Sep 2013 18:11:11 -0000, Warren Bailey said: >> >>> Why does apple feel it is okay to send every mobile device an update on >>> a single day? >> >> How is Patch Tuesday any different? > > From james.cutler at consultant.com Thu Sep 19 20:28:54 2013 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 19 Sep 2013 16:28:54 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: On Sep 19, 2013, at 3:10 PM, Fred Reimer wrote: > I was making the wrong assumption that people understood how > the Internet works. Absolutely! Most "people" understand that the internet works by use of a browser and are content with that knowledge. Much like most motor vehicle operators understand accelerator, brake, steering, and gas pump, with no knowledge of thermodynamics, much less physics or traffic laws. James R. Cutler james.cutler at consultant.com From clayton at MNSi.Net Thu Sep 19 20:29:13 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 19 Sep 2013 16:29:13 -0400 Subject: car2.Detroit1.Level3.net In-Reply-To: References: Message-ID: <1379622555_158763@duplo.mnsi.net> We're connected to that router in Southfield. Our circuits bounced a couple of times earlier this afternoon (same time you mention), and now we're one way traffic. At 02:34 PM 19/09/2013, Nolan Rollo wrote: >Does anyone know of an issue involving car2.Detroit1.Level3.net and >its handoffs? We have been experiencing about 25% packet loss this >week which resulted in an outage from 19/Sep/2013 13:52 to 19/Sep/2013 14:01 > >Tracing route to google-public-dns-a.google.com [8.8.8.8] over a >maximum of 30 hops: > > 1 <1 ms <1 ms <1 ms 192.168.0.1 > 2 3 ms 2 ms 2 ms d233-64-65-227.dim.wideopenwest.com > [64.233.227.65] > 3 666 ms 705 ms 530 ms ge-7-43.car2.Detroit1.Level3.net > [4.53.74.109] > 4 * * * Request timed out. > 5 * * * Request timed out. > > >Nolan Rollo >VoIP Engineer >Main: 517.223.3610x114 >Fax: 517.223.4120 >www.kw-corp.com --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From johns at sstar.com Thu Sep 19 20:36:43 2013 From: johns at sstar.com (John Souvestre) Date: Thu, 19 Sep 2013 15:36:43 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <00d701ceb577$f78187c0$e6849740$@sstar.com> Hi Jared. > The attitude in this email I have encountered elsewhere. Apple pays > for bandwidth, customers pay for access. Not sure why their release > strategy is so highly critiqued. Because it impacts other, non-Apple customers. Or, it costs the ISP more (passed through to all customers) to add capacity to handle an infrequent peak load. Question/suggestion: Could Apple perhaps shift their release to a Saturday morning? I would think that this would go a long way to diluting the peak. John ??? John Souvestre - New Orleans LA - (504) 454-0899 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6298 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Sep 19 20:41:45 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Sep 2013 16:41:45 -0400 Subject: iOS 7 update traffic In-Reply-To: Your message of "Thu, 19 Sep 2013 19:18:29 -0000." References: Message-ID: <24869.1379623305@turing-police.cc.vt.edu> On Thu, 19 Sep 2013 19:18:29 -0000, Warren Bailey said: Reversing a few paragraphs to make a point. > We strive to provide a great customer experience, and when "Hardware Maker > X" decides to roll updates .. It can screw us. In this case, can means > absolutely will happen. > I mean, would it be THAT hard to enable a bonjour update server on an > apple router/computer/whatever and serve things up locally from there? > I've had many replies to this email already, and people are talking about > upgrading bandwidth and CDN's So why didn't you? > Things are not created equal amongst internet providers, a transponder > (90mbps ish) runs us close to 160k a month and that's not including gear > costs, teleport, etc. And you pay Apple *how* much to guarantee that they don't do things that upset the business model you consciously chose to use? Oh, you don't pay them? And your users pay *you* to ensure that when they hit 'Download', that magical things happen? And iOS downloads are user pulls, not Apple pushes? Sounds to me like you and your users need to have a chat about what they pay for and what their expectations should be..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu Sep 19 21:00:26 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 21:00:26 +0000 Subject: iOS 7 update traffic In-Reply-To: <24869.1379623305@turing-police.cc.vt.edu> References: , <24869.1379623305@turing-police.cc.vt.edu> Message-ID: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com> I'm willing and open to hear anyone who has successfully had that conversation with their users. When network congestion occurs, we typically see a mass exodus from whatever website was being used to Speedtest.. You know.. Just to make sure the internets are fast. I'm trying to highlight a point that not all of us have studly 1gbps connections to Akamai. Some of us have to move data into orbit and back.. Some of us are not like the rest of you. These types of situations should not happen in general.. We live in the future. This is like sending a bulk fax to every user on a switch, and when the other users get busy signals I somehow need to realign my view of reality. A single Internet point or software update should not cause all of this discussion. You guys are collectively posting hundreds of gbps for basically a single software update, and comparing it to point releases from vendors. Why do I feel like many of you are spoiled with all of this cheap and fast bandwidth? Do you guys not remember your 9600bps modem? Many of you would have suffered heart failure if I sent you a 100mb file only 10 years ago. Keep that in mind.. Not everyone has their Internet coming off the end of an sfp. Sent from my Mobile Device. -------- Original message -------- From: Valdis.Kletnieks at vt.edu Date: 09/19/2013 1:42 PM (GMT-08:00) To: Warren Bailey Cc: Fred Reimer ,Mikael Abrahamsson ,Paul Ferguson ,NANOG Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013 19:18:29 -0000, Warren Bailey said: Reversing a few paragraphs to make a point. > We strive to provide a great customer experience, and when "Hardware Maker > X" decides to roll updates .. It can screw us. In this case, can means > absolutely will happen. > I mean, would it be THAT hard to enable a bonjour update server on an > apple router/computer/whatever and serve things up locally from there? > I've had many replies to this email already, and people are talking about > upgrading bandwidth and CDN's So why didn't you? > Things are not created equal amongst internet providers, a transponder > (90mbps ish) runs us close to 160k a month and that's not including gear > costs, teleport, etc. And you pay Apple *how* much to guarantee that they don't do things that upset the business model you consciously chose to use? Oh, you don't pay them? And your users pay *you* to ensure that when they hit 'Download', that magical things happen? And iOS downloads are user pulls, not Apple pushes? Sounds to me like you and your users need to have a chat about what they pay for and what their expectations should be..... From jared at puck.nether.net Thu Sep 19 21:11:16 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Sep 2013 17:11:16 -0400 Subject: iOS 7 update traffic In-Reply-To: <20130919184126.GC32378@blackrose.org> References: <20130919184126.GC32378@blackrose.org> Message-ID: <807DD0C8-E428-49B0-BFE6-70C4177C3041@puck.nether.net> Dorian, It seems warren may work for a satellite internet provider. (Just guessing). The impact might be different with this type of a link. There isn't a good broadcast caching system for this compared with the way other content is. This may have that type of an impact, but there are likely ways to address this as well. I recall the sky cache and other systems of the day. Jared Mauch > On Sep 19, 2013, at 2:41 PM, Dorian Kim wrote: > >> On Thu, Sep 19, 2013 at 06:52:51PM +0000, Warren Bailey wrote: >> My.. Our.. Users expect one thing.. >> >> Internet. > > Isn't the ability to download something that they want part of the Internet > thing that users expect from their service providers? > > -dorian From freimer at freimer.org Thu Sep 19 21:05:38 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 19 Sep 2013 21:05:38 +0000 Subject: iOS 7 update traffic In-Reply-To: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com> Message-ID: Actually, I started out with a 300 baud acoustic modem. You know, the kind where you take the handset and jam it into two cups? But I digress? From: Warren Bailey > Reply-To: Warren Bailey > Date: Thursday, September 19, 2013 5:00 PM To: Valdis Kletnieks > Cc: Fred Reimer >, Mikael Abrahamsson >, Paul Ferguson >, NANOG > Subject: Re: iOS 7 update traffic I'm willing and open to hear anyone who has successfully had that conversation with their users. When network congestion occurs, we typically see a mass exodus from whatever website was being used to Speedtest.. You know.. Just to make sure the internets are fast. I'm trying to highlight a point that not all of us have studly 1gbps connections to Akamai. Some of us have to move data into orbit and back.. Some of us are not like the rest of you. These types of situations should not happen in general.. We live in the future. This is like sending a bulk fax to every user on a switch, and when the other users get busy signals I somehow need to realign my view of reality. A single Internet point or software update should not cause all of this discussion. You guys are collectively posting hundreds of gbps for basically a single software update, and comparing it to point releases from vendors. Why do I feel like many of you are spoiled with all of this cheap and fast bandwidth? Do you guys not remember your 9600bps modem? Many of you would have suffered heart failure if I sent you a 100mb file only 10 years ago. Keep that in mind.. Not everyone has their Internet coming off the end of an sfp. Sent from my Mobile Device. -------- Original message -------- From: Valdis.Kletnieks at vt.edu Date: 09/19/2013 1:42 PM (GMT-08:00) To: Warren Bailey > Cc: Fred Reimer >,Mikael Abrahamsson >,Paul Ferguson >,NANOG > Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013 19:18:29 -0000, Warren Bailey said: Reversing a few paragraphs to make a point. > We strive to provide a great customer experience, and when "Hardware Maker > X" decides to roll updates .. It can screw us. In this case, can means > absolutely will happen. > I mean, would it be THAT hard to enable a bonjour update server on an > apple router/computer/whatever and serve things up locally from there? > I've had many replies to this email already, and people are talking about > upgrading bandwidth and CDN's So why didn't you? > Things are not created equal amongst internet providers, a transponder > (90mbps ish) runs us close to 160k a month and that's not including gear > costs, teleport, etc. And you pay Apple *how* much to guarantee that they don't do things that upset the business model you consciously chose to use? Oh, you don't pay them? And your users pay *you* to ensure that when they hit 'Download', that magical things happen? And iOS downloads are user pulls, not Apple pushes? Sounds to me like you and your users need to have a chat about what they pay for and what their expectations should be..... From wbailey at satelliteintelligencegroup.com Thu Sep 19 21:29:10 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 21:29:10 +0000 Subject: iOS 7 update traffic In-Reply-To: References: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com>, Message-ID: <59kbbeyfkjqcc7cm7hm1dacu.1379626146123@email.android.com> So you understand things aren't always metro e.. That's what I was trying to say. I still have a coupler.. ;) Sent from my Mobile Device. -------- Original message -------- From: Fred Reimer Date: 09/19/2013 2:14 PM (GMT-08:00) To: Warren Bailey ,Valdis.Kletnieks at vt.edu Cc: Mikael Abrahamsson ,Paul Ferguson ,NANOG Subject: Re: iOS 7 update traffic Actually, I started out with a 300 baud acoustic modem. You know, the kind where you take the handset and jam it into two cups? But I digress? From: Warren Bailey > Reply-To: Warren Bailey > Date: Thursday, September 19, 2013 5:00 PM To: Valdis Kletnieks > Cc: Fred Reimer >, Mikael Abrahamsson >, Paul Ferguson >, NANOG > Subject: Re: iOS 7 update traffic I'm willing and open to hear anyone who has successfully had that conversation with their users. When network congestion occurs, we typically see a mass exodus from whatever website was being used to Speedtest.. You know.. Just to make sure the internets are fast. I'm trying to highlight a point that not all of us have studly 1gbps connections to Akamai. Some of us have to move data into orbit and back.. Some of us are not like the rest of you. These types of situations should not happen in general.. We live in the future. This is like sending a bulk fax to every user on a switch, and when the other users get busy signals I somehow need to realign my view of reality. A single Internet point or software update should not cause all of this discussion. You guys are collectively posting hundreds of gbps for basically a single software update, and comparing it to point releases from vendors. Why do I feel like many of you are spoiled with all of this cheap and fast bandwidth? Do you guys not remember your 9600bps modem? Many of you would have suffered heart failure if I sent you a 100mb file only 10 years ago. Keep that in mind.. Not everyone has their Internet coming off the end of an sfp. Sent from my Mobile Device. -------- Original message -------- From: Valdis.Kletnieks at vt.edu Date: 09/19/2013 1:42 PM (GMT-08:00) To: Warren Bailey > Cc: Fred Reimer >,Mikael Abrahamsson >,Paul Ferguson >,NANOG > Subject: Re: iOS 7 update traffic On Thu, 19 Sep 2013 19:18:29 -0000, Warren Bailey said: Reversing a few paragraphs to make a point. > We strive to provide a great customer experience, and when "Hardware Maker > X" decides to roll updates .. It can screw us. In this case, can means > absolutely will happen. > I mean, would it be THAT hard to enable a bonjour update server on an > apple router/computer/whatever and serve things up locally from there? > I've had many replies to this email already, and people are talking about > upgrading bandwidth and CDN's So why didn't you? > Things are not created equal amongst internet providers, a transponder > (90mbps ish) runs us close to 160k a month and that's not including gear > costs, teleport, etc. And you pay Apple *how* much to guarantee that they don't do things that upset the business model you consciously chose to use? Oh, you don't pay them? And your users pay *you* to ensure that when they hit 'Download', that magical things happen? And iOS downloads are user pulls, not Apple pushes? Sounds to me like you and your users need to have a chat about what they pay for and what their expectations should be..... From hardenrm at uchicago.edu Thu Sep 19 21:31:39 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Thu, 19 Sep 2013 21:31:39 +0000 Subject: iOS 7 update traffic In-Reply-To: <523B5A72.7080705@mompl.net> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net> Message-ID: <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: > On 09/19/2013 12:06 PM, Ryan Harden wrote: >> As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. > > The difference is there are now a "couple" more million devices out there than there were in 2007. And in 2007 there was just the one phone, now you have tablets and what have you. The effect has been relatively the same regardless of how many iDevices there are. Network Operators have seen spikes during Apple OS releases since they started. The only leeway I'll give you is that the original iPhone only supported 802.11b. With .11n and someday .11ac, the ability for these devices to consume data at a faster rate is also increasing. > >> This isn't a new phenomenon. I realize some of you are too cool for Apple > > Lame low ball remark, however I thought it was the opposite, Apple==coolness? This was in no way meant to be a lowball remark. But it doesn't take much searching to find people exclaiming how they have zero Apple devices or how they don't pay attention to Apple's "iJunk". I assumed (probably mistakenly) that the lack of knowing this is going to happen roughly 2-3 times a year was due to being 'too cool' to keep up with the stuff Apple puts out. > > Regards, > Jeroen > > -- > Earthquake Magnitude: 5.3 > Date: 2013-09-19 17:25:09.350 UTC > Location: 19km ESE of Ishikawa, Japan > Latitude: 37.0716; Longitude: 140.6495 > Depth: 22.22 km | e-quake.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james at towardex.com Thu Sep 19 21:50:19 2013 From: james at towardex.com (james at towardex.com) Date: Thu, 19 Sep 2013 17:50:19 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: <06b301ceb582$3c41e350$b4c5a9f0$@towardex.com> On Sep 19, 2013, at 14:11, Warren Bailey wrote: > I don't see how operators could tolerate this, honestly. I can't think of a single provider who does not oversubscribe their access platform... Which leads me to this question : Over-subscription is a business decision that every network has to make, it's a fact of life for any operator. When you are oversubscribing, you also need to take into consideration on how much you're getting yourself overleveraged in such a configuration for sudden events like this. Oversubscription is a routine process in capacity planning, which is not something you just set it and forget it, then get pissed off at Apple or any other content provider during a sudden upsurge of traffic. > Why does apple feel it is okay to send every mobile device an update on a single day? Your customers/consumers have purchased a product (internet access) from you based on what you've offered. Whether you've oversubscribed or undersubscribed your network in delivering that service is your problem as a network operator, and your problem to deal with. Why should Apple care? Let's turn this question around: why should your customers think it's ok for network operators to irresponsibly increase their profit margins through egregious over-subscriptions and idiotic capacity planning? How is it Apple, content provider or your consumer's problem that your network can't deliver the bits at times when it needs to? As a network providing service, it's your problem to deal with capacity issues -- you've sold a product with specified speed levels to your subscribers, and you've made a bet on oversubscribing. Suddenly the subscriber wants to use what he previously paid for and now it's a problem? > Never mind the fact that we are we ones on the last mile responsible for getting it to their customers, 1gb per sub is pretty serious.. Why are they not caching at their head ends, dslams, etc? Apple delivers their content through Akamai. As a last mile provider responsible for delivering content to your customers, you should check: http://www.akamai.com/html/partners/network_program.html james From jared at puck.nether.net Thu Sep 19 22:08:36 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Sep 2013 18:08:36 -0400 Subject: iOS 7 update traffic In-Reply-To: <00d701ceb577$f78187c0$e6849740$@sstar.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> Message-ID: <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> On Sep 19, 2013, at 4:36 PM, "John Souvestre" wrote: > Hi Jared. > >> The attitude in this email I have encountered elsewhere. Apple pays >> for bandwidth, customers pay for access. Not sure why their release >> strategy is so highly critiqued. > > Because it impacts other, non-Apple customers. Or, it costs the ISP more > (passed through to all customers) to add capacity to handle an infrequent peak > load. > > Question/suggestion: Could Apple perhaps shift their release to a Saturday > morning? I would think that this would go a long way to diluting the peak. > > John > > John Souvestre - New Orleans LA - (504) 454-0899 I think there's a lot that could be done when looking at how to shift this. I've seen one other carrier privately talk to me about the impact and possible impacts to their network. Most of these are folks (along with warren) who are worried about their RF budgets and these event traffic, or even just the nightly traffic peaks. I have advised some in the past to put up caches, but the content owners also make it difficult to do this. Apple sets very short expire values, and you end up with lots of "bad" settings. Apple devices don't honor DHCP option 252 either. This means you're stuck with a transparent proxy, (lets just say squid) putting itself in all tcp/80 traffic, or worse with lots of settings like: reload-into-ims override-expire etc.. This can solve some problems for those who have a 20-50Mb/s link to the internet and 50-100 customers each getting 1Mb/s+ on their CPE. The results I've always seen are you need to find the strategic location to deploy these caches, capabilities or expand your network bandwidth, etc.. Based on all the recent people asking for a fast link in "X" location recently, I'm hoping there will be some better match-making happening soon. - Jared From jcurran at arin.net Thu Sep 19 22:15:12 2013 From: jcurran at arin.net (John Curran) Date: Thu, 19 Sep 2013 22:15:12 +0000 Subject: Important - Register for NANOG 59 _by 3 October_ to Vote in the NRO NC Election Message-ID: <8814818E-EB9C-4859-A5EB-4B874BC30B03@arin.net> NANOGers - Please note that NANOG 59 attendees will be eligible to vote online in the 2013 Number Resource Organization (NRO) Number Council election as long as they have registered for the meeting by 3 October. NANOG 59 or ARIN 32 attendees that have not registered for their meeting by this deadline will not be eligible to vote. Voting for the NRO NC Election occurs from 7-20 October and the winner will be announced before 27 October 2013. The 2013 NRO NC candidates are: Devon Gayle, National Water Commission of Jamaica Jason Schiller, Google You can view candidate's questionnaire responses at: http://teamarin.net/2013-elections/ You can learn more about the NRO NC at: https://www.arin.net/participate/elections/nronumbercouncil.html Thanks! /John John Curran President and CEO ARIN From wbailey at satelliteintelligencegroup.com Thu Sep 19 22:29:28 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 19 Sep 2013 22:29:28 +0000 Subject: iOS 7 update traffic In-Reply-To: <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net>, <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: Your software updates (you meaning a user of the Internet) should not affect my experience. I'm not advocating we go back to 5.25 floppies and never look back. I'm asking.. Is there a way for a COMPUTER and PHONE manufacturer to distribute their software without destroying most last mile connectivity? Who else has had traffic surges like this? And who else has a Nanog strike team coming in screaming buy more bandwidth? ;) Sent from my Mobile Device. -------- Original message -------- From: Ryan Harden Date: 09/19/2013 3:04 PM (GMT-08:00) To: Jeroen van Aart Cc: "" Subject: Re: iOS 7 update traffic On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: > On 09/19/2013 12:06 PM, Ryan Harden wrote: >> As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. > > The difference is there are now a "couple" more million devices out there than there were in 2007. And in 2007 there was just the one phone, now you have tablets and what have you. The effect has been relatively the same regardless of how many iDevices there are. Network Operators have seen spikes during Apple OS releases since they started. The only leeway I'll give you is that the original iPhone only supported 802.11b. With .11n and someday .11ac, the ability for these devices to consume data at a faster rate is also increasing. > >> This isn't a new phenomenon. I realize some of you are too cool for Apple > > Lame low ball remark, however I thought it was the opposite, Apple==coolness? This was in no way meant to be a lowball remark. But it doesn't take much searching to find people exclaiming how they have zero Apple devices or how they don't pay attention to Apple's "iJunk". I assumed (probably mistakenly) that the lack of knowing this is going to happen roughly 2-3 times a year was due to being 'too cool' to keep up with the stuff Apple puts out. > > Regards, > Jeroen > > -- > Earthquake Magnitude: 5.3 > Date: 2013-09-19 17:25:09.350 UTC > Location: 19km ESE of Ishikawa, Japan > Latitude: 37.0716; Longitude: 140.6495 > Depth: 22.22 km | e-quake.org > From frnkblk at iname.com Thu Sep 19 22:34:29 2013 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Sep 2013 17:34:29 -0500 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> Message-ID: <002301ceb588$673688d0$35a39a70$@iname.com> Is there an indication or separate list that shows if they've been recycled? Frank -----Original Message----- From: James Cloos [mailto:cloos at jhcloos.com] Sent: Thursday, September 19, 2013 2:26 PM To: nanog Cc: Timothy Metzinger Subject: Re: The block message is 521 DNSRBL: Blocked for abuse >>>>> "TM" == Timothy Metzinger writes: TM> or ARIN publishes a list of IP assignments that can be TM> used by ISPs to provisionally remove them from blocked lists? Arin publishes all new assignments to : List-Help: List-Subscribe: , -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From streiner at cluebyfour.org Thu Sep 19 18:45:44 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Sep 2013 14:45:44 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com> References: , <24869.1379623305@turing-police.cc.vt.edu> <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com> Message-ID: On Thu, 19 Sep 2013, Warren Bailey wrote: > I'm trying to highlight a point that not > all of us have studly 1gbps connections to Akamai. Some of us have to > move data into orbit and back.. Some of us are not like the rest of you. > These types of situations should not happen in general.. We live in the > future. This is like sending a bulk fax to every user on a switch, and > when the other users get busy signals I somehow need to realign my view > of reality. I suspect that Apple and others did not take the latency and bandwidth limitations of satellite Internet access into account when developing their software distribution model - if they took such things into account at all. If I had to guess, they probably used basic DSL, cable modem, or 4G LTE service as their lowest common denominator. I would guess their assumption is that the vast majority of people who own iThings have an equivalent kind of Internet connection at their disposal. I'm not saying that's right or wrong, but I wouldn't be surprised if that's their thought process. I fully understand that it's very difficult and expensive to evolve the orbiting pieces of your network to get more bandwidth. Designing, building, flying, and operating a new bird is obscenely expensive. Higher data rates impose limitations of their own, re: rain fade, etc, plus the CPE might need to be replaced. > A single Internet point or software update should not cause all of this > discussion. You guys are collectively posting hundreds of gbps for > basically a single software update, and comparing it to point releases > from vendors. What happened is not an unprecedented occurrence. I used to work at an ISP, and I remember our customers crushing our pipes during an infamous Victoria's Secret webcast many moons ago. Many websites for major news outlets seized up on 9/11 because they couldn't handle the number of requests that were coming in. Joe Schmoe's website blows up because he was featured in an article on Slashdot. That was before the days when geographically dispersed content distribution became commonplace and websites weren't nearly as content-heavy as they are today. > Why do I feel like many of you are spoiled with all of this cheap and > fast bandwidth? Do you guys not remember your 9600bps modem? I won't disagree (happy with my fios service, other than the complete inability to get a straight answer from anyone in charge re: when IPv6 will be available in my area but that's a topic for another thread), and yes, I do remember 9600 bps modems. I started at 1200 bps, and my first reaction when I got a 2400 bps modem was 'Holy crap is this fast!' ;) For some reason, I recall the jump from 2400 to 14400 'feeling' somewhat less awe-inspiring. > Many of you would have suffered heart failure if I sent you a 100mb > file only 10 years ago. Keep that in mind.. Not everyone has their > Internet coming off the end of an sfp. I didn't have a hard drive with enough space to store 100 MB of anything at that point ;) jms From joelja at bogus.com Thu Sep 19 22:49:07 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 19 Sep 2013 15:49:07 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net>, <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: <523B7F63.9020206@bogus.com> On 9/19/13 3:29 PM, Warren Bailey wrote: > Your software updates (you meaning a user of the Internet) should not affect my experience. I'm not advocating we go back to 5.25 floppies and never look back. I'm asking.. > > Is there a way for a COMPUTER and PHONE manufacturer to distribute their software without destroying most last mile connectivity? > > Who else has had traffic surges like this? Flash traffic occurs, sometimes people fly planes into things, sometimes nuclear reactors melt down, earthquakes or hurricanes occur or cables are segmented due to underwater landslides. and what infrastructure that is left shifts abruptly from terrestrial to sattelite or gets droppped on the floor. the best you can ask for on an instantanious basis is graceful degredation under load. this happens to not be weather.so maybe you can do something about it. but ultimately a certain number of bytes have to be transfered and given the architecture, the flash was driven by the consumer and not by software automation, if we want the later to control it consumer choice has to be taken out of the loop, which may or may not be palatable. > And who else has a Nanog strike team coming in screaming buy more bandwidth? ;) > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Ryan Harden > Date: 09/19/2013 3:04 PM (GMT-08:00) > To: Jeroen van Aart > Cc: "" > Subject: Re: iOS 7 update traffic > > > > On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: > >> On 09/19/2013 12:06 PM, Ryan Harden wrote: >>> As a side note, how are some of you not aware of this? This has happened with every single Apple OS update since the iPhone was released in 2007. >> >> The difference is there are now a "couple" more million devices out there than there were in 2007. And in 2007 there was just the one phone, now you have tablets and what have you. > > The effect has been relatively the same regardless of how many iDevices there are. Network Operators have seen spikes during Apple OS releases since they started. The only leeway I'll give you is that the original iPhone only supported 802.11b. With .11n and someday .11ac, the ability for these devices to consume data at a faster rate is also increasing. > >> >>> This isn't a new phenomenon. I realize some of you are too cool for Apple >> >> Lame low ball remark, however I thought it was the opposite, Apple==coolness? > > This was in no way meant to be a lowball remark. But it doesn't take much searching to find people exclaiming how they have zero Apple devices or how they don't pay attention to Apple's "iJunk". I assumed (probably mistakenly) that the lack of knowing this is going to happen roughly 2-3 times a year was due to being 'too cool' to keep up with the stuff Apple puts out. > >> >> Regards, >> Jeroen >> >> -- >> Earthquake Magnitude: 5.3 >> Date: 2013-09-19 17:25:09.350 UTC >> Location: 19km ESE of Ishikawa, Japan >> Latitude: 37.0716; Longitude: 140.6495 >> Depth: 22.22 km | e-quake.org >> > > From alvarezp at alvarezp.ods.org Thu Sep 19 22:55:15 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Thu, 19 Sep 2013 15:55:15 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net>, <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: <523B80D3.70504@alvarezp.ods.org> Again, as others have said: complain to the ISP that most probably oversubscribed their links. On 19/09/13 15:29, Warren Bailey wrote: > Your software updates (you meaning a user of the Internet) should not affect my experience. I'm not advocating we go back to 5.25 floppies and never look back. I'm asking.. > > Is there a way for a COMPUTER and PHONE manufacturer to distribute their software without destroying most last mile connectivity? > > Who else has had traffic surges like this? > And who else has a Nanog strike team coming in screaming buy more bandwidth? ;) From brandon.galbraith at gmail.com Thu Sep 19 22:57:35 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 19 Sep 2013 17:57:35 -0500 Subject: iOS 7 update traffic In-Reply-To: <523B7F63.9020206@bogus.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net> <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> <523B7F63.9020206@bogus.com> Message-ID: 1) Rate limit the software update download ("Us") 2) Have device OS download the update in the background, and be resilient to failures with retries ("Manufacturer") 3) Don't present the update notification to the user until the update blob is already cached on the device ("Manufacturer") Only in a perfect world though. On Thu, Sep 19, 2013 at 5:49 PM, joel jaeggli wrote: > On 9/19/13 3:29 PM, Warren Bailey wrote: > > Your software updates (you meaning a user of the Internet) should not > affect my experience. I'm not advocating we go back to 5.25 floppies and > never look back. I'm asking.. > > > > Is there a way for a COMPUTER and PHONE manufacturer to distribute their > software without destroying most last mile connectivity? > > > > Who else has had traffic surges like this? > > Flash traffic occurs, sometimes people fly planes into things, sometimes > nuclear reactors melt down, earthquakes or hurricanes occur or cables > are segmented due to underwater landslides. and what infrastructure that > is left shifts abruptly from terrestrial to sattelite or gets droppped > on the floor. the best you can ask for on an instantanious basis is > graceful degredation under load. > > this happens to not be weather.so maybe you can do something about it. > but ultimately a certain number of bytes have to be transfered and given > the architecture, the flash was driven by the consumer and not by > software automation, if we want the later to control it consumer choice > has to be taken out of the loop, which may or may not be palatable. > > > And who else has a Nanog strike team coming in screaming buy more > bandwidth? ;) > > > > > > Sent from my Mobile Device. > > > > > > -------- Original message -------- > > From: Ryan Harden > > Date: 09/19/2013 3:04 PM (GMT-08:00) > > To: Jeroen van Aart > > Cc: "" > > Subject: Re: iOS 7 update traffic > > > > > > > > On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: > > > >> On 09/19/2013 12:06 PM, Ryan Harden wrote: > >>> As a side note, how are some of you not aware of this? This has > happened with every single Apple OS update since the iPhone was released in > 2007. > >> > >> The difference is there are now a "couple" more million devices out > there than there were in 2007. And in 2007 there was just the one phone, > now you have tablets and what have you. > > > > The effect has been relatively the same regardless of how many iDevices > there are. Network Operators have seen spikes during Apple OS releases > since they started. The only leeway I'll give you is that the original > iPhone only supported 802.11b. With .11n and someday .11ac, the ability for > these devices to consume data at a faster rate is also increasing. > > > >> > >>> This isn't a new phenomenon. I realize some of you are too cool for > Apple > >> > >> Lame low ball remark, however I thought it was the opposite, > Apple==coolness? > > > > This was in no way meant to be a lowball remark. But it doesn't take > much searching to find people exclaiming how they have zero Apple devices > or how they don't pay attention to Apple's "iJunk". I assumed (probably > mistakenly) that the lack of knowing this is going to happen roughly 2-3 > times a year was due to being 'too cool' to keep up with the stuff Apple > puts out. > > > >> > >> Regards, > >> Jeroen > >> > >> -- > >> Earthquake Magnitude: 5.3 > >> Date: 2013-09-19 17:25:09.350 UTC > >> Location: 19km ESE of Ishikawa, Japan > >> Latitude: 37.0716; Longitude: 140.6495 > >> Depth: 22.22 km | e-quake.org > >> > > > > > > > From jabley at hopcount.ca Thu Sep 19 22:58:02 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 19 Sep 2013 18:58:02 -0400 Subject: iOS 7 update traffic In-Reply-To: <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> Message-ID: On 2013-09-19, at 18:08, Jared Mauch wrote: > I think there's a lot that could be done when looking at how to shift this. But likely not before the first iOS 7 patch release. http://appleinsider.com/articles/13/09/19/apples-control-center-used-to-bypass-ios-7-passcode-lock Joe From joelja at bogus.com Thu Sep 19 23:08:02 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 19 Sep 2013 16:08:02 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net> <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> <523B7F63.9020206@bogus.com> Message-ID: <523B83D2.4070909@bogus.com> On 9/19/13 3:57 PM, Brandon Galbraith wrote: > 1) Rate limit the software update download ("Us") > > 2) Have device OS download the update in the background, and be > resilient to failures with retries ("Manufacturer") > > 3) Don't present the update notification to the user until the update > blob is already cached on the device ("Manufacturer") Even in this case, this comes down to a whole bunch of consumers going to the general menu selecting software update and selecting check for software update. So insuring that consumers don't have the opportunity to retrieve something that they want when they want it would be part of a solution. some large fraction of the devices will be soaking this up over the next couple days rather than yesterday some won't get it for quite some time. Software distribution can handle this, they could have been pushing unreleased software blobs for a couple weeks for example, as some steam game launches do for example. But, if you support near instantanious gratification then, when somebody asks for something, then you start fulfilling it. > Only in a perfect world though. > > > On Thu, Sep 19, 2013 at 5:49 PM, joel jaeggli > wrote: > > On 9/19/13 3:29 PM, Warren Bailey wrote: > > Your software updates (you meaning a user of the Internet) should > not affect my experience. I'm not advocating we go back to 5.25 > floppies and never look back. I'm asking.. > > > > Is there a way for a COMPUTER and PHONE manufacturer to distribute > their software without destroying most last mile connectivity? > > > > Who else has had traffic surges like this? > > Flash traffic occurs, sometimes people fly planes into things, sometimes > nuclear reactors melt down, earthquakes or hurricanes occur or cables > are segmented due to underwater landslides. and what infrastructure that > is left shifts abruptly from terrestrial to sattelite or gets droppped > on the floor. the best you can ask for on an instantanious basis is > graceful degredation under load. > > this happens to not be weather.so maybe you can do something about it. > but ultimately a certain number of bytes have to be transfered and given > the architecture, the flash was driven by the consumer and not by > software automation, if we want the later to control it consumer choice > has to be taken out of the loop, which may or may not be palatable. > > > And who else has a Nanog strike team coming in screaming buy more > bandwidth? ;) > > > > > > Sent from my Mobile Device. > > > > > > -------- Original message -------- > > From: Ryan Harden > > > Date: 09/19/2013 3:04 PM (GMT-08:00) > > To: Jeroen van Aart > > > Cc: ">" > > > Subject: Re: iOS 7 update traffic > > > > > > > > On Sep 19, 2013, at 3:11 PM, Jeroen van Aart > wrote: > > > >> On 09/19/2013 12:06 PM, Ryan Harden wrote: > >>> As a side note, how are some of you not aware of this? This has > happened with every single Apple OS update since the iPhone was > released in 2007. > >> > >> The difference is there are now a "couple" more million devices > out there than there were in 2007. And in 2007 there was just the > one phone, now you have tablets and what have you. > > > > The effect has been relatively the same regardless of how many > iDevices there are. Network Operators have seen spikes during Apple > OS releases since they started. The only leeway I'll give you is > that the original iPhone only supported 802.11b. With .11n and > someday .11ac, the ability for these devices to consume data at a > faster rate is also increasing. > > > >> > >>> This isn't a new phenomenon. I realize some of you are too cool > for Apple > >> > >> Lame low ball remark, however I thought it was the opposite, > Apple==coolness? > > > > This was in no way meant to be a lowball remark. But it doesn't > take much searching to find people exclaiming how they have zero > Apple devices or how they don't pay attention to Apple's "iJunk". I > assumed (probably mistakenly) that the lack of knowing this is going > to happen roughly 2-3 times a year was due to being 'too cool' to > keep up with the stuff Apple puts out. > > > >> > >> Regards, > >> Jeroen > >> > >> -- > >> Earthquake Magnitude: 5.3 > >> Date: 2013-09-19 17:25:09.350 UTC > >> Location: 19km ESE of Ishikawa, Japan > >> Latitude: 37.0716; Longitude: 140.6495 > >> Depth: 22.22 km | e-quake.org > >> > > > > > > > From marka at isc.org Thu Sep 19 23:13:39 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 20 Sep 2013 09:13:39 +1000 Subject: iOS 7 update traffic In-Reply-To: Your message of "Thu, 19 Sep 2013 18:08:36 -0400." <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> Message-ID: <20130919231339.D3A1673F854@rock.dv.isc.org> In message <64245AC1-BC00-4928-B2F7-F259E8632655 at puck.nether.net>, Jared Mauch writes: > > On Sep 19, 2013, at 4:36 PM, "John Souvestre" wrote: > > > Hi Jared. > > > >> The attitude in this email I have encountered elsewhere. Apple pays > >> for bandwidth, customers pay for access. Not sure why their release > >> strategy is so highly critiqued. > > > > Because it impacts other, non-Apple customers. Or, it costs the ISP > more > > (passed through to all customers) to add capacity to handle an > infrequent peak > > load. > > > > Question/suggestion: Could Apple perhaps shift their release to a > Saturday > > morning? I would think that this would go a long way to diluting the > peak. > > > > John > > > > John Souvestre - New Orleans LA - (504) 454-0899 > > > I think there's a lot that could be done when looking at how to shift > this. > > I've seen one other carrier privately talk to me about the impact and > possible impacts to their network. Most of these are folks (along with > warren) who are worried about their RF budgets and these event traffic, > or even just the nightly traffic peaks. > > I have advised some in the past to put up caches, but the content owners > also make it difficult to do this. Apple sets very short expire values, > and you end up with lots of "bad" settings. Apple devices don't honor > DHCP option 252 either. Oh you mean that option that never made it past a internet-draft that expired 13 years ago[1] and is in the private range[2] to boot. If you want proxy discovery to work on all devices complete the process of getting a code point allocated then get the OS vendors to query for it. 252 is fine for experimenting / proof of concept but it really is the wrong value for long term use. Mark [1] http://tools.ietf.org/html/draft-ietf-wrec-wpad-01 [2] http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml > This means you're stuck with a transparent proxy, (lets just say squid) > putting itself in all tcp/80 traffic, or worse with lots of settings > like: reload-into-ims override-expire etc.. > > This can solve some problems for those who have a 20-50Mb/s link to the > internet and 50-100 customers each getting 1Mb/s+ on their CPE. > > The results I've always seen are you need to find the strategic location > to deploy these caches, capabilities or expand your network bandwidth, > etc.. > > Based on all the recent people asking for a fast link in "X" location > recently, I'm hoping there will be some better match-making happening > soon. > > - Jared -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nwolff at oar.net Thu Sep 19 21:32:09 2013 From: nwolff at oar.net (Nick Wolff) Date: Thu, 19 Sep 2013 21:32:09 +0000 Subject: iOS 7 update traffic In-Reply-To: <523B5C05.2000000@lists.esoteric.ca> Message-ID: In my experience just having a Akamai cache wasn't enough to handle this. Our local cache was doing 15 out of 20gbps usage and seemed pegged at that. One of our customers had a local Akamai cache on there end crash and we were mostly filling a 10gbps pipe to a datacenter with limelight cdn's at it. This was just the CDN spike and not the one's over our peering and commodity traffic. Yes apple might not of forced people to upgrade exactly at the time they released but they can at least do an enforced role out like google does(on much smaller updates of course). Our core handled it all with not much more then amazement from our staff but a majority of customers pipes were pegged at whatever bandwidth they were paying for(I'm talking between 200mbps-5gbps with a few as big as 10gbps customer connections) --Nick On 9/19/13 4:18 PM, "Stephen Fulton" wrote: >+1 > >If you do not/cannot have an Akamai cache, connect to an IX that does, >and make sure you've got the capacity. My own rule of thumb is have 2x >the capacity of your average *peak* traffic on an IX. When big events >happen, whether it is news, sporting or a major software update, that >extra capacity will be sorely needed. > >At TorIX, most peers traffic jumped by the same percentage that others >have bandied about on this thread. One peer jumped almost 100%, but >they had the right port speed and thus no issues (at least on the >Exchange). > >Compared to transit in Canada, IX peering is dirt cheap, and pays >dividends. > >-- Stephen > >On 19/09/2013 3:07 PM, Jared Mauch wrote: >> The attitude in this email I have encountered elsewhere. Apple pays >>for bandwidth, customers pay for access. Not sure why their release >>strategy is so highly critiqued. Microsoft and others have their own >>strategies for incremental downloads, caching, etc.. Apple has theirs. >> >> Seems like most consumers want the update and are actively fetching it >>vs having older software live forever and not be updated. Overall I see >>this as a win. >> >> Jared Mauch >> >>> On Sep 19, 2013, at 2:11 PM, Warren Bailey >>> wrote: >>> >>> I don't see how operators could tolerate this, honestly. I can't think >>>of a single provider who does not oversubscribe their access >>>platform... Which leads me to this question : >>> >>> Why does apple feel it is okay to send every mobile device an update >>>on a single day? >> > From Valdis.Kletnieks at vt.edu Fri Sep 20 00:42:02 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Sep 2013 20:42:02 -0400 Subject: iOS 7 update traffic In-Reply-To: Your message of "Thu, 19 Sep 2013 22:29:28 -0000." References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, , <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net>, <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> Message-ID: <40750.1379637722@turing-police.cc.vt.edu> On Thu, 19 Sep 2013 22:29:28 -0000, Warren Bailey said: > Who else has had traffic surges like this? Most are reporting a doubling or so of bandwidth, for an event that you had a week's advance notice. April 16 a few years ago, we had a much higher bandwidth impact on much shorter notice. Oh, and a protip: Trying to remediate a slashdotting is hard. Trying to remediate one while you're still under lockdown due to the cause of the slashdotting is even harder. But our efforts were nowhere near as valiant as the guys who were boots on the ground in Haiti after the quake, or the guys who kept 60 Hudson online. In the greater scheme of things, it was *just* a software release. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From kmedcalf at dessus.com Fri Sep 20 00:54:58 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 19 Sep 2013 18:54:58 -0600 Subject: iOS 7 update traffic In-Reply-To: Message-ID: <6698cb2ede46c14a83d67742ec756a65@mail.dessus.com> Why do you sell services to customers using iThings if you are incapable of supporting them? Are you sure that it is not you yourself who have used to much "bait and switch" selling a service you are unable to provide? What actions do you take to discourage iThings on your network? > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Thursday, 19 September, 2013 16:29 > To: Ryan Harden; Jeroen van Aart > Cc: > Subject: Re: iOS 7 update traffic > > Your software updates (you meaning a user of the Internet) should not > affect my experience. I'm not advocating we go back to 5.25 floppies and > never look back. I'm asking.. > > Is there a way for a COMPUTER and PHONE manufacturer to distribute their > software without destroying most last mile connectivity? > > Who else has had traffic surges like this? > And who else has a Nanog strike team coming in screaming buy more > bandwidth? ;) > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Ryan Harden > Date: 09/19/2013 3:04 PM (GMT-08:00) > To: Jeroen van Aart > Cc: "" > Subject: Re: iOS 7 update traffic > > > > On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: > > > On 09/19/2013 12:06 PM, Ryan Harden wrote: > >> As a side note, how are some of you not aware of this? This has > happened with every single Apple OS update since the iPhone was released > in 2007. > > > > The difference is there are now a "couple" more million devices out > there than there were in 2007. And in 2007 there was just the one phone, > now you have tablets and what have you. > > The effect has been relatively the same regardless of how many iDevices > there are. Network Operators have seen spikes during Apple OS releases > since they started. The only leeway I'll give you is that the original > iPhone only supported 802.11b. With .11n and someday .11ac, the ability > for these devices to consume data at a faster rate is also increasing. > > > > >> This isn't a new phenomenon. I realize some of you are too cool for > Apple > > > > Lame low ball remark, however I thought it was the opposite, > Apple==coolness? > > This was in no way meant to be a lowball remark. But it doesn't take > much searching to find people exclaiming how they have zero Apple > devices or how they don't pay attention to Apple's "iJunk". I assumed > (probably mistakenly) that the lack of knowing this is going to happen > roughly 2-3 times a year was due to being 'too cool' to keep up with the > stuff Apple puts out. > > > > > Regards, > > Jeroen > > > > -- > > Earthquake Magnitude: 5.3 > > Date: 2013-09-19 17:25:09.350 UTC > > Location: 19km ESE of Ishikawa, Japan > > Latitude: 37.0716; Longitude: 140.6495 > > Depth: 22.22 km | e-quake.org > > From mohta at necom830.hpcl.titech.ac.jp Fri Sep 20 00:55:13 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 20 Sep 2013 09:55:13 +0900 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <523B9CF1.2050301@necom830.hpcl.titech.ac.jp> TR Shaw wrote: > Major update & provides many of 5S functionality to the 5, 4S, & 4 Different versions could have been updated on different days, at least. Masataka Ohta From joelja at bogus.com Fri Sep 20 01:08:06 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 19 Sep 2013 18:08:06 -0700 Subject: iOS 7 update traffic In-Reply-To: <6698cb2ede46c14a83d67742ec756a65@mail.dessus.com> References: <6698cb2ede46c14a83d67742ec756a65@mail.dessus.com> Message-ID: <523B9FF6.30803@bogus.com> On 9/19/13 5:54 PM, Keith Medcalf wrote: > > Why do you sell services to customers using iThings if you are > incapable of supporting them? Are you sure that it is not you > yourself who have used to much "bait and switch" selling a service > you are unable to provide? What actions do you take to discourage > iThings on your network? Not all business models are able sustain some kinds of demands. Marketplaces aren't so elsatic that sudden changes in demand can be immediately addressed. Given enough time and incentive this addressed, at the margins however you may get hosed anyway. Physics is a stern taskmaster. >> -----Original Message----- From: Warren Bailey >> [mailto:wbailey at satelliteintelligencegroup.com] Sent: Thursday, 19 >> September, 2013 16:29 To: Ryan Harden; Jeroen van Aart Cc: >> Subject: Re: iOS 7 update traffic >> >> Your software updates (you meaning a user of the Internet) should >> not affect my experience. I'm not advocating we go back to 5.25 >> floppies and never look back. I'm asking.. >> >> Is there a way for a COMPUTER and PHONE manufacturer to distribute >> their software without destroying most last mile connectivity? >> >> Who else has had traffic surges like this? And who else has a Nanog >> strike team coming in screaming buy more bandwidth? ;) >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- From: Ryan Harden >> Date: 09/19/2013 3:04 PM (GMT-08:00) To: >> Jeroen van Aart Cc: "" >> Subject: Re: iOS 7 update traffic >> >> >> >> On Sep 19, 2013, at 3:11 PM, Jeroen van Aart >> wrote: >> >>> On 09/19/2013 12:06 PM, Ryan Harden wrote: >>>> As a side note, how are some of you not aware of this? This >>>> has >> happened with every single Apple OS update since the iPhone was >> released in 2007. >>> >>> The difference is there are now a "couple" more million devices >>> out >> there than there were in 2007. And in 2007 there was just the one >> phone, now you have tablets and what have you. >> >> The effect has been relatively the same regardless of how many >> iDevices there are. Network Operators have seen spikes during Apple >> OS releases since they started. The only leeway I'll give you is >> that the original iPhone only supported 802.11b. With .11n and >> someday .11ac, the ability for these devices to consume data at a >> faster rate is also increasing. >> >>> >>>> This isn't a new phenomenon. I realize some of you are too cool >>>> for >> Apple >>> >>> Lame low ball remark, however I thought it was the opposite, >> Apple==coolness? >> >> This was in no way meant to be a lowball remark. But it doesn't >> take much searching to find people exclaiming how they have zero >> Apple devices or how they don't pay attention to Apple's "iJunk". I >> assumed (probably mistakenly) that the lack of knowing this is >> going to happen roughly 2-3 times a year was due to being 'too >> cool' to keep up with the stuff Apple puts out. >> >>> >>> Regards, Jeroen >>> >>> -- Earthquake Magnitude: 5.3 Date: 2013-09-19 17:25:09.350 UTC >>> Location: 19km ESE of Ishikawa, Japan Latitude: 37.0716; >>> Longitude: 140.6495 Depth: 22.22 km | e-quake.org >>> > > > > > > From LarrySheldon at cox.net Fri Sep 20 01:23:00 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 19 Sep 2013 20:23:00 -0500 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523BA374.3090002@cox.net> On 9/19/2013 7:54 PM, Keith Medcalf wrote: > Why do you sell services to customers using ... if you are > incapable of supporting them? Are you serious? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jeff-kell at utc.edu Fri Sep 20 01:29:28 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 19 Sep 2013 21:29:28 -0400 Subject: iOS 7 update traffic In-Reply-To: <59kbbeyfkjqcc7cm7hm1dacu.1379626146123@email.android.com> References: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com>, <59kbbeyfkjqcc7cm7hm1dacu.1379626146123@email.android.com> Message-ID: <523BA4F8.7030705@utc.edu> On 9/19/2013 5:29 PM, Warren Bailey wrote: > So you understand things aren't always metro e.. That's what I was trying to say. I still have a coupler.. ;) > > -------- Original message -------- > From: Fred Reimer > > Actually, I started out with a 300 baud acoustic modem. You know, the kind where you take the handset and jam it into two cups? But I digress? Bah! That was a take-home convenience. How about the old ASR TeleType with the 110-baud link to get a hardcopy listing? Jeff From bmanning at vacation.karoshi.com Fri Sep 20 01:55:48 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 20 Sep 2013 01:55:48 +0000 Subject: anybody from Amsterdam Internet Exchange (ams-ix) to help? In-Reply-To: References: Message-ID: <20130920015548.GA20233@vacation.karoshi.com.> there is a huge amount of information on the net. have you done any homework? brief summary, an exchange is a shared fate transport where an ISP can exchange traffic with two or more other participants on the exchange. most of the traffic exchange is done via "peering" with the BGP protocol. Bill Norton has written about peering. Bill Woodcock has built on the old EP.NET data and has a fairly comprehensive set at PCH.NET Current discussion is being held in the OpenIX forums. IXPs are even a part fo the next ITU framework. Care to refine your question a bit? /bill On Thu, Sep 19, 2013 at 08:35:18AM +0330, Shahab Vahabzadeh wrote: > Hello Everybody, > Is there anybody from Amsterdam IX here? > I have some questions about concept of IXP. > If anybody else have enough information about IXP's please give me message > off the list. > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From johns at sstar.com Fri Sep 20 04:51:27 2013 From: johns at sstar.com (John Souvestre) Date: Thu, 19 Sep 2013 23:51:27 -0500 Subject: iOS 7 update traffic In-Reply-To: <523BA4F8.7030705@utc.edu> References: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com>, <59kbbeyfkjqcc7cm7hm1dacu.1379626146123@email.android.com> <523BA4F8.7030705@utc.edu> Message-ID: <027801ceb5bd$174446c0$45ccd440$@sstar.com> > Bah! That was a take-home convenience. How about the old ASR TeleType > with the 110-baud link to get a hardcopy listing? Model 15, 45.5 baud. :) John John Souvestre - New Orleans LA - (504) 454-0899 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6298 bytes Desc: not available URL: From LarrySheldon at cox.net Fri Sep 20 04:54:35 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 19 Sep 2013 23:54:35 -0500 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: <523BD50B.9060700@cox.net> Thought occurs to me--anybody have a traffic analysis that shows how much of the "iOS 7 bump" is due to email on NANOG about it? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From tshaw at oitc.com Fri Sep 20 09:33:53 2013 From: tshaw at oitc.com (TR Shaw) Date: Fri, 20 Sep 2013 05:33:53 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <11F730430848354485CBED437DCBDBBF13CE9569@XM-MBX-02-PROD.ad.uchicago.edu> <523B5A72.7080705@mompl.net> <11F730430848354485CBED437DCBDBBF13CEC6A6@XM-MBX-02-PROD.ad.uchicago.edu> <523B7F63.9020206@bogus.com> Message-ID: Just as a note. On Sep 19, 2013, at 6:57 PM, Brandon Galbraith wrote: > 1) Rate limit the software update download ("Us") > > 2) Have device OS download the update in the background, and be resilient > to failures with retries ("Manufacturer") > Apple already does this in the iTunes update the ios device mode. > 3) Don't present the update notification to the user until the update blob > is already cached on the device ("Manufacturer") > Apple also already does this. However, manual checks/updates can be done. When there is so much buzz on the news and given Apple customers zeal a large percentage manually invoke the update. > Only in a perfect world though. > > > On Thu, Sep 19, 2013 at 5:49 PM, joel jaeggli wrote: > >> On 9/19/13 3:29 PM, Warren Bailey wrote: >>> Your software updates (you meaning a user of the Internet) should not >> affect my experience. I'm not advocating we go back to 5.25 floppies and >> never look back. I'm asking.. >>> >>> Is there a way for a COMPUTER and PHONE manufacturer to distribute their >> software without destroying most last mile connectivity? >>> >>> Who else has had traffic surges like this? >> >> Flash traffic occurs, sometimes people fly planes into things, sometimes >> nuclear reactors melt down, earthquakes or hurricanes occur or cables >> are segmented due to underwater landslides. and what infrastructure that >> is left shifts abruptly from terrestrial to sattelite or gets droppped >> on the floor. the best you can ask for on an instantanious basis is >> graceful degredation under load. >> >> this happens to not be weather.so maybe you can do something about it. >> but ultimately a certain number of bytes have to be transfered and given >> the architecture, the flash was driven by the consumer and not by >> software automation, if we want the later to control it consumer choice >> has to be taken out of the loop, which may or may not be palatable. >> >>> And who else has a Nanog strike team coming in screaming buy more >> bandwidth? ;) >>> >>> >>> Sent from my Mobile Device. >>> >>> >>> -------- Original message -------- >>> From: Ryan Harden >>> Date: 09/19/2013 3:04 PM (GMT-08:00) >>> To: Jeroen van Aart >>> Cc: "" >>> Subject: Re: iOS 7 update traffic >>> >>> >>> >>> On Sep 19, 2013, at 3:11 PM, Jeroen van Aart wrote: >>> >>>> On 09/19/2013 12:06 PM, Ryan Harden wrote: >>>>> As a side note, how are some of you not aware of this? This has >> happened with every single Apple OS update since the iPhone was released in >> 2007. >>>> >>>> The difference is there are now a "couple" more million devices out >> there than there were in 2007. And in 2007 there was just the one phone, >> now you have tablets and what have you. >>> >>> The effect has been relatively the same regardless of how many iDevices >> there are. Network Operators have seen spikes during Apple OS releases >> since they started. The only leeway I'll give you is that the original >> iPhone only supported 802.11b. With .11n and someday .11ac, the ability for >> these devices to consume data at a faster rate is also increasing. >>> >>>> >>>>> This isn't a new phenomenon. I realize some of you are too cool for >> Apple >>>> >>>> Lame low ball remark, however I thought it was the opposite, >> Apple==coolness? >>> >>> This was in no way meant to be a lowball remark. But it doesn't take >> much searching to find people exclaiming how they have zero Apple devices >> or how they don't pay attention to Apple's "iJunk". I assumed (probably >> mistakenly) that the lack of knowing this is going to happen roughly 2-3 >> times a year was due to being 'too cool' to keep up with the stuff Apple >> puts out. >>> >>>> >>>> Regards, >>>> Jeroen >>>> >>>> -- >>>> Earthquake Magnitude: 5.3 >>>> Date: 2013-09-19 17:25:09.350 UTC >>>> Location: 19km ESE of Ishikawa, Japan >>>> Latitude: 37.0716; Longitude: 140.6495 >>>> Depth: 22.22 km | e-quake.org >>>> >>> >>> >> >> >> From tom.taylor.stds at gmail.com Fri Sep 20 11:57:03 2013 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Fri, 20 Sep 2013 07:57:03 -0400 Subject: iOS 7 update traffic In-Reply-To: <523BA4F8.7030705@utc.edu> References: <7xrtnwadto0v2yxa3189bhcw.1379624403740@email.android.com>, <59kbbeyfkjqcc7cm7hm1dacu.1379626146123@email.android.com> <523BA4F8.7030705@utc.edu> Message-ID: <523C380F.6090004@gmail.com> On 19/09/2013 9:29 PM, Jeff Kell wrote: > On 9/19/2013 5:29 PM, Warren Bailey wrote: >> So you understand things aren't always metro e.. That's what I was trying to say. I still have a coupler.. ;) >> >> -------- Original message -------- >> From: Fred Reimer >> >> Actually, I started out with a 300 baud acoustic modem. You know, the kind where you take the handset and jam it into two cups? But I digress? > > Bah! That was a take-home convenience. How about the old ASR TeleType > with the 110-baud link to get a hardcopy listing? > > Jeff > > > Ah, distinctly I remember. The ASR shook the whole house when it started typing things out. I was using a government tie line from Ottawa to Toronto, and occasionally the operator would break in to investigate the long call with funny noises. Tom From joquendo at e-fensive.net Fri Sep 20 12:06:34 2013 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 20 Sep 2013 07:06:34 -0500 Subject: anybody from datashack.net ? In-Reply-To: References: Message-ID: <20130920120634.GB17831@e-fensive.net> On Thu, 19 Sep 2013, Hermann wrote: > Is there anybody from datashack.net here? > > I'm having a lot of problems with them and they are not responding my emails. > I have sent out about a half dozen of e-mails to them within the last few weeks as I have seen a huge amount of attacker traffic targeting my VoIP infrastructures (managed) and have yet to see my response. I just dropped their entire blocks and blacklisted them period. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From tron at acm.org Fri Sep 20 12:29:58 2013 From: tron at acm.org (Carlos G Mendioroz) Date: Fri, 20 Sep 2013 09:29:58 -0300 Subject: Contact at spamhaus to ASK for a DROP listing ? Message-ID: <523C3FC6.9050107@acm.org> Hi, I've seen many threads of delisting requests here, and this is NOT one. I happen to be tech contact for an unused allocated block that has been recently hijacked. I have no means to actually route it now, so I guess the best course of action is to list it in DROP. On pourpose. If anyone can help me on that, or provide advise on a better course of action, I'm all ears :) TIA, -- Carlos G Mendioroz From kris at kriskinc.com Fri Sep 20 12:54:51 2013 From: kris at kriskinc.com (Kristian Kielhofner) Date: Fri, 20 Sep 2013 08:54:51 -0400 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <5223A4CE.9090505@ripe.net> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net> <5223A4CE.9090505@ripe.net> Message-ID: I know I'm digging up an old thread here but I've spent some time analyzing some of the significant changes that Apple has made to the Facetime protocol, apparently with a huge focus on IP packet size to avoid fragmentation issues: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html I'm betting they've had HUGE issues with IP+UDP MTU issues over the last three years... On Sun, Sep 1, 2013 at 4:34 PM, Emile Aben wrote: > On 31/08/2013 13:13, Randy Bush wrote: >> could you please test with ipv6? > > This is what I see for various IPv6 payloads (large ICMPv6 echo > requests) from all RIPE Atlas probes that where available at the time to > a single "known good" MTU 1500 destination: > > plen fail% nr_probes > 100 9.64 1266 > 500 9.34 1039 > 1000 9.94 1298 > 1240 9.94 1308 > 1241 11.62 1300 > 1440 12.70 890 > 1441 14.70 1306 > 1460 15.18 1304 > 1461 19.84 1290 > 1462 22.02 1294 > > plen: IPv6 payload length (ie. not including 40byte IPv6 header) > fail%: percentage of probes that didn't get any of the 5 pkts that were > sent. Note that there is a large baseline failure rate in IPv6 on RIPE > Atlas probes [1], which would explain the ~10% failure rate for the > smaller packets. > > I plan to do more analysis and start writing this up on RIPE Labs over > the next few days. > > cheers, > Emile Aben > RIPE NCC > > > [1] > https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong > -- Kristian Kielhofner From tshaw at oitc.com Fri Sep 20 13:01:04 2013 From: tshaw at oitc.com (TR Shaw) Date: Fri, 20 Sep 2013 09:01:04 -0400 Subject: Contact at spamhaus to ASK for a DROP listing ? In-Reply-To: <523C3FC6.9050107@acm.org> References: <523C3FC6.9050107@acm.org> Message-ID: <7C619A65-7112-4063-A957-EEED1EA5DA3B@oitc.com> Forwarded you request to spamhaus Tom On Sep 20, 2013, at 8:29 AM, Carlos G Mendioroz wrote: > Hi, > I've seen many threads of delisting requests here, and this is NOT one. > I happen to be tech contact for an unused allocated block that has been recently hijacked. I have no means to actually route it now, so I guess the best course of action is to list it in DROP. On pourpose. > > If anyone can help me on that, or provide advise on a better course of action, I'm all ears :) > > TIA, > > -- > Carlos G Mendioroz > From ben+nanog at list-subs.com Fri Sep 20 16:57:04 2013 From: ben+nanog at list-subs.com (Ben) Date: Fri, 20 Sep 2013 17:57:04 +0100 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com>, Message-ID: <523C7E60.80002@list-subs.com> > Why does apple feel it is okay to send every mobile device an update on a single day? > (a) That's why god invented the concept of CDNs....to take the stress of the more contended parts of an operators network. ;-) (b) Its not just Apple but any vendor (e.g. Microsloth).... their updates are released to the world at the same time. (c) Your user is paying you to push packets. If that's causing you a problem, you either need to review your commercial structure (i.e. charge people more) or your technical network design. Face the facts, what with everyone jumping on the "cloud" bandwagon, the future is only going to see you pushing more packets, not less ! So if you can't stand the heat, get out of the kitchen (or the xSP industry). ;-) No need for you to bash Apple in this instance. From sfrost at snowman.net Fri Sep 20 17:17:16 2013 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 20 Sep 2013 13:17:16 -0400 Subject: iOS 7 update traffic In-Reply-To: <523C7E60.80002@list-subs.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <523C7E60.80002@list-subs.com> Message-ID: <20130920171716.GH2706@tamriel.snowman.net> * Ben (ben+nanog at list-subs.com) wrote: > No need for you to bash Apple in this instance. What this conversation badly needs is a sub-thread about whatever happened to the technical solutions which would address this issue (eg: mbone). Of course, I know what happened and what the issues are there, but it'd be fun to watch people complain about how Apple should try and do the "right thing" and make multicast work for their updates, 'cause it's the "right" technical solution. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jared at puck.nether.net Fri Sep 20 17:50:19 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Sep 2013 13:50:19 -0400 Subject: iOS 7 update traffic In-Reply-To: <20130919231339.D3A1673F854@rock.dv.isc.org> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> Message-ID: On Sep 19, 2013, at 7:13 PM, Mark Andrews wrote: > Oh you mean that option that never made it past a internet-draft > that expired 13 years ago[1] and is in the private range[2] to boot. > > If you want proxy discovery to work on all devices complete the > process of getting a code point allocated then get the OS vendors > to query for it. 252 is fine for experimenting / proof of concept > but it really is the wrong value for long term use. > > Mark > > [1] http://tools.ietf.org/html/draft-ietf-wrec-wpad-01 > [2] http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml > Sure! I've found that Microsoft devices honor this option, but others do not. I would be in support of something similar to provide this support, but the part of my original reply you missed is that the content is deliberately not-cachable on the part of either the CDN or the originator. Microsoft patches are also not easily cacheable as well because they only request about 100Kb per request, so you get an awful lot of HTTP/206. They also make it easier to run local caches for an enterprise. The apple process requires the full patch to come down in one-shot and doesn't like being interrupted. It might be easier for Warren to ship each customer a 16GB USB with the whole set of images for each device type. Then again, they would have to know how to use them.... I know what to do, but my other family members, not so much... - Jared From cscora at apnic.net Fri Sep 20 18:51:00 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Sep 2013 04:51:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201309201851.r8KIp0eZ029012@thyme.rand.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, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. 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 . Routing Table Report 04:00 +10GMT Sat 21 Sep, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 467671 Prefixes after maximum aggregation: 188636 Deaggregation factor: 2.48 Unique aggregates announced to Internet: 232499 Total ASes present in the Internet Routing Table: 45041 Prefixes per ASN: 10.38 Origin-only ASes present in the Internet Routing Table: 35179 Origin ASes announcing only one prefix: 16272 Transit ASes present in the Internet Routing Table: 5915 Transit-only ASes present in the Internet Routing Table: 163 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 5180 Unregistered ASNs in the Routing Table: 810 Number of 32-bit ASNs allocated by the RIRs: 5066 Number of 32-bit ASNs visible in the Routing Table: 3947 Prefixes from 32-bit ASNs in the Routing Table: 12287 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 496 Number of addresses announced to Internet: 2643702548 Equivalent to 157 /8s, 147 /16s and 179 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.0 Total number of prefixes smaller than registry allocations: 163839 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110877 Total APNIC prefixes after maximum aggregation: 33651 APNIC Deaggregation factor: 3.29 Prefixes being announced from the APNIC address blocks: 112862 Unique aggregates announced from the APNIC address blocks: 46676 APNIC Region origin ASes present in the Internet Routing Table: 4868 APNIC Prefixes per ASN: 23.18 APNIC Region origin ASes announcing only one prefix: 1213 APNIC Region transit ASes present in the Internet Routing Table: 832 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 680 Number of APNIC addresses announced to Internet: 727933184 Equivalent to 43 /8s, 99 /16s and 97 /24s Percentage of available APNIC address space announced: 85.1 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-63999, 131072-133631 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: 162664 Total ARIN prefixes after maximum aggregation: 81384 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 163181 Unique aggregates announced from the ARIN address blocks: 75892 ARIN Region origin ASes present in the Internet Routing Table: 15900 ARIN Prefixes per ASN: 10.26 ARIN Region origin ASes announcing only one prefix: 6025 ARIN Region transit ASes present in the Internet Routing Table: 1657 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 21 Number of ARIN addresses announced to Internet: 1071770368 Equivalent to 63 /8s, 225 /16s and 235 /24s Percentage of available ARIN address space announced: 56.7 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, 393216-394239 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: 118739 Total RIPE prefixes after maximum aggregation: 61170 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 122602 Unique aggregates announced from the RIPE address blocks: 79354 RIPE Region origin ASes present in the Internet Routing Table: 17428 RIPE Prefixes per ASN: 7.03 RIPE Region origin ASes announcing only one prefix: 8266 RIPE Region transit ASes present in the Internet Routing Table: 2816 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2399 Number of RIPE addresses announced to Internet: 656991204 Equivalent to 39 /8s, 40 /16s and 227 /24s Percentage of available RIPE address space announced: 95.5 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-200191 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: 51331 Total LACNIC prefixes after maximum aggregation: 9822 LACNIC Deaggregation factor: 5.23 Prefixes being announced from the LACNIC address blocks: 56287 Unique aggregates announced from the LACNIC address blocks: 26187 LACNIC Region origin ASes present in the Internet Routing Table: 2026 LACNIC Prefixes per ASN: 27.78 LACNIC Region origin ASes announcing only one prefix: 576 LACNIC Region transit ASes present in the Internet Routing Table: 379 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 841 Number of LACNIC addresses announced to Internet: 139185200 Equivalent to 8 /8s, 75 /16s and 204 /24s Percentage of available LACNIC address space announced: 83.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11638 Total AfriNIC prefixes after maximum aggregation: 2533 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 12243 Unique aggregates announced from the AfriNIC address blocks: 3950 AfriNIC Region origin ASes present in the Internet Routing Table: 654 AfriNIC Prefixes per ASN: 18.72 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 135 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46651136 Equivalent to 2 /8s, 199 /16s and 215 /24s Percentage of available AfriNIC address space announced: 46.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 4766 2923 11561 924 Korea Telecom (KIX) 17974 2679 903 91 PT TELEKOMUNIKASI INDONESIA 7545 2081 321 112 TPG Internet Pty Ltd 4755 1770 391 188 TATA Communications formerly 9829 1550 1238 40 BSNL National Internet Backbo 9583 1232 92 505 Sify Limited 4808 1188 2133 348 CNCGROUP IP network: China169 9498 1188 309 70 BHARTI Airtel Ltd. 7552 1163 1080 13 Vietel Corporation 24560 1089 380 164 Bharti Airtel Ltd., Telemedia 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 6389 3067 3689 62 BellSouth.net Inc. 18566 2065 382 184 Covad Communications 22773 2043 2933 124 Cox Communications, Inc. 1785 2018 679 126 PaeTec Communications, Inc. 20115 1679 1650 627 Charter Communications 4323 1611 1103 409 Time Warner Telecom 701 1531 11152 796 UUNET Technologies, Inc. 30036 1349 304 632 Mediacom Communications Corp 7018 1315 11261 828 AT&T WorldNet Services 22561 1236 386 201 Digital Teleport, Inc 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 8402 1729 544 16 OJSC "Vimpelcom" 34984 1361 244 220 TELLCOM ILETISIM HIZMETLERI A 20940 1031 378 795 Akamai Technologies European 31148 987 43 17 FreeNet ISP 6830 894 2367 426 UPC Distribution Services 13188 847 99 70 TOV "Bank-Inform" 8551 745 370 41 Bezeq International 12479 676 799 49 Uni2 Autonomous System 35228 528 246 16 Avatar Broadband Limited 35819 512 597 70 Bayanat Al-Oula For Network S 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 28573 3287 1728 99 NET Servicos de Comunicao S.A 10620 2573 420 250 TVCABLE BOGOTA 7303 1712 1134 226 Telecom Argentina Stet-France 18881 1432 844 20 Global Village Telecom 8151 1317 2787 407 UniNet S.A. de C.V. 11830 865 364 15 Instituto Costarricense de El 27947 836 93 94 Telconet S.A 6503 823 434 64 AVANTEL, S.A. 7738 780 1498 36 Telecomunicacoes da Bahia S.A 3816 722 303 92 Empresa Nacional de Telecomun 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 36998 1864 112 5 Sudanese Mobile Telephone (ZA 24863 876 274 30 LINKdotNET AS number 6713 554 633 26 Itissalat Al-MAGHRIB 8452 426 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 216 The Internet Solution 29571 222 17 12 Ci Telecom Autonomous system 36992 222 501 28 Etisalat MISR 15706 221 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 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 28573 3287 1728 99 NET Servicos de Comunicao S.A 6389 3067 3689 62 BellSouth.net Inc. 4766 2923 11561 924 Korea Telecom (KIX) 17974 2679 903 91 PT TELEKOMUNIKASI INDONESIA 10620 2573 420 250 TVCABLE BOGOTA 7545 2081 321 112 TPG Internet Pty Ltd 18566 2065 382 184 Covad Communications 22773 2043 2933 124 Cox Communications, Inc. 1785 2018 679 126 PaeTec Communications, Inc. 36998 1864 112 5 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3067 3005 BellSouth.net Inc. 17974 2679 2588 PT TELEKOMUNIKASI INDONESIA 10620 2573 2323 TVCABLE BOGOTA 4766 2923 1999 Korea Telecom (KIX) 7545 2081 1969 TPG Internet Pty Ltd 22773 2043 1919 Cox Communications, Inc. 1785 2018 1892 PaeTec Communications, Inc. 18566 2065 1881 Covad Communications 36998 1864 1859 Sudanese Mobile Telephone (ZA 8402 1729 1713 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.90.192.0/18 36086 Broad Communications Technolo 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.96.0/20 40676 Psychz Networks 23.91.112.0/21 32475 MidPhase Inc. 23.91.160.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.160.0/19 36493 3757277 Canada Inc. (oa 295.c 23.91.164.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.168.0/22 36493 3757277 Canada Inc. (oa 295.c 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:11 /10:31 /11:93 /12:250 /13:479 /14:915 /15:1627 /16:12794 /17:6704 /18:11144 /19:22955 /20:32528 /21:35151 /22:49644 /23:43016 /24:247837 /25:844 /26:992 /27:481 /28:47 /29:79 /30:19 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1829 1864 Sudanese Mobile Telephone (ZA 6389 1712 3067 BellSouth.net Inc. 8402 1440 1729 OJSC "Vimpelcom" 22773 1329 2043 Cox Communications, Inc. 30036 1209 1349 Mediacom Communications Corp 11492 1187 1228 Cable One 1785 1084 2018 PaeTec Communications, Inc. 6983 1025 1152 ITC^Deltacom 22561 960 1236 Digital Teleport, Inc Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:812 2:838 3:3 4:17 5:967 6:19 8:607 12:1894 13:3 14:869 15:11 16:3 17:12 18:19 20:21 23:405 24:1744 27:1579 31:1463 32:45 33:2 34:5 36:80 37:1829 38:907 39:3 40:179 41:3287 42:253 44:13 46:2004 47:6 49:673 50:844 52:12 54:39 55:5 57:26 58:1169 59:605 60:343 61:1417 62:1196 63:1988 64:4566 65:2365 66:4175 67:2084 68:1086 69:3307 70:868 71:495 72:2008 74:2559 75:330 76:303 77:1176 78:1056 79:630 80:1318 81:1030 82:631 83:582 84:585 85:1265 86:487 87:1045 88:554 89:1802 90:158 91:5708 92:599 93:1641 94:2026 95:1572 96:518 97:342 98:1041 99:43 100:31 101:609 103:3311 105:519 106:142 107:208 108:507 109:1870 110:965 111:1123 112:574 113:798 114:724 115:1005 116:972 117:823 118:1161 119:1284 120:363 121:741 122:1879 123:1254 124:1386 125:1425 128:627 129:321 130:322 131:674 132:347 133:161 134:546 135:67 136:272 137:268 138:348 139:178 140:206 141:324 142:553 143:408 144:504 145:100 146:516 147:490 148:698 149:356 150:157 151:584 152:413 153:195 154:46 155:486 156:279 157:421 158:285 159:763 160:350 161:450 162:705 163:229 164:625 165:573 166:258 167:611 168:1049 169:127 170:1087 171:193 172:25 173:1609 174:663 175:499 176:1209 177:2289 178:1884 179:145 180:1526 181:719 182:1269 183:464 184:655 185:871 186:2553 187:1456 188:1901 189:1327 190:6989 192:6939 193:5662 194:4064 195:3336 196:1323 197:980 198:4685 199:5460 200:5980 201:2507 202:8975 203:8921 204:4518 205:2636 206:2845 207:2899 208:4002 209:3607 210:2947 211:1554 212:2287 213:2052 214:930 215:99 216:5303 217:1658 218:623 219:314 220:1277 221:558 222:326 223:500 End of report From cidr-report at potaroo.net Fri Sep 20 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Sep 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201309202200.r8KM00sv086498@wattle.apnic.net> This report has been generated at Fri Sep 20 21:13:29 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-09-13 481601 273173 14-09-13 481702 272312 15-09-13 481537 272334 16-09-13 481108 272841 17-09-13 481432 272757 18-09-13 481432 274141 19-09-13 481930 274557 20-09-13 482319 274583 AS Summary 45203 Number of ASes in routing system 18598 Number of ASes announcing only one prefix 4175 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118059232 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Sep13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 482155 274460 207695 43.1% All ASes AS6389 3067 65 3002 97.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2678 147 2531 94.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS28573 3287 800 2487 75.7% NET Servi?os de Comunica??o S.A. AS7029 4175 2026 2149 51.5% WINDSTREAM - Windstream Communications Inc AS4766 2923 932 1991 68.1% KIXS-AS-KR Korea Telecom AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS10620 2573 1003 1570 61.0% Telmex Colombia S.A. AS3356 3253 1731 1522 46.8% LEVEL3 Level 3 Communications AS36998 1866 378 1488 79.7% SDN-MOBITEL AS4323 2953 1528 1425 48.3% TWTC - tw telecom holdings, inc. AS18881 1432 69 1363 95.2% Global Village Telecom AS7303 1712 458 1254 73.2% Telecom Argentina S.A. AS4755 1769 590 1179 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1196 138 1058 88.5% VIETEL-AS-AP Vietel Corporation AS22561 1236 210 1026 83.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2018 1161 857 42.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 2046 1232 814 39.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18101 981 179 802 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1188 403 785 66.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS11830 866 117 749 86.5% Instituto Costarricense de Electricidad y Telecom. AS701 1532 800 732 47.8% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS7545 2082 1350 732 35.2% TPG-INTERNET-AP TPG Telecom Limited AS24560 1089 368 721 66.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS13977 848 144 704 83.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1322 624 698 52.8% Uninet S.A. de C.V. AS855 740 55 685 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1152 483 669 58.1% ITCDELTA - ITC^Deltacom AS7738 780 138 642 82.3% Telemar Norte Leste S.A. AS17676 767 140 627 81.7% GIGAINFRA Softbank BB Corp. AS3549 938 321 617 65.8% GBLX Global Crossing Ltd. Total 54534 18058 36476 66.9% Top 30 total Possible Bogus Routes 23.92.128.0/17 AS42981 RES-PL RES.PL ISP S.C. 23.92.224.0/23 AS55048 VMWARE - VMware, Inc. 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 31.13.184.0/21 AS42981 RES-PL RES.PL ISP S.C. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 82.103.0.0/18 AS30901 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.200.188.0/22 AS44016 91.205.188.0/22 AS47983 91.207.178.0/23 AS48274 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.9.220.0/24 AS13230 103.9.221.0/24 AS13230 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 164.40.184.0/24 AS19821 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.35.200.0/22 AS50304 BLIX Blix Solutions AS 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.9.59.0/24 AS1257 TELE2 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.43.127.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.84.16.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.84.17.0/24 AS17781 XINHUA Xinhua News Agency 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.225.0/24 AS3549 GBLX Global Crossing Ltd. 208.66.227.0/24 AS3549 GBLX Global Crossing Ltd. 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.87.144.0/21 AS21919 209.87.152.0/22 AS21919 209.87.156.0/24 AS21919 209.87.157.0/24 AS21919 209.87.158.0/24 AS21919 209.87.159.0/24 AS21919 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS1915 SEQUOIA-AS - National Science Foundation 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Sep 20 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Sep 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201309202200.r8KM01FB086512@wattle.apnic.net> BGP Update Report Interval: 12-Sep-13 -to- 19-Sep-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 52984 2.3% 38.5 -- BSNL-NIB National Internet Backbone 2 - AS8402 44678 2.0% 23.1 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS15003 35584 1.6% 41.9 -- NOBIS-TECH - Nobis Technology Group, LLC 4 - AS28573 29527 1.3% 8.9 -- NET Servi?os de Comunica??o S.A. 5 - AS36998 26259 1.1% 14.1 -- SDN-MOBITEL 6 - AS13118 22295 1.0% 474.4 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS10620 21940 1.0% 9.0 -- Telmex Colombia S.A. 8 - AS27738 20281 0.9% 35.1 -- Ecuadortelecom S.A. 9 - AS9498 18747 0.8% 15.7 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS9416 18467 0.8% 473.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS4775 16130 0.7% 194.3 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS35819 14887 0.7% 26.6 -- MOBILY-AS Etihad Etisalat Company (Mobily) 13 - AS48159 12275 0.5% 13.2 -- TIC-AS Telecommunication Infrastructure Company 14 - AS8151 12188 0.5% 11.3 -- Uninet S.A. de C.V. 15 - AS21341 11867 0.5% 247.2 -- SINET-AS Soroush Rasanheh Company Ltd 16 - AS4766 11125 0.5% 3.8 -- KIXS-AS-KR Korea Telecom 17 - AS53229 10773 0.5% 3591.0 -- Industrias Arteb S.A 18 - AS11976 10762 0.5% 60.1 -- FIDN - Fidelity Communication International Inc. 19 - AS31148 10398 0.5% 10.5 -- FREENET-AS Freenet Ltd. 20 - AS4434 10051 0.4% 139.6 -- ERX-RADNET1-AS PT Rahajasa Media Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53229 10773 0.5% 3591.0 -- Industrias Arteb S.A 2 - AS6174 7068 0.3% 3534.0 -- SPRINTLINK8 - Sprint 3 - AS37367 3144 0.1% 3144.0 -- CALLKEY 4 - AS2 2740 0.1% 1985.0 -- CONTROLVM-MY ControlVM Technology 5 - AS11533 1998 0.1% 1998.0 -- VERITY-AS - Verity, Inc. 6 - AS42334 2577 0.1% 1288.5 -- BBP-AS Broadband Plus s.a.l. 7 - AS1880 4851 0.2% 1212.8 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 8 - AS21551 1044 0.1% 1044.0 -- HIGHBRIDGENY - Highbridge Capital Management, LLC. 9 - AS6629 9199 0.4% 836.3 -- NOAA-AS - NOAA 10 - AS59486 808 0.0% 808.0 -- DATAGOSTAROFOGHFARS Data Gostar Ofogh Fars 11 - AS19779 1591 0.1% 795.5 -- 12 - AS7202 8226 0.4% 747.8 -- FAMU - Florida A & M University 13 - AS48612 9468 0.4% 676.3 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 14 - AS38000 1792 0.1% 597.3 -- CRISIL-AS [CRISIL Limited.Autonomous System] 15 - AS52355 1177 0.1% 588.5 -- Jalasoft Corp. 16 - AS58085 4618 0.2% 577.2 -- TCE-ASN Esfahan Telecommunication Company (P.J.S.) 17 - AS56895 2308 0.1% 577.0 -- SVIAZTELECOM-AS Svyaztelecom ltd. 18 - AS47887 2564 0.1% 512.8 -- NEU-AS NEU Telecom & Technologies 19 - AS37443 996 0.0% 498.0 -- Usmanu 20 - AS24282 3896 0.2% 487.0 -- KIR Kagoya Japan CO,LTD TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21615 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 61.95.239.0/24 15123 0.6% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 3 - 186.251.232.0/23 10771 0.4% AS53229 -- Industrias Arteb S.A 4 - 202.154.17.0/24 9910 0.4% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 5 - 92.246.207.0/24 9353 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 6 - 203.118.224.0/21 9229 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - 203.118.232.0/21 9170 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - 192.58.232.0/24 9164 0.4% AS6629 -- NOAA-AS - NOAA 9 - 120.28.62.0/24 8007 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 222.127.0.0/24 7980 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 11 - 95.47.176.0/24 6932 0.3% AS8359 -- MTS MTS OJSC 12 - 67.210.190.0/23 5812 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 13 - 115.170.128.0/17 5706 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 14 - 204.29.132.0/23 4848 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 15 - 67.210.188.0/23 4672 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 16 - 69.38.178.0/24 4410 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 17 - 168.223.200.0/22 4113 0.2% AS7202 -- FAMU - Florida A & M University 18 - 168.223.206.0/23 4063 0.2% AS7202 -- FAMU - Florida A & M University 19 - 64.187.64.0/23 3681 0.1% AS16608 -- KENTEC - Kentec Communications, Inc. 20 - 208.16.110.0/24 3537 0.1% AS6174 -- SPRINTLINK8 - Sprint Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From marka at isc.org Fri Sep 20 22:55:50 2013 From: marka at isc.org (Mark Andrews) Date: Sat, 21 Sep 2013 08:55:50 +1000 Subject: iOS 7 update traffic In-Reply-To: Your message of "Fri, 20 Sep 2013 13:50:19 -0400." References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> Message-ID: <20130920225550.92EC774B120@rock.dv.isc.org> In message , Jared Mauch writes: > > On Sep 19, 2013, at 7:13 PM, Mark Andrews wrote: > > > Oh you mean that option that never made it past a internet-draft > > that expired 13 years ago[1] and is in the private range[2] to boot. > > > > If you want proxy discovery to work on all devices complete the > > process of getting a code point allocated then get the OS vendors > > to query for it. 252 is fine for experimenting / proof of concept > > but it really is the wrong value for long term use. > > > > Mark > > > > [1] http://tools.ietf.org/html/draft-ietf-wrec-wpad-01 > > [2] > http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter > s.xhtml > > > > Sure! > > I've found that Microsoft devices honor this option, but others do not. > > I would be in support of something similar to provide this support, but > the part of my original reply you missed is that the content is > deliberately not-cachable on the part of either the CDN or the > originator. Microsoft patches are also not easily cacheable as well > because they only request about 100Kb per request, so you get an awful > lot of HTTP/206. > > They also make it easier to run local caches for an enterprise. > > The apple process requires the full patch to come down in one-shot and > doesn't like being interrupted. > > It might be easier for Warren to ship each customer a 16GB USB with the > whole set of images for each device type. Then again, they would have to > know how to use them.... I know what to do, but my other family members, > not so much... > > - Jared So you fix one part at a time. Each part is independently fixable. Each part helps by itself. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From LarrySheldon at cox.net Fri Sep 20 23:46:54 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 20 Sep 2013 18:46:54 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> Message-ID: <523CDE6E.8060906@cox.net> On 9/20/2013 5:55 PM, Mark Andrews wrote: > So you fix one part at a time. Each part is independently fixable. Each > part helps by itself. I wonder it the thing that needs to be fixed first involves opening a dialog between Engineering and Marketing over which the message "Don't sell stuff we can't deliver" might be passed. And just maybe some "we are going public with a new whatever in 6 months, here is [some meaningful amount of money], get us ready." messages in the opposite direction? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Sat Sep 21 01:13:07 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 20 Sep 2013 20:13:07 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> Message-ID: <523CF2A3.6020505@cox.net> From a Facebook posting: > So need the masses input.. If you updated to iOS 7... Wed I installed > it, it was fine. Thursday fine as well. But today.. It just wants to > keep resetting itself every 15-20 mins. It's just on my 4s... Any one > else having this issue? Just wondering. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mikeal.clark at gmail.com Sat Sep 21 02:41:51 2013 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Fri, 20 Sep 2013 21:41:51 -0500 Subject: iOS 7 update traffic In-Reply-To: <523CF2A3.6020505@cox.net> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> <523CF2A3.6020505@cox.net> Message-ID: I've seen 4s with the panic.list problem after upgrade. Apple claims hardware issue. On Fri, Sep 20, 2013 at 8:13 PM, Larry Sheldon wrote: > From a Facebook posting: > > So need the masses input.. If you updated to iOS 7... Wed I installed >> it, it was fine. Thursday fine as well. But today.. It just wants to >> keep resetting itself every 15-20 mins. It's just on my 4s... Any one >> else having this issue? Just wondering. >> > > > > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > From jfmezei_nanog at vaxination.ca Sat Sep 21 21:07:04 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 21 Sep 2013 17:07:04 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <00d701ceb577$f78187c0$e6849740$@sstar.com> <64245AC1-BC00-4928-B2F7-F259E8632655@puck.nether.net> <20130919231339.D3A1673F854@rock.dv.isc.org> <523CF2A3.6020505@cox.net> Message-ID: <523E0A78.9000804@vaxination.ca> http://www.electronista.com/articles/13/09/20/upgrading.spike.doubled.some.isp.traffic.12.percent.worldwide.internet.usage.jump/ ## Upgrading spike doubled some ISP traffic; 12 percent worldwide Internet usage jump ... Analytics company Mixpanel estimates that more than 130 million users had updated their devices within the first 10 hours of availability, out of a potential iOS 7-eligible base of 415 million. ... The spikes, reported by The Guardian in the UK, focus on British ISP reports and show that demand hit its peak about 3.5 hours after the official release. This would have been around the time Apple servers began to recover from the initial wave of downloaders as users struggled in the first few hours to download the free iOS upgrade, which ranged in size from 750MB to 1.4GB depending on what device was being updated. ... At one point in the initial surge, a British Telecom (BT) spokesperson reported that the provider was seeing traffic of over 200 Gigabits per second, the highest the company has ever recorded. Lonap said that overall high-use traffic, which averages up to 30 Gigabits per second, spiked to just under 60Gb per second late Wednesday evening as the upgrade became available, and raised the daily peak time traffic to nearly 40Gb per second on Thursday. The paper also reported that Germany's Berlin Internet Exchange saw traffic rise precipitously -- more than 10Gb per second over normal traffic levels -- as iOS 7 came online. Data from Akamai, a company that distributes and manages Internet backbone traffic, suggested that overall worldwide usage jumped 12 percent above normal levels as the download became available. ## From georgeb at gmail.com Sun Sep 22 02:41:54 2013 From: georgeb at gmail.com (George B.) Date: Sat, 21 Sep 2013 19:41:54 -0700 Subject: Routes from AS17299 via AS24246 Message-ID: I would be much obliged of folks (peers of AS24246 -- InterNAP Hong Kong -- in particular) would adjust their filters to accept 216.239.98.0/24 and 216.231.203.0/24 announced from AS17299 via AS24246. You should also see those routes from AS17819 but it is the 24246 path that causing me hardship. Thanks g (yeah, I'll get them in a routing registry next week if that will help) From morrowc.lists at gmail.com Sun Sep 22 03:23:26 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 21 Sep 2013 23:23:26 -0400 Subject: Routes from AS17299 via AS24246 In-Reply-To: References: Message-ID: On Sat, Sep 21, 2013 at 10:41 PM, George B. wrote: > 216.231.203.0/24 you don't appear to be on the whois list for that block nor asn... so, why would someone accept this block on your say-so? Are you asking as a customer of the ASN or as the ASN owner/operator? From georgeb at gmail.com Sun Sep 22 03:38:29 2013 From: georgeb at gmail.com (George B.) Date: Sat, 21 Sep 2013 20:38:29 -0700 Subject: Routes from AS17299 via AS24246 In-Reply-To: References: Message-ID: Because it is being announced by the ASN that is owned by the same company that owns the address block. Look up the originating ASN, look up the IP block. You don't have to take MY word for it but I am employed by that company. That's why. On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow wrote: > On Sat, Sep 21, 2013 at 10:41 PM, George B. wrote: > > 216.231.203.0/24 > > you don't appear to be on the whois list for that block nor asn... so, > why would someone accept this block on your say-so? Are you asking as > a customer of the ASN or as the ASN owner/operator? > From georgeb at gmail.com Sun Sep 22 03:41:17 2013 From: georgeb at gmail.com (George B.) Date: Sat, 21 Sep 2013 20:41:17 -0700 Subject: Routes from AS17299 via AS24246 In-Reply-To: References: Message-ID: And yeah, I am still associated with my former employer, I'm not on the new employer's stuff yet. G On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow wrote: > On Sat, Sep 21, 2013 at 10:41 PM, George B. wrote: > > 216.231.203.0/24 > > you don't appear to be on the whois list for that block nor asn... so, > why would someone accept this block on your say-so? Are you asking as > a customer of the ASN or as the ASN owner/operator? > From morrowc.lists at gmail.com Sun Sep 22 03:48:32 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 21 Sep 2013 23:48:32 -0400 Subject: Routes from AS17299 via AS24246 In-Reply-To: References: Message-ID: $ whois AS17299 | grep -i bos $ $ whois 216.239.98.0 | grep -i bos $ don't see you on either of the whois contact sets... which was what prompted my question originally. $ whois -h whois.cymru.com 216.239.98.0 AS | IP | AS Name 17299 | 216.239.98.0 | IPASS-4 - iPass Incorporated that seems kosher though. On Sat, Sep 21, 2013 at 11:41 PM, George B. wrote: > And yeah, I am still associated with my former employer, I'm not on the new > employer's stuff yet. > > G > > > On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow > wrote: >> >> On Sat, Sep 21, 2013 at 10:41 PM, George B. wrote: >> > 216.231.203.0/24 >> >> you don't appear to be on the whois list for that block nor asn... so, >> why would someone accept this block on your say-so? Are you asking as >> a customer of the ASN or as the ASN owner/operator? > > From georgeb at gmail.com Sun Sep 22 03:56:40 2013 From: georgeb at gmail.com (George B.) Date: Sat, 21 Sep 2013 20:56:40 -0700 Subject: Routes from AS17299 via AS24246 In-Reply-To: References: Message-ID: Sorry if I a bit testy. Have a typhoon bearing down on the region and the primary connectivity for a site is apparently useless as the routes are not propagating from them and I have only one single connection to the alternate provider. I'm trying to make the site as resilient as possible under the circumstances. InterNAP claims peers are filtering the routes so I am asking for a favor. Thanks. G ASN ASNumber: 17299 ASName: IPASS-4 ASHandle: AS17299 RegDate: 2006-03-27 Updated: 2012-07-24 Ref: http://whois.arin.net/rest/asn/AS17299 OrgName: iPass Incorporated OrgId: IPAS Address: 3800 Bridge Parkway City: Redwood Shores StateProv: CA Address block 1: NetRange: 216.239.96.0 - 216.239.111.255 CIDR: 216.239.96.0/20 OriginAS: NetName: IPASS-1BLK NetHandle: NET-216-239-96-0-1 Parent: NET-216-0-0-0-0 NetType: Direct Allocation Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate: 2000-11-29 Updated: 2012-07-24 Ref: http://whois.arin.net/rest/net/NET-216-239-96-0-1 OrgName: iPass Incorporated OrgId: IPAS Address: 3800 Bridge Parkway City: Redwood Shores StateProv: CA PostalCode: 94065 Country: US Second block: NetRange: 216.231.192.0 - 216.231.207.255 CIDR: 216.231.192.0/20 OriginAS: AS17398, AS32199, AS22665, AS17299 NetName: NET-216-231-192-0-1 NetHandle: NET-216-231-192-0-1 Parent: NET-216-0-0-0-0 NetType: Direct Assignment RegDate: 1999-06-29 Updated: 2012-07-24 Ref: http://whois.arin.net/rest/net/NET-216-231-192-0-1 OrgName: iPass Incorporated OrgId: IPAS Address: 3800 Bridge Parkway City: Redwood Shores StateProv: CA On Sat, Sep 21, 2013 at 8:48 PM, Christopher Morrow wrote: > $ whois AS17299 | grep -i bos > $ > > $ whois 216.239.98.0 | grep -i bos > $ > > don't see you on either of the whois contact sets... which was what > prompted my question originally. > > $ whois -h whois.cymru.com 216.239.98.0 > AS | IP | AS Name > 17299 | 216.239.98.0 | IPASS-4 - iPass Incorporated > > that seems kosher though. > > On Sat, Sep 21, 2013 at 11:41 PM, George B. wrote: > > And yeah, I am still associated with my former employer, I'm not on the > new > > employer's stuff yet. > > > > G > > > > > > On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow > > wrote: > >> > >> On Sat, Sep 21, 2013 at 10:41 PM, George B. wrote: > >> > 216.231.203.0/24 > >> > >> you don't appear to be on the whois list for that block nor asn... so, > >> why would someone accept this block on your say-so? Are you asking as > >> a customer of the ASN or as the ASN owner/operator? > > > > > From colin.alston at gmail.com Sun Sep 22 19:35:51 2013 From: colin.alston at gmail.com (Colin Alston) Date: Sun, 22 Sep 2013 21:35:51 +0200 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: That system by the way is annoying when your mobile network operator are so oversubscribed/old-fashioned that I had to wait over 6 months before I could update to Android ICS... I really don't want my ability to update the software on my phone to be controlled by a teleco, and these large teleco's really should have Akamai caches in place by now - if they even know what that is. On Thu, Sep 19, 2013 at 8:22 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's > sequentially. That way, you do not.. > > 1. Murder your last mike packet network, which is your bandwidth > bottleneck. > > 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. > > 3. Anger your paying customers who would like to use packet data > successfully on an ios download day. > > These people (Apple) represent themselves as smart guys, but their actions > reflect otherwise. I bet this would be a larger deal to Nanog people if > your Internet stopped working as the result of 100% Linux adoption. That is > very close to what this is.. Tens of millions of people trying to update > their 13 ios devices at the same time. Who owns a single ios device? A > household could do 5-10gb worth of updates in a single day.. > > I personally do not own an ios device, and I see close to 3 gigs worth of > update traffic at my house. These things are everywhere, and this problem > will not stop. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Mikael Abrahamsson > Date: 09/19/2013 11:16 AM (GMT-08:00) > To: Warren Bailey > Cc: Paul Ferguson ,NANOG > Subject: Re: iOS 7 update traffic > > > On Thu, 19 Sep 2013, Warren Bailey wrote: > > > Why does apple feel it is okay to send every mobile device an update on > a single day? > > They don't, these are users who actively goes into the software upgrade > menu and pressing "upgrade". > > I believe the nagging won't start for quite some time. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From mureninc at gmail.com Sun Sep 22 19:47:12 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 22 Sep 2013 12:47:12 -0700 Subject: gmail.com 550-5.7.1 refusing mtr(8) output; other excessive bounces Message-ID: <20130922194712.GA10209@Cns.Cns.SU> This has happened to me several times recently; has never happened until a couple of weeks ago. >From the https://mail.google.com/mail/ web-interface, Cc an alias on my server, which expands to, amongst other things, my gmail.com email address; a bounce is immediately received in the thread (apparently, gmail doesn't reject the bounces from the very same server from which some messages are rejected). Most likely cause: too many domain names from the mtr(8) output in the message. Same for sending a similar message directly from my own server, directly to my gmail.com address, being in the Cc field: a bounce is received within my own server, no message is received at gmail. The bounce from such an experience is at the end of this message. I consider this a major outage: how many other valid semi-automated emails addressed to myself have been unfairly rejected by gmail on the SMTP level recently? I also now know why my gmail.com address has been unsubscribed from several mailing lists over this summer, citing excessive bouncing. My own mailserver wasn't even involved: <<## Delivered-To: mureninc at gmail.com Received: by 10.114.5.70 with SMTP id q6csp13073ldq; Tue, 10 Sep 2013 03:43:00 -0700 (PDT) X-Received: by 10.204.76.203 with SMTP id d11mr18914232bkk.3.1378809779724; Tue, 10 Sep 2013 03:42:59 -0700 (PDT) Return-Path: Received: from flocki.atrpms.net (m.at.physik.fu-berlin.de. [160.45.254.30]) by mx.google.com with ESMTPS id zk7si1773373bkb.190.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 03:42:59 -0700 (PDT) Received-SPF: neutral (google.com: 160.45.254.30 is neither permitted nor denied by best guess record for domain of lm-sensors-bounces at lm-sensors.org) client-ip=160.45.254.30; Authentication-Results: mx.google.com; spf=neutral (google.com: 160.45.254.30 is neither permitted nor denied by best guess record for domain of lm-sensors-bounces at lm-sensors.org) smtp.mail=lm-sensors-bounces at lm-sensors.org Received: from localhost ([::1] helo=m.at.physik.fu-berlin.de) by flocki.atrpms.net with esmtp (Exim 4.80.1) id 1VJLPJ-0001fB-QJ for mureninc at gmail.com; Tue, 10 Sep 2013 12:42:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: lm-sensors-request at lm-sensors.org To: mureninc at gmail.com ... ... Your membership in the mailing list lm-sensors has been disabled due to excessive bounces The last bounce received from you was dated 10-Sep-2013. You will not get any more messages from this list until you re-enable your membership. You will receive 3 more reminders like this before your membership in the list is deleted. ... ##>> If you need any further info, feel free to contact me off-list. C. ----- Forwarded message from Mail Delivery Subsystem ----- Date: Sun, 22 Sep 2013 11:36:28 -0700 (PDT) From: Mail Delivery Subsystem To: XXXXXX at bugmailXXXXXXXX Subject: Returned mail: see transcript for details The original message was received at Sun, 22 Sep 2013 11:36:19 -0700 (PDT) from XXXXXlocalhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 550-5.7.1 [2001:470:7240:: 12] Our system has detected that this message is) ----- Transcript of session follows ----- ... while talking to gmail-smtp-in.l.google.com.: >>> DATA <<< 550-5.7.1 [2001:470:7240:: 12] Our system has detected that this message is <<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, <<< 550-5.7.1 this message has been blocked. Please visit <<< 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for <<< 550 5.7.1 more information. od6si8589779bkb.242 - gsmtp 554 5.0.0 Service unavailable Reporting-MTA: dns; XXXXXXXXXX Received-From-MTA: DNS; localhost Arrival-Date: Sun, 22 Sep 2013 11:36:19 -0700 (PDT) Final-Recipient: RFC822; mureninc at gmail.com Action: failed Status: 5.7.1 Remote-MTA: DNS; gmail-smtp-in.l.google.com Diagnostic-Code: SMTP; 550-5.7.1 [2001:470:7240:: 12] Our system has detected that this message is Last-Attempt-Date: Sun, 22 Sep 2013 11:36:20 -0700 (PDT) Return-Path: Received: from XXXXXXXXXX (XXXX at localhost [127.0.0.1]) by XXXXXXXXXX (8.14.5/8.14.5) with ESMTP id r8MIaJGR015280; Sun, 22 Sep 2013 11:36:19 -0700 (PDT) Received: (from XXXX at localhost) by XXXXXXXXXX (8.14.5/8.14.5/Submit) id r8MIaJ9o021840; Sun, 22 Sep 2013 11:36:19 -0700 (PDT) X-Authentication-Warning: XXXXXXXXXX: XXXX set sender to XXXXXX at bugmailXXXXXXXX using -f Date: Sun, 22 Sep 2013 11:36:19 -0700 From: "Constantine A. Murenin" To: noc at he.net Cc: mureninc at gmail.com Subject: packet loss at 10gigabitethernet9-6.core1.par2.he.net Message-ID: <20130922183619.GA10404 at XXXXXXXXXX> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) ----- End forwarded message ----- From jcurran at arin.net Sun Sep 22 23:15:28 2013 From: jcurran at arin.net (John Curran) Date: Sun, 22 Sep 2013 23:15:28 +0000 Subject: 32-bit ASN acceptance by ISPs in ARIN region (was: Re: Weekly Routing Table Report) In-Reply-To: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> Message-ID: <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> On Sep 20, 2013, at 2:51 PM, Routing Analysis Role Account wrote: > Analysis Summary > ---------------- > ... > Number of 32-bit ASNs allocated by the RIRs: 5066 > Number of 32-bit ASNs visible in the Routing Table: 3947 > ... > ARIN Region Analysis Summary > ---------------------------- > ... > Number of ARIN region 32-bit ASNs visible in the Routing Table: 21 Folks - If you work for a Internet service provider, please check your readiness to accept customers with 32-bit ASNs as soon as possible. While we still have some 16-bit ASNs in ARIN's regional pool, availability is limited and we do not anticipate receiving additional 16-bit ASN blocks from IANA. Not being able to use 32-bit ASNs in your network and support systems will inevitably lead to confusion for those customers who are assigned them. Thanks! /John John Curran President and CEO ARIN From jsmith4112003 at yahoo.co.uk Mon Sep 23 09:32:23 2013 From: jsmith4112003 at yahoo.co.uk (John Smith) Date: Mon, 23 Sep 2013 10:32:23 +0100 (BST) Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> Message-ID: <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> Picked this off www.jaluri.com (network and Cisco blog aggregator): http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ The consensus seems to be for providers to install CDN servers, if they arent able to cope up with an occasional OS update traffic. http://news.idg.no/cw/art.cfm?id=391B4B64-F693-41B7-6BBAC6D7017C3B8A John ________________________________ From: Colin Alston To: Warren Bailey Cc: NANOG Sent: Monday, 23 September 2013, 1:05 Subject: Re: iOS 7 update traffic That system by the way is annoying when your mobile network operator are so oversubscribed/old-fashioned that I had to wait over 6 months before I could update to Android ICS... I really don't want my ability to update the software on my phone to be controlled by a teleco, and these large teleco's really should have Akamai caches in place by now - if they even know what that is. On Thu, Sep 19, 2013 at 8:22 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I own a galaxy note 2..tmo ran an update that pushed to unique IMEI's > sequentially. That way, you do not.. > > 1. Murder your last mike packet network, which is your bandwidth > bottleneck. > > 2. Murder your ggsn/whateverpacketnodeyouwant closer to the core. > > 3. Anger your paying customers who would like to use packet data > successfully on an ios download day. > > These people (Apple) represent themselves as smart guys, but their actions > reflect otherwise. I bet this would be a larger deal to Nanog people if > your Internet stopped working as the result of 100% Linux adoption. That is > very close to what this is.. Tens of millions of people trying to update > their 13 ios devices at the same time. Who owns a single ios device? A > household could do 5-10gb worth of updates in a single day.. > > I personally do not own an ios device, and I see close to 3 gigs worth of > update traffic at my house. These things are everywhere, and this problem > will not stop. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Mikael Abrahamsson > Date: 09/19/2013 11:16 AM (GMT-08:00) > To: Warren Bailey > Cc: Paul Ferguson ,NANOG > Subject: Re: iOS 7 update traffic > > > On Thu, 19 Sep 2013, Warren Bailey wrote: > > > Why does apple feel it is okay to send every mobile device an update on > a single day? > > They don't, these are users who actively goes into the software upgrade > menu and pressing "upgrade". > > I believe the nagging won't start for quite some time. > > -- > Mikael Abrahamsson? ? email: swmike at swm.pp.se > From nick at foobar.org Mon Sep 23 10:01:28 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Sep 2013 11:01:28 +0100 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> Message-ID: <52401178.3000500@foobar.org> On 23/09/2013 00:15, John Curran wrote: > Not being able to use 32-bit ASNs in your network and support systems will > inevitably lead to confusion for those customers who are assigned them. I look forward to the day when we have proper 32 bit BGP community support and ASN32s finally become usable on nontrivial networks. Nick From neil at tonal.clara.co.uk Mon Sep 23 10:59:59 2013 From: neil at tonal.clara.co.uk (Neil Harris) Date: Mon, 23 Sep 2013 11:59:59 +0100 Subject: iOS 7 update traffic In-Reply-To: <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> Message-ID: <52401F2F.8010209@tonal.clara.co.uk> On 23/09/13 10:32, John Smith wrote: > Picked this off www.jaluri.com (network and Cisco blog aggregator): > > http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ > > The consensus seems to be for providers to install CDN servers, if they arent able to cope up with an occasional OS update traffic. > > http://news.idg.no/cw/art.cfm?id=391B4B64-F693-41B7-6BBAC6D7017C3B8A > > John > Perhaps Apple, Microsoft etc. should consider using Bittorrent as a way of distributing their updates? If ISPs were to run their own Bittorrent servers (with appropriate restrictions, see below), this would then create an instant CDN, with no need to define any other protocols or pay any third parties. The hard bit would be to create a way for Apple etc. to be able to authoritatively say "we are the content owners, and are happy for you to replicate this locally": but perhaps this could be as simple serving the initial seed from an HTTPS server with a valid certificate? It would then be trivial to create a whitelist of the domains of the top 10 or so distributors of patches, and then everything would work automatically from then on. -- N. From glen.kent at gmail.com Mon Sep 23 12:14:08 2013 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 23 Sep 2013 17:44:08 +0530 Subject: iOS 7 update traffic In-Reply-To: <52401F2F.8010209@tonal.clara.co.uk> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: One of the earlier posts seems to suggest that if iOS updates were cached on the ISPs CDN server then the traffic would have been manageable since everybody would only contact the local sever to get the image. Is this assumption correct? Do most big service providers maintain their own content servers? Is this what we're heading to these days? Glen On Mon, Sep 23, 2013 at 4:29 PM, Neil Harris wrote: > On 23/09/13 10:32, John Smith wrote: > >> Picked this off www.jaluri.com (network and Cisco blog aggregator): >> >> http://routingfreak.wordpress.**com/2013/09/23/ios7s-impact-** >> on-networks-worldwide/ >> >> The consensus seems to be for providers to install CDN servers, if they >> arent able to cope up with an occasional OS update traffic. >> >> http://news.idg.no/cw/art.cfm?**id=391B4B64-F693-41B7-**6BBAC6D7017C3B8A >> >> John >> >> > Perhaps Apple, Microsoft etc. should consider using Bittorrent as a way of > distributing their updates? If ISPs were to run their own Bittorrent > servers (with appropriate restrictions, see below), this would then create > an instant CDN, with no need to define any other protocols or pay any third > parties. > > The hard bit would be to create a way for Apple etc. to be able to > authoritatively say "we are the content owners, and are happy for you to > replicate this locally": but perhaps this could be as simple serving the > initial seed from an HTTPS server with a valid certificate? It would then > be trivial to create a whitelist of the domains of the top 10 or so > distributors of patches, and then everything would work automatically from > then on. > > -- N. > > > From bmanning at vacation.karoshi.com Mon Sep 23 12:39:03 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 23 Sep 2013 12:39:03 +0000 Subject: DNS Reliability In-Reply-To: <20130916163622.GC3108@burnout.tpb.net> References: <52327019.7070600@cox.net> <52336F2F.1030206@vaxination.ca> <20130913201509.GC18576@vacation.karoshi.com.> <20130916163622.GC3108@burnout.tpb.net> Message-ID: <20130923123903.GB9251@vacation.karoshi.com.> On Mon, Sep 16, 2013 at 06:36:22PM +0200, Niels Bakker wrote: > * bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) [Fri 13 Sep > 2013, 22:16 CEST]: > > from where? to where? what % of the Internet is _not_ > > reachable from my DNS service at any given time? why is > > that acceptable? and more importantly, who's job is it to > > fix/stablize the net so these "remote" locations can reach > > my DNS service? > > > > "we will answer 100% of the valid DNS queries we receive." > > Is this thread even about authoritative or recursive DNS? > > > -- Niels. Does it matter? /bill From rmayer at nerd-residenz.de Mon Sep 23 12:32:27 2013 From: rmayer at nerd-residenz.de (Ralph J.Mayer) Date: Mon, 23 Sep 2013 14:32:27 +0200 Subject: iOS 7 update traffic In-Reply-To: <52401F2F.8010209@tonal.clara.co.uk> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: <20130923123227.GB9532@falstaff.nerd-residenz.net> > Perhaps Apple, Microsoft etc. should consider using Bittorrent as a > way of distributing their updates? If ISPs were to run their own > Bittorrent servers (with appropriate restrictions, see below), this > would then create an instant CDN, with no need to define any other > protocols or pay any third parties. They should do it like the game vendors. You are able to preload the game but it will only run on the day it is released. But, you still have to make sure not all your customers fetch the content at the same time with full speed. And what about thouse who just own a phone and no computer with iTunes? These customers will prefer to download over wifi as fast as possible to get the upgrade done. Preloading over anything other than wifi is way to expensive. Someone mentioned Win8/8.1 and Upgrades, there will also be OSX Mavericks quite soon. Fewer devices but way more content ... Access is sold by bandwith, so there will be oversubscrition. Sell it by traffic and all thouse iPhone users will walk to the neares Apple store to buy an USB stick with the upgrade since its cheaper than downloading it. rm From simon.leinen at switch.ch Mon Sep 23 13:10:05 2013 From: simon.leinen at switch.ch (Simon Leinen) Date: Mon, 23 Sep 2013 15:10:05 +0200 Subject: iOS 7 update traffic In-Reply-To: (Glen Kent's message of "Mon, 23 Sep 2013 17:44:08 +0530") References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: Glen Kent writes: > One of the earlier posts seems to suggest that if iOS updates were > cached on the ISPs CDN server then the traffic would have been > manageable since everybody would only contact the local sever to get > the image. Is this assumption correct? Not necessarily. I think most of the iOS 7 update traffic WAS in fact delivered from CDN servers (in particular Akamai). And many/most large service providers already have Akamai servers in their networks. But they may not have enough spare capacity for such a sudden demand - either in terms of CDN (Akamai) servers or in terms of capacity between their CDN servers and their customers. > Do most big service providers maintain their own content servers? Is > this what we're heading to these days? Depends on what you mean by "their own". As I said, these days Akamai has servers in many of the big networks. Google and possibly others (Limelight, ...?) might have that as well. But I wouldn't call them "their [the SPs'] own". Some SPs are also built their own CDNs (Level 3) or are talking about it. But that model seems to be less popular with the content owners and the other SPs. -- Simon. From gih at apnic.net Mon Sep 23 13:28:58 2013 From: gih at apnic.net (Geoff Huston) Date: Mon, 23 Sep 2013 23:28:58 +1000 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <52401178.3000500@foobar.org> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> Message-ID: On 23/09/2013, at 8:01 PM, Nick Hilliard wrote: > On 23/09/2013 00:15, John Curran wrote: >> Not being able to use 32-bit ASNs in your network and support systems will >> inevitably lead to confusion for those customers who are assigned them. > > I look forward to the day when we have proper 32 bit BGP community support > and ASN32s finally become usable on nontrivial networks. > Is there some reference that describes the problems with the use of RFC5668? I was not aware that there were residual issues here. regards, Geoff From bicknell at ufp.org Mon Sep 23 13:41:02 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 Sep 2013 08:41:02 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: On Sep 23, 2013, at 8:10 AM, Simon Leinen wrote: > Not necessarily. I think most of the iOS 7 update traffic WAS in fact > delivered from CDN servers (in particular Akamai). And many/most large > service providers already have Akamai servers in their networks. But > they may not have enough spare capacity for such a sudden demand - > either in terms of CDN (Akamai) servers or in terms of capacity between > their CDN servers and their customers. Apple claims 200 million[1] IOS devices upgrade to version 7 in the past week. A typical download was on the order of 800MB. At the same time, Apple released some other updates, like OSX 10.8.5[2] (275MB) and XCode 5.0[3] (2GB). They also made the iWork and iLife applications (Pages, Numbers, Keynote iMovie, and iPhoto) free to download[4] for all new IOS purchasers. Oh, and they sold 9 million iPhone 5s/c devices[1], most of which needed an update to IOS 7.0.1[5] which was a 1.2GB download. With all of that going on the grumbling on NANOG has pretty much been limited to "yeah, we saw a spike", and a few providers of alternative technologies (like Satellite) grousing a bit. I'm not saying the industry can't do better, but I'm finding it hard to describe what happened as anything besides a success for CDN's and most consumer facing ISP's. I only hope the various CDN's and ISP's study what happened so they can be prepared for the next event, which will no doubt be bigger. We're all in an "up and to the right" industry. 1: http://9to5mac.com/2013/09/23/apple-announces-9-million-iphone-sales-over-first-three-days/ 2: http://support.apple.com/kb/DL1675 3: http://9to5mac.com/2013/09/18/xcode-5-0-released-with-ios-7-sdk-64-bit-app-compiler/ 4: http://9to5mac.com/2013/09/10/apple-makes-iwork-apps-iphoto-and-imovie-free-with-all-new-ios-devices/ 5: http://support.apple.com/kb/DL1683 -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From glen.kent at gmail.com Mon Sep 23 13:41:45 2013 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 23 Sep 2013 19:11:45 +0530 Subject: iOS 7 update traffic In-Reply-To: <52401F2F.8010209@tonal.clara.co.uk> References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: BTW Linux distributions are available to download via bittorrent, so we dont really need Akamai/Limelight here. Is there a reason why Apple has not adopted bit-torrent for distribution? Are there legal/commercial implications using bit-torrent? Glen On Mon, Sep 23, 2013 at 4:29 PM, Neil Harris wrote: > On 23/09/13 10:32, John Smith wrote: > >> Picked this off www.jaluri.com (network and Cisco blog aggregator): >> >> http://routingfreak.wordpress.**com/2013/09/23/ios7s-impact-** >> on-networks-worldwide/ >> >> The consensus seems to be for providers to install CDN servers, if they >> arent able to cope up with an occasional OS update traffic. >> >> http://news.idg.no/cw/art.cfm?**id=391B4B64-F693-41B7-**6BBAC6D7017C3B8A >> >> John >> >> > Perhaps Apple, Microsoft etc. should consider using Bittorrent as a way of > distributing their updates? If ISPs were to run their own Bittorrent > servers (with appropriate restrictions, see below), this would then create > an instant CDN, with no need to define any other protocols or pay any third > parties. > > The hard bit would be to create a way for Apple etc. to be able to > authoritatively say "we are the content owners, and are happy for you to > replicate this locally": but perhaps this could be as simple serving the > initial seed from an HTTPS server with a valid certificate? It would then > be trivial to create a whitelist of the domains of the top 10 or so > distributors of patches, and then everything would work automatically from > then on. > > -- N. > > > From jabley at hopcount.ca Mon Sep 23 13:50:02 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 23 Sep 2013 09:50:02 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: On 2013-09-23, at 09:10, Simon Leinen wrote: > Glen Kent writes: >> One of the earlier posts seems to suggest that if iOS updates were >> cached on the ISPs CDN server then the traffic would have been >> manageable since everybody would only contact the local sever to get >> the image. Is this assumption correct? > > Not necessarily. I think most of the iOS 7 update traffic WAS in fact > delivered from CDN servers (in particular Akamai). And many/most large > service providers already have Akamai servers in their networks. But > they may not have enough spare capacity for such a sudden demand - > either in terms of CDN (Akamai) servers or in terms of capacity between > their CDN servers and their customers. I think oversubscription in the access network (between the customer and the ISP network that might contain Akamai nodes) is the general concern, at least from the ISPs I have visibility into. Your access network doesn't have to be a narrowband satellite network for this kind of unexpected demand to hurt, and provisioning extra access bandwidth in anticipation of a one- or two-day possibility of increased demand is not practical. I don't doubt Apple are aware of the issue and will make changes if they can. The characterisation that Apple doesn't care, or is callously causing pain in other networks ignores the commercial reality that user experience is important to them. The user experience when an anticipated update can't be downloaded easily is not great. The suggestions on how to make things better next time that have appeared on this list seem helpful. I would imagine that any vendor with a huge and widely-distributed user base would do well to take note. Joe From cabo at tzi.org Mon Sep 23 13:50:30 2013 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 23 Sep 2013 15:50:30 +0200 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: <46138D91-D23F-470D-BC56-C417BFB5509F@tzi.org> On Sep 23, 2013, at 15:10, Simon Leinen wrote: > Glen Kent writes: >> One of the earlier posts seems to suggest that if iOS updates were >> cached on the ISPs CDN server then the traffic would have been >> manageable since everybody would only contact the local sever to get >> the image. Is this assumption correct? > > Not necessarily. I think most of the iOS 7 update traffic WAS in fact > delivered from CDN servers (in particular Akamai). And many/most large > service providers already have Akamai servers in their networks. But > they may not have enough spare capacity for such a sudden demand - > either in terms of CDN (Akamai) servers or in terms of capacity between > their CDN servers and their customers. I have some anecdotal evidence that a large swatch of Telekom land in Germany was fed from two (2) Limelight servers in Frankfurt (?). Of course, packet loss to them during Wednesday evening was around 50 %. (I VPNed out of Telekom land to get my iOS 7 update, which was then no problem at all; that clearly shows that the access infrastructure wasn't overloaded.) It doesn't help that Apple's update software has no way to make use of the results of a prematurely aborted transfer; this is a recipe for bistable behavior. Gr??e, Carsten From jared at puck.nether.net Mon Sep 23 13:50:57 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 23 Sep 2013 09:50:57 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: On Sep 23, 2013, at 9:41 AM, Glen Kent wrote: > BTW Linux distributions are available to download via bittorrent, so we > dont really need Akamai/Limelight here. Is there a reason why Apple has not > adopted bit-torrent for distribution? Are there legal/commercial > implications using bit-torrent? It's more about predictable results and outcome. I can pay a CDN and likely get some sort of reporting/SLA. I can't as easily insure that my torrent traffic will work as well. Some carriers dabbled in doing something about peer-to-peer/torrent type traffic in the past, such as the P4P stuff: http://www.datacenterknowledge.com/archives/2008/03/14/verizon-testing-p4p-for-peer-to-peer-delivery/ But I think it died off like many other things. I think CNN.com video still wants the peer-to-peer octoshape thing, but I have always said NO. https://www.google.com/search?q=octoshape+peer+to+peer while an older article from 2009, here's why you should say no as well: http://arstechnica.com/business/2009/02/cnn-p2p-video-streaming-tech-raises-questions/ - Jared From jeroen at massar.ch Mon Sep 23 13:58:59 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 23 Sep 2013 15:58:59 +0200 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: <52404923.1020208@massar.ch> On 2013-09-23 15:41 , Glen Kent wrote: > BTW Linux distributions are available to download via bittorrent, I am very sure that you will be happy to see your customer's UPSTREAM links filled with that traffic... next to you having a shiny CDN and then having to do traffic to ISPs who do not have one... IMHO the model with CDN is appropriate for this kind of traffic: the pusher is footing the bill. Greets, Jeroen From job.snijders at atrato.com Mon Sep 23 14:02:04 2013 From: job.snijders at atrato.com (Job Snijders) Date: Mon, 23 Sep 2013 16:02:04 +0200 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> Message-ID: <20130923140204.GJ339@Elise.local> On Mon, Sep 23, 2013 at 11:28:58PM +1000, Geoff Huston wrote: > On 23/09/2013, at 8:01 PM, Nick Hilliard wrote: > > > I look forward to the day when we have proper 32 bit BGP community > > support and ASN32s finally become usable on nontrivial networks. > > > > Is there some reference that describes the problems with the use of > RFC5668? I was not aware that there were residual issues here. It would've been really nice if one could fit more than 16 bit in the locally administrated part. Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From jabley at hopcount.ca Mon Sep 23 14:02:09 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 23 Sep 2013 10:02:09 -0400 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: On 2013-09-23, at 09:41, Glen Kent wrote: > BTW Linux distributions are available to download via bittorrent, so we > dont really need Akamai/Limelight here. Is there a reason why Apple has not > adopted bit-torrent for distribution? Are there legal/commercial > implications using bit-torrent? There are upstream congestion issues frequently associated with bittorrent. If you compare (a) five thousand students on a campus wifi network trying to download a 1GB image from a nearby Akamai cache, and (b) five thousand students on a campus wifi network seeding a 1GB image to people all over the world it's not obvious that more pain results from (a) than (b). Even given the ability of Apple to control the behaviour of the bittorrent agent (which presumably would be built into iOS) the impact of such a strategy on an event of this size seems very hard to predict, given a narrow time base and an unknowable number of local network constraints. It doesn't seem impossible to try and optimise the fan-out by giving network operators hooks to influence peer selection based on local topology. But it also doesn't sound like an easy general problem to solve (or a problem that anybody necessarily wants to spend money on if the relief is only going to be felt once per year on major iOS updates). (Remember as well that the scale here is very different. With iOS, Apple is the major Unix vendor on the planet by some margin. No other single Linux or other Unix/Unix-like distribution comes close, and I am guessing no single operating system triggers the update enthusiasm observed with iOS.) Joe From gih at apnic.net Mon Sep 23 14:14:21 2013 From: gih at apnic.net (Geoff Huston) Date: Tue, 24 Sep 2013 00:14:21 +1000 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <20130923140204.GJ339@Elise.local> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> <20130923140204.GJ339@Elise.local> Message-ID: On 24/09/2013, at 12:02 AM, Job Snijders wrote: > On Mon, Sep 23, 2013 at 11:28:58PM +1000, Geoff Huston wrote: > >> On 23/09/2013, at 8:01 PM, Nick Hilliard wrote: >> >>> I look forward to the day when we have proper 32 bit BGP community >>> support and ASN32s finally become usable on nontrivial networks. >>> >> >> Is there some reference that describes the problems with the use of >> RFC5668? I was not aware that there were residual issues here. > > It would've been really nice if one could fit more than 16 bit in the > locally administrated part. > > Kind regards, > > Job I'm sorry, but I'm still confused, as I see your comment as one that relates to the size of the payload field here, as distinct from the support for 32 bit AS numbers per se. Geoff From nick at foobar.org Mon Sep 23 14:21:45 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Sep 2013 15:21:45 +0100 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> <20130923140204.GJ339@Elise.local> Message-ID: <52404E79.4050408@foobar.org> On 23/09/2013 15:14, Geoff Huston wrote: > I'm sorry, but I'm still confused, as I see your comment as one that relates to the > size of the payload field here, as distinct from the support for 32 bit AS numbers > per se. hence my original comment about being usable on nontrivial transit networks, where having the size of the community local administrator >= your customer asn bitfield size is a rather useful feature. There's also a serious vendor support problem at the moment. Nick From Ben.Kessler at zenetra.com Mon Sep 23 14:30:50 2013 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Mon, 23 Sep 2013 14:30:50 +0000 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <52404E79.4050408@foobar.org> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> <20130923140204.GJ339@Elise.local> <52404E79.4050408@foobar.org> Message-ID: <0CFF54003CD92945994CF0C0F90D81B65E1C1FA7@EXCH1-FWA1.zenetra.local> I'd like to see an option for a larger private ASN block - 1K of private ASNs can be quite a pain in really large organizations. I have seen others mention this in the past - e.g. http://www.gossamer-threads.com/lists/cisco/nsp/158375 But apparently there's not enough traction to cause movement. -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Monday, September 23, 2013 10:22 AM To: Geoff Huston Cc: nanog at nanog.org list Subject: Re: 32-bit ASN acceptance by ISPs in ARIN region On 23/09/2013 15:14, Geoff Huston wrote: > I'm sorry, but I'm still confused, as I see your comment as one that > relates to the size of the payload field here, as distinct from the > support for 32 bit AS numbers per se. hence my original comment about being usable on nontrivial transit networks, where having the size of the community local administrator >= your customer asn bitfield size is a rather useful feature. There's also a serious vendor support problem at the moment. Nick From ikiris at gmail.com Mon Sep 23 14:31:32 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 23 Sep 2013 09:31:32 -0500 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: Bit torrent is a way to lighten the load on the originator, and to increase the speed of the acquisition from the receivers. It is not a tool to decrease network load, if anything it does the opposite most of the time. Every now and then, a client will find a local network peer, but its usually an accident more than anything from the algorithm it uses to try to find the fastest senders with pieces it needs. This is most often a product of far end congestion and what pieces are completed, and rarely upstream related barring major issues. The algorithim is self greedy, not altruistic, and definitely not written with ISP load issues in mind. I'd much prefer CDN content over bittorrent from the ISP side. -Blake On Mon, Sep 23, 2013 at 9:02 AM, Joe Abley wrote: > > On 2013-09-23, at 09:41, Glen Kent wrote: > > > BTW Linux distributions are available to download via bittorrent, so we > > dont really need Akamai/Limelight here. Is there a reason why Apple has > not > > adopted bit-torrent for distribution? Are there legal/commercial > > implications using bit-torrent? > > There are upstream congestion issues frequently associated with > bittorrent. If you compare > > (a) five thousand students on a campus wifi network trying to download a > 1GB image from a nearby Akamai cache, and > > (b) five thousand students on a campus wifi network seeding a 1GB image to > people all over the world > > it's not obvious that more pain results from (a) than (b). > > Even given the ability of Apple to control the behaviour of the bittorrent > agent (which presumably would be built into iOS) the impact of such a > strategy on an event of this size seems very hard to predict, given a > narrow time base and an unknowable number of local network constraints. > > It doesn't seem impossible to try and optimise the fan-out by giving > network operators hooks to influence peer selection based on local > topology. But it also doesn't sound like an easy general problem to solve > (or a problem that anybody necessarily wants to spend money on if the > relief is only going to be felt once per year on major iOS updates). > > (Remember as well that the scale here is very different. With iOS, Apple > is the major Unix vendor on the planet by some margin. No other single > Linux or other Unix/Unix-like distribution comes close, and I am guessing > no single operating system triggers the update enthusiasm observed with > iOS.) > > > Joe > > > From nick at foobar.org Mon Sep 23 14:35:47 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Sep 2013 15:35:47 +0100 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <0CFF54003CD92945994CF0C0F90D81B65E1C1FA7@EXCH1-FWA1.zenetra.local> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> <20130923140204.GJ339@Elise.local> <52404E79.4050408@foobar.org> <0CFF54003CD92945994CF0C0F90D81B65E1C1FA7@EXCH1-FWA1.zenetra.local> Message-ID: <524051C3.4050905@foobar.org> On 23/09/2013 15:30, R. Benjamin Kessler wrote: > I'd like to see an option for a larger private ASN block - 1K of private ASNs can be quite a pain in really large organizations. > > I have seen others mention this in the past - e.g. > http://www.gossamer-threads.com/lists/cisco/nsp/158375 > > But apparently there's not enough traction to cause movement. For 32 bit ASNs, there's RFC 6996. If you're looking for more 16 bit private ASNs, you've missed the boat: they're all gone. Nick From leo.vegoda at icann.org Mon Sep 23 14:41:44 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 23 Sep 2013 07:41:44 -0700 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: <0CFF54003CD92945994CF0C0F90D81B65E1C1FA7@EXCH1-FWA1.zenetra.local> References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> <20130923140204.GJ339@Elise.local> <52404E79.4050408@foobar.org> <0CFF54003CD92945994CF0C0F90D81B65E1C1FA7@EXCH1-FWA1.zenetra.local> Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E16F6072@EXVPMBX100-1.exc.icann.org> Hi, R. Benjamin Kessler wrote: > I'd like to see an option for a larger private ASN block - > 1K of private ASNs can be quite a pain in really large organizations. > > I have seen others mention this in the past - e.g. > http://www.gossamer-threads.com/lists/cisco/nsp/158375 > > But apparently there's not enough traction to cause movement. In the 32-bit space there is: 4200000000-4294967294 Reserved for Private Use [RFC6996] which is considerably more than 1,000. The remaining unallocated 16-bit AS Numbers are 64000-64495. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Sep 23 14:46:13 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Sep 2013 10:46:13 -0400 Subject: 32-bit ASN acceptance by ISPs in ARIN region In-Reply-To: Your message of "Mon, 23 Sep 2013 23:28:58 +1000." References: <201309201851.r8KIp0eZ029012@thyme.rand.apnic.net> <9775F10E-933D-423D-A03F-10C32D923330@corp.arin.net> <52401178.3000500@foobar.org> Message-ID: <184733.1379947573@turing-police.cc.vt.edu> On Mon, 23 Sep 2013 23:28:58 +1000, Geoff Huston said: > Is there some reference that describes the problems with the use of RFC5668? > I was not aware that there were residual issues here. I wonder what the correlation is between sites that haven't deployed 5668, sites that haven't deployed IPv6, and sites that haven't deployed BCP38. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Mon Sep 23 16:13:50 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 23 Sep 2013 12:13:50 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: Message-ID: <13298057.8383.1379952830468.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > To: "Paul Ferguson" > On Thu, 19 Sep 2013, Paul Ferguson wrote: > > Can someone please explain to a non-Apple person what the hell happened > > that started generating so much traffic? Perhaps I missed it in this > > thread, but I would be curious to know what iOS 7 implemented that > > caused this... > > The IOS7 upgrade is ~750 megabyte download for the phones/pods, and ~950 > megabytes for ipad. There are quite a few devices out there times > these amounts to download... It wasn't sinister, Ferg, it was *stupid*. *They announced the release date and time*. Everyone's phone has a "check for release now" button, and yet they believed that only *push notifying* phones in waves would be enough to prevent what happened. See also: screwed the pooch. This went out, what, last Weds and Thu? I had half a dozen people from all different environments ask me "why's the Internet broke today?" on release day. There was a consumer-visible impact from this absolutely asinine release engineering project on Apple's part. You don't announce the exact release time, and you don't even *make the release visible to all devices at the same time* since Twitter. This is apparently their first rodeo. We should take pains to make it their last. As an anti-Apple guy, I resent having my stuff screwed up because of it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From dharmachris at gmail.com Mon Sep 23 16:55:22 2013 From: dharmachris at gmail.com (Christopher Hunt) Date: Mon, 23 Sep 2013 09:55:22 -0700 Subject: d6991.com traffic Message-ID: Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. 75% of the traffic is for d6991.com. Does anyone else see this? Who are these folks (WEBNIC.CC)? -chris From fergdawgster at mykolab.com Mon Sep 23 17:09:16 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 23 Sep 2013 10:09:16 -0700 Subject: d6991.com traffic In-Reply-To: References: Message-ID: <524075BC.6000408@mykolab.com> On 9/23/2013 9:55 AM, Christopher Hunt wrote: > Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. > 75% of the traffic is for d6991.com. Does anyone else see this? Who are > these folks (WEBNIC.CC)? > Maybe because of this mess? ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.7.3 <<>> @localhost d6991.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61549 ;; flags: qr rd ra; QUERY: 1, ANSWER: 256, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;d6991.com. IN A ;; ANSWER SECTION: d6991.com. 6000 IN A 121.100.153.100 d6991.com. 6000 IN A 121.100.153.101 d6991.com. 6000 IN A 121.100.153.102 d6991.com. 6000 IN A 121.100.153.103 d6991.com. 6000 IN A 121.100.153.104 d6991.com. 6000 IN A 121.100.153.105 d6991.com. 6000 IN A 121.100.153.106 d6991.com. 6000 IN A 121.100.153.107 d6991.com. 6000 IN A 121.100.153.108 d6991.com. 6000 IN A 121.100.153.109 d6991.com. 6000 IN A 121.100.153.110 d6991.com. 6000 IN A 121.100.153.111 d6991.com. 6000 IN A 121.100.153.112 d6991.com. 6000 IN A 121.100.153.113 d6991.com. 6000 IN A 121.100.153.114 d6991.com. 6000 IN A 121.100.153.115 d6991.com. 6000 IN A 121.100.153.116 d6991.com. 6000 IN A 121.100.153.117 d6991.com. 6000 IN A 121.100.153.118 d6991.com. 6000 IN A 121.100.153.119 d6991.com. 6000 IN A 121.100.153.120 d6991.com. 6000 IN A 121.100.153.121 d6991.com. 6000 IN A 121.100.153.122 d6991.com. 6000 IN A 121.100.153.123 d6991.com. 6000 IN A 121.100.153.124 d6991.com. 6000 IN A 121.100.153.125 d6991.com. 6000 IN A 121.100.153.126 d6991.com. 6000 IN A 121.100.153.127 d6991.com. 6000 IN A 121.100.153.128 d6991.com. 6000 IN A 121.100.153.129 d6991.com. 6000 IN A 121.100.153.130 d6991.com. 6000 IN A 121.100.153.131 d6991.com. 6000 IN A 121.100.153.132 d6991.com. 6000 IN A 121.100.153.133 d6991.com. 6000 IN A 121.100.153.134 d6991.com. 6000 IN A 121.100.153.135 d6991.com. 6000 IN A 121.100.153.136 d6991.com. 6000 IN A 121.100.153.137 d6991.com. 6000 IN A 121.100.153.138 d6991.com. 6000 IN A 121.100.153.139 d6991.com. 6000 IN A 121.100.153.140 d6991.com. 6000 IN A 121.100.153.141 d6991.com. 6000 IN A 121.100.153.142 d6991.com. 6000 IN A 121.100.153.143 d6991.com. 6000 IN A 121.100.153.144 d6991.com. 6000 IN A 121.100.153.145 d6991.com. 6000 IN A 121.100.153.146 d6991.com. 6000 IN A 121.100.153.147 d6991.com. 6000 IN A 121.100.153.148 d6991.com. 6000 IN A 121.100.153.149 d6991.com. 6000 IN A 121.100.153.150 d6991.com. 6000 IN A 121.100.153.151 d6991.com. 6000 IN A 121.100.153.152 d6991.com. 6000 IN A 121.100.153.153 d6991.com. 6000 IN A 121.100.153.154 d6991.com. 6000 IN A 121.100.153.155 d6991.com. 6000 IN A 121.100.153.156 d6991.com. 6000 IN A 121.100.153.157 d6991.com. 6000 IN A 121.100.153.158 d6991.com. 6000 IN A 121.100.153.159 d6991.com. 6000 IN A 121.100.153.160 d6991.com. 6000 IN A 121.100.153.161 d6991.com. 6000 IN A 121.100.153.162 d6991.com. 6000 IN A 121.100.153.163 d6991.com. 6000 IN A 121.100.153.164 d6991.com. 6000 IN A 121.100.153.165 d6991.com. 6000 IN A 121.100.153.166 d6991.com. 6000 IN A 121.100.153.167 d6991.com. 6000 IN A 121.100.153.168 d6991.com. 6000 IN A 121.100.153.169 d6991.com. 6000 IN A 121.100.153.170 d6991.com. 6000 IN A 121.100.153.171 d6991.com. 6000 IN A 121.100.153.172 d6991.com. 6000 IN A 121.100.153.173 d6991.com. 6000 IN A 121.100.153.174 d6991.com. 6000 IN A 121.100.153.175 d6991.com. 6000 IN A 121.100.153.176 d6991.com. 6000 IN A 121.100.153.177 d6991.com. 6000 IN A 121.100.153.178 d6991.com. 6000 IN A 121.100.153.179 d6991.com. 6000 IN A 121.100.153.180 d6991.com. 6000 IN A 121.100.153.181 d6991.com. 6000 IN A 121.100.153.182 d6991.com. 6000 IN A 121.100.153.183 d6991.com. 6000 IN A 121.100.153.184 d6991.com. 6000 IN A 121.100.153.185 d6991.com. 6000 IN A 121.100.153.186 d6991.com. 6000 IN A 121.100.153.187 d6991.com. 6000 IN A 121.100.153.188 d6991.com. 6000 IN A 121.100.153.189 d6991.com. 6000 IN A 121.100.153.190 d6991.com. 6000 IN A 121.100.153.191 d6991.com. 6000 IN A 121.100.153.192 d6991.com. 6000 IN A 121.100.153.193 d6991.com. 6000 IN A 121.100.153.194 d6991.com. 6000 IN A 121.100.153.195 d6991.com. 6000 IN A 121.100.153.196 d6991.com. 6000 IN A 121.100.153.197 d6991.com. 6000 IN A 121.100.153.198 d6991.com. 6000 IN A 121.100.153.199 d6991.com. 6000 IN A 121.100.153.200 d6991.com. 6000 IN A 121.100.152.100 d6991.com. 6000 IN A 121.100.152.101 d6991.com. 6000 IN A 121.100.152.102 d6991.com. 6000 IN A 121.100.152.103 d6991.com. 6000 IN A 121.100.152.104 d6991.com. 6000 IN A 121.100.152.105 d6991.com. 6000 IN A 121.100.152.106 d6991.com. 6000 IN A 121.100.152.107 d6991.com. 6000 IN A 121.100.152.108 d6991.com. 6000 IN A 121.100.152.109 d6991.com. 6000 IN A 121.100.152.110 d6991.com. 6000 IN A 121.100.152.111 d6991.com. 6000 IN A 121.100.152.112 d6991.com. 6000 IN A 121.100.152.113 d6991.com. 6000 IN A 121.100.152.114 d6991.com. 6000 IN A 121.100.152.115 d6991.com. 6000 IN A 121.100.152.116 d6991.com. 6000 IN A 121.100.152.117 d6991.com. 6000 IN A 121.100.152.118 d6991.com. 6000 IN A 121.100.152.119 d6991.com. 6000 IN A 121.100.152.120 d6991.com. 6000 IN A 121.100.152.121 d6991.com. 6000 IN A 121.100.152.122 d6991.com. 6000 IN A 121.100.152.123 d6991.com. 6000 IN A 121.100.152.124 d6991.com. 6000 IN A 121.100.152.125 d6991.com. 6000 IN A 121.100.152.126 d6991.com. 6000 IN A 121.100.152.127 d6991.com. 6000 IN A 121.100.152.128 d6991.com. 6000 IN A 121.100.152.129 d6991.com. 6000 IN A 121.100.152.130 d6991.com. 6000 IN A 121.100.152.131 d6991.com. 6000 IN A 121.100.152.132 d6991.com. 6000 IN A 121.100.152.133 d6991.com. 6000 IN A 121.100.152.134 d6991.com. 6000 IN A 121.100.152.135 d6991.com. 6000 IN A 121.100.152.136 d6991.com. 6000 IN A 121.100.152.137 d6991.com. 6000 IN A 121.100.152.138 d6991.com. 6000 IN A 121.100.152.139 d6991.com. 6000 IN A 121.100.152.140 d6991.com. 6000 IN A 121.100.152.141 d6991.com. 6000 IN A 121.100.152.142 d6991.com. 6000 IN A 121.100.152.143 d6991.com. 6000 IN A 121.100.152.144 d6991.com. 6000 IN A 121.100.152.145 d6991.com. 6000 IN A 121.100.152.146 d6991.com. 6000 IN A 121.100.152.147 d6991.com. 6000 IN A 121.100.152.148 d6991.com. 6000 IN A 121.100.152.149 d6991.com. 6000 IN A 121.100.152.150 d6991.com. 6000 IN A 121.100.152.151 d6991.com. 6000 IN A 121.100.152.152 d6991.com. 6000 IN A 121.100.152.153 d6991.com. 6000 IN A 121.100.152.154 d6991.com. 6000 IN A 121.100.152.155 d6991.com. 6000 IN A 121.100.152.156 d6991.com. 6000 IN A 121.100.152.157 d6991.com. 6000 IN A 121.100.152.158 d6991.com. 6000 IN A 121.100.152.159 d6991.com. 6000 IN A 121.100.152.160 d6991.com. 6000 IN A 121.100.152.161 d6991.com. 6000 IN A 121.100.152.162 d6991.com. 6000 IN A 121.100.152.163 d6991.com. 6000 IN A 121.100.152.164 d6991.com. 6000 IN A 121.100.152.165 d6991.com. 6000 IN A 121.100.152.166 d6991.com. 6000 IN A 121.100.152.167 d6991.com. 6000 IN A 121.100.152.168 d6991.com. 6000 IN A 121.100.152.169 d6991.com. 6000 IN A 121.100.152.170 d6991.com. 6000 IN A 121.100.152.171 d6991.com. 6000 IN A 121.100.152.172 d6991.com. 6000 IN A 121.100.152.173 d6991.com. 6000 IN A 121.100.152.174 d6991.com. 6000 IN A 121.100.152.175 d6991.com. 6000 IN A 121.100.152.176 d6991.com. 6000 IN A 121.100.152.177 d6991.com. 6000 IN A 121.100.152.178 d6991.com. 6000 IN A 121.100.152.179 d6991.com. 6000 IN A 121.100.152.180 d6991.com. 6000 IN A 121.100.152.181 d6991.com. 6000 IN A 121.100.152.182 d6991.com. 6000 IN A 121.100.152.183 d6991.com. 6000 IN A 121.100.152.184 d6991.com. 6000 IN A 121.100.152.185 d6991.com. 6000 IN A 121.100.152.186 d6991.com. 6000 IN A 121.100.152.187 d6991.com. 6000 IN A 121.100.152.188 d6991.com. 6000 IN A 121.100.152.189 d6991.com. 6000 IN A 121.100.152.190 d6991.com. 6000 IN A 121.100.152.191 d6991.com. 6000 IN A 121.100.152.192 d6991.com. 6000 IN A 121.100.152.193 d6991.com. 6000 IN A 121.100.152.194 d6991.com. 6000 IN A 121.100.152.195 d6991.com. 6000 IN A 121.100.152.196 d6991.com. 6000 IN A 121.100.152.197 d6991.com. 6000 IN A 121.100.152.198 d6991.com. 6000 IN A 121.100.152.199 d6991.com. 6000 IN A 121.100.152.200 d6991.com. 6000 IN A 121.100.152.201 d6991.com. 6000 IN A 121.100.152.202 d6991.com. 6000 IN A 121.100.152.203 d6991.com. 6000 IN A 121.100.152.204 d6991.com. 6000 IN A 121.100.152.205 d6991.com. 6000 IN A 121.100.152.206 d6991.com. 6000 IN A 121.100.152.207 d6991.com. 6000 IN A 121.100.152.208 d6991.com. 6000 IN A 121.100.152.209 d6991.com. 6000 IN A 121.100.152.210 d6991.com. 6000 IN A 121.100.152.211 d6991.com. 6000 IN A 121.100.152.212 d6991.com. 6000 IN A 121.100.152.213 d6991.com. 6000 IN A 121.100.152.214 d6991.com. 6000 IN A 121.100.152.215 d6991.com. 6000 IN A 121.100.152.216 d6991.com. 6000 IN A 121.100.152.217 d6991.com. 6000 IN A 121.100.152.218 d6991.com. 6000 IN A 121.100.152.219 d6991.com. 6000 IN A 121.100.152.220 d6991.com. 6000 IN A 121.100.152.221 d6991.com. 6000 IN A 121.100.152.222 d6991.com. 6000 IN A 121.100.152.223 d6991.com. 6000 IN A 121.100.152.224 d6991.com. 6000 IN A 121.100.152.225 d6991.com. 6000 IN A 121.100.152.226 d6991.com. 6000 IN A 121.100.152.227 d6991.com. 6000 IN A 121.100.152.228 d6991.com. 6000 IN A 121.100.152.229 d6991.com. 6000 IN A 121.100.152.230 d6991.com. 6000 IN A 121.100.152.231 d6991.com. 6000 IN A 121.100.152.232 d6991.com. 6000 IN A 121.100.152.233 d6991.com. 6000 IN A 121.100.152.234 d6991.com. 6000 IN A 121.100.152.235 d6991.com. 6000 IN A 121.100.152.236 d6991.com. 6000 IN A 121.100.152.237 d6991.com. 6000 IN A 121.100.152.238 d6991.com. 6000 IN A 121.100.152.239 d6991.com. 6000 IN A 121.100.152.240 d6991.com. 6000 IN A 121.100.152.241 d6991.com. 6000 IN A 121.100.152.242 d6991.com. 6000 IN A 121.100.152.243 d6991.com. 6000 IN A 121.100.152.244 d6991.com. 6000 IN A 121.100.152.245 d6991.com. 6000 IN A 121.100.152.246 d6991.com. 6000 IN A 121.100.152.247 d6991.com. 6000 IN A 121.100.152.248 d6991.com. 6000 IN A 121.100.152.249 d6991.com. 6000 IN A 121.100.152.250 d6991.com. 6000 IN A 121.100.152.251 d6991.com. 6000 IN A 121.100.152.252 d6991.com. 6000 IN A 121.100.152.253 d6991.com. 6000 IN A 121.100.152.254 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Sep 23 19:06:40 2013 ;; MSG SIZE rcvd: 4123 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html % Information related to '121.100.128.0 - 121.100.191.255' inetnum: 121.100.128.0 - 121.100.191.255 netname: YanYang-network descr: Beijing Yan Yang Century Science & Technology Co., LTD descr: 9-605 Xuhuiaodu, Lishuiqiao south, Chaoyang District, Beijing country: CN admin-c: ZM675-AP tech-c: ZM676-AP mnt-by: MAINT-CNNIC-AP mnt-lower: MAINT-CNNIC-AP mnt-routes: MAINT-CNNIC-AP mnt-irt: IRT-CNNIC-CN status: ALLOCATED PORTABLE changed: ipas at cnnic.net 20110610 source: APNIC irt: IRT-CNNIC-CN address: Beijing, China e-mail: ipas at cnnic.cn abuse-mailbox: ipas at cnnic.cn admin-c: IP50-AP tech-c: IP50-AP auth: # Filtered remarks: Please note that CNNIC is not an ISP and is not remarks: empowered to investigate complaints of network abuse. remarks: Please contact the tech-c or admin-c of the network. mnt-by: MAINT-CNNIC-AP changed: ipas at cnnic.cn 20110428 source: APNIC person: Yanqing Xiao address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District address: Beijing, China, 100012 country: CN phone: +86-18600090096 fax-no: +86-010- 59456518 e-mail: xiaoyanqingvp at 126.com nic-hdl: ZM675-AP mnt-by: MAINT-CNNIC-AP changed: ipas at cnnic.net 20110609 source: APNIC person: Jian Zhou address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District address: Beijing, China, 100012 country: CN phone: +86-18611086106 fax-no: +86-010- 59456518 e-mail: sxbjzj at 163.com nic-hdl: ZM676-AP mnt-by: MAINT-CNNIC-AP changed: ipas at cnnic.net 20110609 source: APNIC % Information related to '121.100.128.0/19AS4837' route: 121.100.128.0/19 descr: CNC Group CHINA169 Shan1xi Province Network descr: Addresses from CNNIC country: CN origin: AS4837 mnt-by: MAINT-CNCGROUP-RR changed: abuse at cnc-noc.net 20060926 source: APNIC % This query was served by the APNIC Whois Service version 1.68 (WHOIS3) - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From bmeshier at amherst.com Mon Sep 23 17:11:04 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Mon, 23 Sep 2013 17:11:04 +0000 Subject: d6991.com traffic In-Reply-To: References: Message-ID: <68C2CBC977F3E04799DF9C76E938E709081C3A5C@DFEXCH1.asglp.com> Could be DNS packet tunneling to China, bad news. https://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152 -----Original Message----- From: Christopher Hunt [mailto:dharmachris at gmail.com] Sent: Monday, September 23, 2013 11:55 AM To: nanog at nanog.org Subject: d6991.com traffic Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. 75% of the traffic is for d6991.com. Does anyone else see this? Who are these folks (WEBNIC.CC)? -chris --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From dharmachris at gmail.com Mon Sep 23 17:11:31 2013 From: dharmachris at gmail.com (Chris Hunt) Date: Mon, 23 Sep 2013 10:11:31 -0700 Subject: d6991.com traffic In-Reply-To: <524075BC.6000408@mykolab.com> References: <524075BC.6000408@mykolab.com> Message-ID: <52407643.9080306@gmail.com> That is a problem, but I'm seeing a lot of queries from residential users for what seems to me an obscure name hostied in Asia. I'm guessing some kind of bot traffic... -chris On 9/23/2013 10:09 AM, Paul Ferguson wrote: > On 9/23/2013 9:55 AM, Christopher Hunt wrote: > >> Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. >> 75% of the traffic is for d6991.com. Does anyone else see this? >> Who are >> these folks (WEBNIC.CC)? >> > > Maybe because of this mess? > > > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.7.3 <<>> @localhost d6991.com A > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61549 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 256, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;d6991.com. IN A > > ;; ANSWER SECTION: > d6991.com. 6000 IN A 121.100.153.100 > d6991.com. 6000 IN A 121.100.153.101 > d6991.com. 6000 IN A 121.100.153.102 > d6991.com. 6000 IN A 121.100.153.103 > d6991.com. 6000 IN A 121.100.153.104 > d6991.com. 6000 IN A 121.100.153.105 > d6991.com. 6000 IN A 121.100.153.106 > d6991.com. 6000 IN A 121.100.153.107 > d6991.com. 6000 IN A 121.100.153.108 > d6991.com. 6000 IN A 121.100.153.109 > d6991.com. 6000 IN A 121.100.153.110 > d6991.com. 6000 IN A 121.100.153.111 > d6991.com. 6000 IN A 121.100.153.112 > d6991.com. 6000 IN A 121.100.153.113 > d6991.com. 6000 IN A 121.100.153.114 > d6991.com. 6000 IN A 121.100.153.115 > d6991.com. 6000 IN A 121.100.153.116 > d6991.com. 6000 IN A 121.100.153.117 > d6991.com. 6000 IN A 121.100.153.118 > d6991.com. 6000 IN A 121.100.153.119 > d6991.com. 6000 IN A 121.100.153.120 > d6991.com. 6000 IN A 121.100.153.121 > d6991.com. 6000 IN A 121.100.153.122 > d6991.com. 6000 IN A 121.100.153.123 > d6991.com. 6000 IN A 121.100.153.124 > d6991.com. 6000 IN A 121.100.153.125 > d6991.com. 6000 IN A 121.100.153.126 > d6991.com. 6000 IN A 121.100.153.127 > d6991.com. 6000 IN A 121.100.153.128 > d6991.com. 6000 IN A 121.100.153.129 > d6991.com. 6000 IN A 121.100.153.130 > d6991.com. 6000 IN A 121.100.153.131 > d6991.com. 6000 IN A 121.100.153.132 > d6991.com. 6000 IN A 121.100.153.133 > d6991.com. 6000 IN A 121.100.153.134 > d6991.com. 6000 IN A 121.100.153.135 > d6991.com. 6000 IN A 121.100.153.136 > d6991.com. 6000 IN A 121.100.153.137 > d6991.com. 6000 IN A 121.100.153.138 > d6991.com. 6000 IN A 121.100.153.139 > d6991.com. 6000 IN A 121.100.153.140 > d6991.com. 6000 IN A 121.100.153.141 > d6991.com. 6000 IN A 121.100.153.142 > d6991.com. 6000 IN A 121.100.153.143 > d6991.com. 6000 IN A 121.100.153.144 > d6991.com. 6000 IN A 121.100.153.145 > d6991.com. 6000 IN A 121.100.153.146 > d6991.com. 6000 IN A 121.100.153.147 > d6991.com. 6000 IN A 121.100.153.148 > d6991.com. 6000 IN A 121.100.153.149 > d6991.com. 6000 IN A 121.100.153.150 > d6991.com. 6000 IN A 121.100.153.151 > d6991.com. 6000 IN A 121.100.153.152 > d6991.com. 6000 IN A 121.100.153.153 > d6991.com. 6000 IN A 121.100.153.154 > d6991.com. 6000 IN A 121.100.153.155 > d6991.com. 6000 IN A 121.100.153.156 > d6991.com. 6000 IN A 121.100.153.157 > d6991.com. 6000 IN A 121.100.153.158 > d6991.com. 6000 IN A 121.100.153.159 > d6991.com. 6000 IN A 121.100.153.160 > d6991.com. 6000 IN A 121.100.153.161 > d6991.com. 6000 IN A 121.100.153.162 > d6991.com. 6000 IN A 121.100.153.163 > d6991.com. 6000 IN A 121.100.153.164 > d6991.com. 6000 IN A 121.100.153.165 > d6991.com. 6000 IN A 121.100.153.166 > d6991.com. 6000 IN A 121.100.153.167 > d6991.com. 6000 IN A 121.100.153.168 > d6991.com. 6000 IN A 121.100.153.169 > d6991.com. 6000 IN A 121.100.153.170 > d6991.com. 6000 IN A 121.100.153.171 > d6991.com. 6000 IN A 121.100.153.172 > d6991.com. 6000 IN A 121.100.153.173 > d6991.com. 6000 IN A 121.100.153.174 > d6991.com. 6000 IN A 121.100.153.175 > d6991.com. 6000 IN A 121.100.153.176 > d6991.com. 6000 IN A 121.100.153.177 > d6991.com. 6000 IN A 121.100.153.178 > d6991.com. 6000 IN A 121.100.153.179 > d6991.com. 6000 IN A 121.100.153.180 > d6991.com. 6000 IN A 121.100.153.181 > d6991.com. 6000 IN A 121.100.153.182 > d6991.com. 6000 IN A 121.100.153.183 > d6991.com. 6000 IN A 121.100.153.184 > d6991.com. 6000 IN A 121.100.153.185 > d6991.com. 6000 IN A 121.100.153.186 > d6991.com. 6000 IN A 121.100.153.187 > d6991.com. 6000 IN A 121.100.153.188 > d6991.com. 6000 IN A 121.100.153.189 > d6991.com. 6000 IN A 121.100.153.190 > d6991.com. 6000 IN A 121.100.153.191 > d6991.com. 6000 IN A 121.100.153.192 > d6991.com. 6000 IN A 121.100.153.193 > d6991.com. 6000 IN A 121.100.153.194 > d6991.com. 6000 IN A 121.100.153.195 > d6991.com. 6000 IN A 121.100.153.196 > d6991.com. 6000 IN A 121.100.153.197 > d6991.com. 6000 IN A 121.100.153.198 > d6991.com. 6000 IN A 121.100.153.199 > d6991.com. 6000 IN A 121.100.153.200 > d6991.com. 6000 IN A 121.100.152.100 > d6991.com. 6000 IN A 121.100.152.101 > d6991.com. 6000 IN A 121.100.152.102 > d6991.com. 6000 IN A 121.100.152.103 > d6991.com. 6000 IN A 121.100.152.104 > d6991.com. 6000 IN A 121.100.152.105 > d6991.com. 6000 IN A 121.100.152.106 > d6991.com. 6000 IN A 121.100.152.107 > d6991.com. 6000 IN A 121.100.152.108 > d6991.com. 6000 IN A 121.100.152.109 > d6991.com. 6000 IN A 121.100.152.110 > d6991.com. 6000 IN A 121.100.152.111 > d6991.com. 6000 IN A 121.100.152.112 > d6991.com. 6000 IN A 121.100.152.113 > d6991.com. 6000 IN A 121.100.152.114 > d6991.com. 6000 IN A 121.100.152.115 > d6991.com. 6000 IN A 121.100.152.116 > d6991.com. 6000 IN A 121.100.152.117 > d6991.com. 6000 IN A 121.100.152.118 > d6991.com. 6000 IN A 121.100.152.119 > d6991.com. 6000 IN A 121.100.152.120 > d6991.com. 6000 IN A 121.100.152.121 > d6991.com. 6000 IN A 121.100.152.122 > d6991.com. 6000 IN A 121.100.152.123 > d6991.com. 6000 IN A 121.100.152.124 > d6991.com. 6000 IN A 121.100.152.125 > d6991.com. 6000 IN A 121.100.152.126 > d6991.com. 6000 IN A 121.100.152.127 > d6991.com. 6000 IN A 121.100.152.128 > d6991.com. 6000 IN A 121.100.152.129 > d6991.com. 6000 IN A 121.100.152.130 > d6991.com. 6000 IN A 121.100.152.131 > d6991.com. 6000 IN A 121.100.152.132 > d6991.com. 6000 IN A 121.100.152.133 > d6991.com. 6000 IN A 121.100.152.134 > d6991.com. 6000 IN A 121.100.152.135 > d6991.com. 6000 IN A 121.100.152.136 > d6991.com. 6000 IN A 121.100.152.137 > d6991.com. 6000 IN A 121.100.152.138 > d6991.com. 6000 IN A 121.100.152.139 > d6991.com. 6000 IN A 121.100.152.140 > d6991.com. 6000 IN A 121.100.152.141 > d6991.com. 6000 IN A 121.100.152.142 > d6991.com. 6000 IN A 121.100.152.143 > d6991.com. 6000 IN A 121.100.152.144 > d6991.com. 6000 IN A 121.100.152.145 > d6991.com. 6000 IN A 121.100.152.146 > d6991.com. 6000 IN A 121.100.152.147 > d6991.com. 6000 IN A 121.100.152.148 > d6991.com. 6000 IN A 121.100.152.149 > d6991.com. 6000 IN A 121.100.152.150 > d6991.com. 6000 IN A 121.100.152.151 > d6991.com. 6000 IN A 121.100.152.152 > d6991.com. 6000 IN A 121.100.152.153 > d6991.com. 6000 IN A 121.100.152.154 > d6991.com. 6000 IN A 121.100.152.155 > d6991.com. 6000 IN A 121.100.152.156 > d6991.com. 6000 IN A 121.100.152.157 > d6991.com. 6000 IN A 121.100.152.158 > d6991.com. 6000 IN A 121.100.152.159 > d6991.com. 6000 IN A 121.100.152.160 > d6991.com. 6000 IN A 121.100.152.161 > d6991.com. 6000 IN A 121.100.152.162 > d6991.com. 6000 IN A 121.100.152.163 > d6991.com. 6000 IN A 121.100.152.164 > d6991.com. 6000 IN A 121.100.152.165 > d6991.com. 6000 IN A 121.100.152.166 > d6991.com. 6000 IN A 121.100.152.167 > d6991.com. 6000 IN A 121.100.152.168 > d6991.com. 6000 IN A 121.100.152.169 > d6991.com. 6000 IN A 121.100.152.170 > d6991.com. 6000 IN A 121.100.152.171 > d6991.com. 6000 IN A 121.100.152.172 > d6991.com. 6000 IN A 121.100.152.173 > d6991.com. 6000 IN A 121.100.152.174 > d6991.com. 6000 IN A 121.100.152.175 > d6991.com. 6000 IN A 121.100.152.176 > d6991.com. 6000 IN A 121.100.152.177 > d6991.com. 6000 IN A 121.100.152.178 > d6991.com. 6000 IN A 121.100.152.179 > d6991.com. 6000 IN A 121.100.152.180 > d6991.com. 6000 IN A 121.100.152.181 > d6991.com. 6000 IN A 121.100.152.182 > d6991.com. 6000 IN A 121.100.152.183 > d6991.com. 6000 IN A 121.100.152.184 > d6991.com. 6000 IN A 121.100.152.185 > d6991.com. 6000 IN A 121.100.152.186 > d6991.com. 6000 IN A 121.100.152.187 > d6991.com. 6000 IN A 121.100.152.188 > d6991.com. 6000 IN A 121.100.152.189 > d6991.com. 6000 IN A 121.100.152.190 > d6991.com. 6000 IN A 121.100.152.191 > d6991.com. 6000 IN A 121.100.152.192 > d6991.com. 6000 IN A 121.100.152.193 > d6991.com. 6000 IN A 121.100.152.194 > d6991.com. 6000 IN A 121.100.152.195 > d6991.com. 6000 IN A 121.100.152.196 > d6991.com. 6000 IN A 121.100.152.197 > d6991.com. 6000 IN A 121.100.152.198 > d6991.com. 6000 IN A 121.100.152.199 > d6991.com. 6000 IN A 121.100.152.200 > d6991.com. 6000 IN A 121.100.152.201 > d6991.com. 6000 IN A 121.100.152.202 > d6991.com. 6000 IN A 121.100.152.203 > d6991.com. 6000 IN A 121.100.152.204 > d6991.com. 6000 IN A 121.100.152.205 > d6991.com. 6000 IN A 121.100.152.206 > d6991.com. 6000 IN A 121.100.152.207 > d6991.com. 6000 IN A 121.100.152.208 > d6991.com. 6000 IN A 121.100.152.209 > d6991.com. 6000 IN A 121.100.152.210 > d6991.com. 6000 IN A 121.100.152.211 > d6991.com. 6000 IN A 121.100.152.212 > d6991.com. 6000 IN A 121.100.152.213 > d6991.com. 6000 IN A 121.100.152.214 > d6991.com. 6000 IN A 121.100.152.215 > d6991.com. 6000 IN A 121.100.152.216 > d6991.com. 6000 IN A 121.100.152.217 > d6991.com. 6000 IN A 121.100.152.218 > d6991.com. 6000 IN A 121.100.152.219 > d6991.com. 6000 IN A 121.100.152.220 > d6991.com. 6000 IN A 121.100.152.221 > d6991.com. 6000 IN A 121.100.152.222 > d6991.com. 6000 IN A 121.100.152.223 > d6991.com. 6000 IN A 121.100.152.224 > d6991.com. 6000 IN A 121.100.152.225 > d6991.com. 6000 IN A 121.100.152.226 > d6991.com. 6000 IN A 121.100.152.227 > d6991.com. 6000 IN A 121.100.152.228 > d6991.com. 6000 IN A 121.100.152.229 > d6991.com. 6000 IN A 121.100.152.230 > d6991.com. 6000 IN A 121.100.152.231 > d6991.com. 6000 IN A 121.100.152.232 > d6991.com. 6000 IN A 121.100.152.233 > d6991.com. 6000 IN A 121.100.152.234 > d6991.com. 6000 IN A 121.100.152.235 > d6991.com. 6000 IN A 121.100.152.236 > d6991.com. 6000 IN A 121.100.152.237 > d6991.com. 6000 IN A 121.100.152.238 > d6991.com. 6000 IN A 121.100.152.239 > d6991.com. 6000 IN A 121.100.152.240 > d6991.com. 6000 IN A 121.100.152.241 > d6991.com. 6000 IN A 121.100.152.242 > d6991.com. 6000 IN A 121.100.152.243 > d6991.com. 6000 IN A 121.100.152.244 > d6991.com. 6000 IN A 121.100.152.245 > d6991.com. 6000 IN A 121.100.152.246 > d6991.com. 6000 IN A 121.100.152.247 > d6991.com. 6000 IN A 121.100.152.248 > d6991.com. 6000 IN A 121.100.152.249 > d6991.com. 6000 IN A 121.100.152.250 > d6991.com. 6000 IN A 121.100.152.251 > d6991.com. 6000 IN A 121.100.152.252 > d6991.com. 6000 IN A 121.100.152.253 > d6991.com. 6000 IN A 121.100.152.254 > > ;; Query time: 2 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Sep 23 19:06:40 2013 > ;; MSG SIZE rcvd: 4123 > > > > % [whois.apnic.net] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > % Information related to '121.100.128.0 - 121.100.191.255' > > inetnum: 121.100.128.0 - 121.100.191.255 > netname: YanYang-network > descr: Beijing Yan Yang Century Science & Technology Co., LTD > descr: 9-605 Xuhuiaodu, Lishuiqiao south, Chaoyang District, > Beijing > country: CN > admin-c: ZM675-AP > tech-c: ZM676-AP > mnt-by: MAINT-CNNIC-AP > mnt-lower: MAINT-CNNIC-AP > mnt-routes: MAINT-CNNIC-AP > mnt-irt: IRT-CNNIC-CN > status: ALLOCATED PORTABLE > changed: ipas at cnnic.net 20110610 > source: APNIC > > irt: IRT-CNNIC-CN > address: Beijing, China > e-mail: ipas at cnnic.cn > abuse-mailbox: ipas at cnnic.cn > admin-c: IP50-AP > tech-c: IP50-AP > auth: # Filtered > remarks: Please note that CNNIC is not an ISP and is not > remarks: empowered to investigate complaints of network abuse. > remarks: Please contact the tech-c or admin-c of the network. > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.cn 20110428 > source: APNIC > > person: Yanqing Xiao > address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District > address: Beijing, China, 100012 > country: CN > phone: +86-18600090096 > fax-no: +86-010- 59456518 > e-mail: xiaoyanqingvp at 126.com > nic-hdl: ZM675-AP > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.net 20110609 > source: APNIC > > person: Jian Zhou > address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District > address: Beijing, China, 100012 > country: CN > phone: +86-18611086106 > fax-no: +86-010- 59456518 > e-mail: sxbjzj at 163.com > nic-hdl: ZM676-AP > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.net 20110609 > source: APNIC > > % Information related to '121.100.128.0/19AS4837' > > route: 121.100.128.0/19 > descr: CNC Group CHINA169 Shan1xi Province Network > descr: Addresses from CNNIC > country: CN > origin: AS4837 > mnt-by: MAINT-CNCGROUP-RR > changed: abuse at cnc-noc.net 20060926 > source: APNIC > > % This query was served by the APNIC Whois Service version 1.68 (WHOIS3) > > > - ferg > > > From rdobbins at arbor.net Mon Sep 23 17:25:02 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 23 Sep 2013 17:25:02 +0000 Subject: d6991.com traffic In-Reply-To: <52407643.9080306@gmail.com> References: <524075BC.6000408@mykolab.com> <52407643.9080306@gmail.com> Message-ID: <1D57C71E-1465-40F5-8AB3-6646B89B5982@arbor.net> On Sep 24, 2013, at 12:11 AM, Chris Hunt wrote: > That is a problem, but I'm seeing a lot of queries from residential users for what seems to me an obscure name hostied in Asia. I'm > guessing some kind of bot traffic... They may be open recursors being leveraged for DNS reflection/amplification DDoS (many CPE devices are broken this way). Check some of the CPEs to see if they're open recursors: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cma at cmadams.net Mon Sep 23 17:25:13 2013 From: cma at cmadams.net (Chris Adams) Date: Mon, 23 Sep 2013 12:25:13 -0500 Subject: d6991.com traffic In-Reply-To: <52407643.9080306@gmail.com> References: <524075BC.6000408@mykolab.com> <52407643.9080306@gmail.com> Message-ID: <20130923172513.GB1915@cmadams.net> Once upon a time, Chris Hunt said: > That is a problem, but I'm seeing a lot of queries from residential > users for what seems to me an obscure name hostied in Asia. I'm > guessing some kind of bot traffic... Any of the affected users have open resolvers (on DSL routers for example)? -- Chris Adams From jared at puck.nether.net Mon Sep 23 17:37:44 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 23 Sep 2013 13:37:44 -0400 Subject: d6991.com traffic In-Reply-To: <20130923172513.GB1915@cmadams.net> References: <524075BC.6000408@mykolab.com> <52407643.9080306@gmail.com> <20130923172513.GB1915@cmadams.net> Message-ID: On Sep 23, 2013, at 1:25 PM, Chris Adams wrote: > Once upon a time, Chris Hunt said: >> That is a problem, but I'm seeing a lot of queries from residential >> users for what seems to me an obscure name hostied in Asia. I'm >> guessing some kind of bot traffic... > > Any of the affected users have open resolvers (on DSL routers for > example)? I've heard estimates (from others that have looked at the OpenResovlerProject.org data) around 90% of resolvers are CPE devices that respond to queries on the WAN interface. - Jared From ahebert at pubnix.net Mon Sep 23 21:01:17 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 23 Sep 2013 17:01:17 -0400 Subject: d6991.com traffic In-Reply-To: <524075BC.6000408@mykolab.com> References: <524075BC.6000408@mykolab.com> Message-ID: <5240AC1D.9060404@pubnix.net> Well, There is a lot of those popping up in the past 6 months. I'm still running bindguard 0.71 and caught about 1300 targets of reflection DDoS in the past 24h. Beside using ". IN ANY" a lot are using "isc.org IN ANY" and some more that I won't list here =D Which should be pretty easy to track down the domain build for the purpose of DNS DDoS, Just saying... ----- 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 09/23/13 13:09, Paul Ferguson wrote: > On 9/23/2013 9:55 AM, Christopher Hunt wrote: > >> Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. >> 75% of the traffic is for d6991.com. Does anyone else see this? >> Who are >> these folks (WEBNIC.CC)? >> > > Maybe because of this mess? > > > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.7.3 <<>> @localhost d6991.com A > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61549 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 256, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;d6991.com. IN A > > ;; ANSWER SECTION: > d6991.com. 6000 IN A 121.100.153.100 > d6991.com. 6000 IN A 121.100.153.101 > d6991.com. 6000 IN A 121.100.153.102 > d6991.com. 6000 IN A 121.100.153.103 > d6991.com. 6000 IN A 121.100.153.104 > d6991.com. 6000 IN A 121.100.153.105 > d6991.com. 6000 IN A 121.100.153.106 > d6991.com. 6000 IN A 121.100.153.107 > d6991.com. 6000 IN A 121.100.153.108 > d6991.com. 6000 IN A 121.100.153.109 > d6991.com. 6000 IN A 121.100.153.110 > d6991.com. 6000 IN A 121.100.153.111 > d6991.com. 6000 IN A 121.100.153.112 > d6991.com. 6000 IN A 121.100.153.113 > d6991.com. 6000 IN A 121.100.153.114 > d6991.com. 6000 IN A 121.100.153.115 > d6991.com. 6000 IN A 121.100.153.116 > d6991.com. 6000 IN A 121.100.153.117 > d6991.com. 6000 IN A 121.100.153.118 > d6991.com. 6000 IN A 121.100.153.119 > d6991.com. 6000 IN A 121.100.153.120 > d6991.com. 6000 IN A 121.100.153.121 > d6991.com. 6000 IN A 121.100.153.122 > d6991.com. 6000 IN A 121.100.153.123 > d6991.com. 6000 IN A 121.100.153.124 > d6991.com. 6000 IN A 121.100.153.125 > d6991.com. 6000 IN A 121.100.153.126 > d6991.com. 6000 IN A 121.100.153.127 > d6991.com. 6000 IN A 121.100.153.128 > d6991.com. 6000 IN A 121.100.153.129 > d6991.com. 6000 IN A 121.100.153.130 > d6991.com. 6000 IN A 121.100.153.131 > d6991.com. 6000 IN A 121.100.153.132 > d6991.com. 6000 IN A 121.100.153.133 > d6991.com. 6000 IN A 121.100.153.134 > d6991.com. 6000 IN A 121.100.153.135 > d6991.com. 6000 IN A 121.100.153.136 > d6991.com. 6000 IN A 121.100.153.137 > d6991.com. 6000 IN A 121.100.153.138 > d6991.com. 6000 IN A 121.100.153.139 > d6991.com. 6000 IN A 121.100.153.140 > d6991.com. 6000 IN A 121.100.153.141 > d6991.com. 6000 IN A 121.100.153.142 > d6991.com. 6000 IN A 121.100.153.143 > d6991.com. 6000 IN A 121.100.153.144 > d6991.com. 6000 IN A 121.100.153.145 > d6991.com. 6000 IN A 121.100.153.146 > d6991.com. 6000 IN A 121.100.153.147 > d6991.com. 6000 IN A 121.100.153.148 > d6991.com. 6000 IN A 121.100.153.149 > d6991.com. 6000 IN A 121.100.153.150 > d6991.com. 6000 IN A 121.100.153.151 > d6991.com. 6000 IN A 121.100.153.152 > d6991.com. 6000 IN A 121.100.153.153 > d6991.com. 6000 IN A 121.100.153.154 > d6991.com. 6000 IN A 121.100.153.155 > d6991.com. 6000 IN A 121.100.153.156 > d6991.com. 6000 IN A 121.100.153.157 > d6991.com. 6000 IN A 121.100.153.158 > d6991.com. 6000 IN A 121.100.153.159 > d6991.com. 6000 IN A 121.100.153.160 > d6991.com. 6000 IN A 121.100.153.161 > d6991.com. 6000 IN A 121.100.153.162 > d6991.com. 6000 IN A 121.100.153.163 > d6991.com. 6000 IN A 121.100.153.164 > d6991.com. 6000 IN A 121.100.153.165 > d6991.com. 6000 IN A 121.100.153.166 > d6991.com. 6000 IN A 121.100.153.167 > d6991.com. 6000 IN A 121.100.153.168 > d6991.com. 6000 IN A 121.100.153.169 > d6991.com. 6000 IN A 121.100.153.170 > d6991.com. 6000 IN A 121.100.153.171 > d6991.com. 6000 IN A 121.100.153.172 > d6991.com. 6000 IN A 121.100.153.173 > d6991.com. 6000 IN A 121.100.153.174 > d6991.com. 6000 IN A 121.100.153.175 > d6991.com. 6000 IN A 121.100.153.176 > d6991.com. 6000 IN A 121.100.153.177 > d6991.com. 6000 IN A 121.100.153.178 > d6991.com. 6000 IN A 121.100.153.179 > d6991.com. 6000 IN A 121.100.153.180 > d6991.com. 6000 IN A 121.100.153.181 > d6991.com. 6000 IN A 121.100.153.182 > d6991.com. 6000 IN A 121.100.153.183 > d6991.com. 6000 IN A 121.100.153.184 > d6991.com. 6000 IN A 121.100.153.185 > d6991.com. 6000 IN A 121.100.153.186 > d6991.com. 6000 IN A 121.100.153.187 > d6991.com. 6000 IN A 121.100.153.188 > d6991.com. 6000 IN A 121.100.153.189 > d6991.com. 6000 IN A 121.100.153.190 > d6991.com. 6000 IN A 121.100.153.191 > d6991.com. 6000 IN A 121.100.153.192 > d6991.com. 6000 IN A 121.100.153.193 > d6991.com. 6000 IN A 121.100.153.194 > d6991.com. 6000 IN A 121.100.153.195 > d6991.com. 6000 IN A 121.100.153.196 > d6991.com. 6000 IN A 121.100.153.197 > d6991.com. 6000 IN A 121.100.153.198 > d6991.com. 6000 IN A 121.100.153.199 > d6991.com. 6000 IN A 121.100.153.200 > d6991.com. 6000 IN A 121.100.152.100 > d6991.com. 6000 IN A 121.100.152.101 > d6991.com. 6000 IN A 121.100.152.102 > d6991.com. 6000 IN A 121.100.152.103 > d6991.com. 6000 IN A 121.100.152.104 > d6991.com. 6000 IN A 121.100.152.105 > d6991.com. 6000 IN A 121.100.152.106 > d6991.com. 6000 IN A 121.100.152.107 > d6991.com. 6000 IN A 121.100.152.108 > d6991.com. 6000 IN A 121.100.152.109 > d6991.com. 6000 IN A 121.100.152.110 > d6991.com. 6000 IN A 121.100.152.111 > d6991.com. 6000 IN A 121.100.152.112 > d6991.com. 6000 IN A 121.100.152.113 > d6991.com. 6000 IN A 121.100.152.114 > d6991.com. 6000 IN A 121.100.152.115 > d6991.com. 6000 IN A 121.100.152.116 > d6991.com. 6000 IN A 121.100.152.117 > d6991.com. 6000 IN A 121.100.152.118 > d6991.com. 6000 IN A 121.100.152.119 > d6991.com. 6000 IN A 121.100.152.120 > d6991.com. 6000 IN A 121.100.152.121 > d6991.com. 6000 IN A 121.100.152.122 > d6991.com. 6000 IN A 121.100.152.123 > d6991.com. 6000 IN A 121.100.152.124 > d6991.com. 6000 IN A 121.100.152.125 > d6991.com. 6000 IN A 121.100.152.126 > d6991.com. 6000 IN A 121.100.152.127 > d6991.com. 6000 IN A 121.100.152.128 > d6991.com. 6000 IN A 121.100.152.129 > d6991.com. 6000 IN A 121.100.152.130 > d6991.com. 6000 IN A 121.100.152.131 > d6991.com. 6000 IN A 121.100.152.132 > d6991.com. 6000 IN A 121.100.152.133 > d6991.com. 6000 IN A 121.100.152.134 > d6991.com. 6000 IN A 121.100.152.135 > d6991.com. 6000 IN A 121.100.152.136 > d6991.com. 6000 IN A 121.100.152.137 > d6991.com. 6000 IN A 121.100.152.138 > d6991.com. 6000 IN A 121.100.152.139 > d6991.com. 6000 IN A 121.100.152.140 > d6991.com. 6000 IN A 121.100.152.141 > d6991.com. 6000 IN A 121.100.152.142 > d6991.com. 6000 IN A 121.100.152.143 > d6991.com. 6000 IN A 121.100.152.144 > d6991.com. 6000 IN A 121.100.152.145 > d6991.com. 6000 IN A 121.100.152.146 > d6991.com. 6000 IN A 121.100.152.147 > d6991.com. 6000 IN A 121.100.152.148 > d6991.com. 6000 IN A 121.100.152.149 > d6991.com. 6000 IN A 121.100.152.150 > d6991.com. 6000 IN A 121.100.152.151 > d6991.com. 6000 IN A 121.100.152.152 > d6991.com. 6000 IN A 121.100.152.153 > d6991.com. 6000 IN A 121.100.152.154 > d6991.com. 6000 IN A 121.100.152.155 > d6991.com. 6000 IN A 121.100.152.156 > d6991.com. 6000 IN A 121.100.152.157 > d6991.com. 6000 IN A 121.100.152.158 > d6991.com. 6000 IN A 121.100.152.159 > d6991.com. 6000 IN A 121.100.152.160 > d6991.com. 6000 IN A 121.100.152.161 > d6991.com. 6000 IN A 121.100.152.162 > d6991.com. 6000 IN A 121.100.152.163 > d6991.com. 6000 IN A 121.100.152.164 > d6991.com. 6000 IN A 121.100.152.165 > d6991.com. 6000 IN A 121.100.152.166 > d6991.com. 6000 IN A 121.100.152.167 > d6991.com. 6000 IN A 121.100.152.168 > d6991.com. 6000 IN A 121.100.152.169 > d6991.com. 6000 IN A 121.100.152.170 > d6991.com. 6000 IN A 121.100.152.171 > d6991.com. 6000 IN A 121.100.152.172 > d6991.com. 6000 IN A 121.100.152.173 > d6991.com. 6000 IN A 121.100.152.174 > d6991.com. 6000 IN A 121.100.152.175 > d6991.com. 6000 IN A 121.100.152.176 > d6991.com. 6000 IN A 121.100.152.177 > d6991.com. 6000 IN A 121.100.152.178 > d6991.com. 6000 IN A 121.100.152.179 > d6991.com. 6000 IN A 121.100.152.180 > d6991.com. 6000 IN A 121.100.152.181 > d6991.com. 6000 IN A 121.100.152.182 > d6991.com. 6000 IN A 121.100.152.183 > d6991.com. 6000 IN A 121.100.152.184 > d6991.com. 6000 IN A 121.100.152.185 > d6991.com. 6000 IN A 121.100.152.186 > d6991.com. 6000 IN A 121.100.152.187 > d6991.com. 6000 IN A 121.100.152.188 > d6991.com. 6000 IN A 121.100.152.189 > d6991.com. 6000 IN A 121.100.152.190 > d6991.com. 6000 IN A 121.100.152.191 > d6991.com. 6000 IN A 121.100.152.192 > d6991.com. 6000 IN A 121.100.152.193 > d6991.com. 6000 IN A 121.100.152.194 > d6991.com. 6000 IN A 121.100.152.195 > d6991.com. 6000 IN A 121.100.152.196 > d6991.com. 6000 IN A 121.100.152.197 > d6991.com. 6000 IN A 121.100.152.198 > d6991.com. 6000 IN A 121.100.152.199 > d6991.com. 6000 IN A 121.100.152.200 > d6991.com. 6000 IN A 121.100.152.201 > d6991.com. 6000 IN A 121.100.152.202 > d6991.com. 6000 IN A 121.100.152.203 > d6991.com. 6000 IN A 121.100.152.204 > d6991.com. 6000 IN A 121.100.152.205 > d6991.com. 6000 IN A 121.100.152.206 > d6991.com. 6000 IN A 121.100.152.207 > d6991.com. 6000 IN A 121.100.152.208 > d6991.com. 6000 IN A 121.100.152.209 > d6991.com. 6000 IN A 121.100.152.210 > d6991.com. 6000 IN A 121.100.152.211 > d6991.com. 6000 IN A 121.100.152.212 > d6991.com. 6000 IN A 121.100.152.213 > d6991.com. 6000 IN A 121.100.152.214 > d6991.com. 6000 IN A 121.100.152.215 > d6991.com. 6000 IN A 121.100.152.216 > d6991.com. 6000 IN A 121.100.152.217 > d6991.com. 6000 IN A 121.100.152.218 > d6991.com. 6000 IN A 121.100.152.219 > d6991.com. 6000 IN A 121.100.152.220 > d6991.com. 6000 IN A 121.100.152.221 > d6991.com. 6000 IN A 121.100.152.222 > d6991.com. 6000 IN A 121.100.152.223 > d6991.com. 6000 IN A 121.100.152.224 > d6991.com. 6000 IN A 121.100.152.225 > d6991.com. 6000 IN A 121.100.152.226 > d6991.com. 6000 IN A 121.100.152.227 > d6991.com. 6000 IN A 121.100.152.228 > d6991.com. 6000 IN A 121.100.152.229 > d6991.com. 6000 IN A 121.100.152.230 > d6991.com. 6000 IN A 121.100.152.231 > d6991.com. 6000 IN A 121.100.152.232 > d6991.com. 6000 IN A 121.100.152.233 > d6991.com. 6000 IN A 121.100.152.234 > d6991.com. 6000 IN A 121.100.152.235 > d6991.com. 6000 IN A 121.100.152.236 > d6991.com. 6000 IN A 121.100.152.237 > d6991.com. 6000 IN A 121.100.152.238 > d6991.com. 6000 IN A 121.100.152.239 > d6991.com. 6000 IN A 121.100.152.240 > d6991.com. 6000 IN A 121.100.152.241 > d6991.com. 6000 IN A 121.100.152.242 > d6991.com. 6000 IN A 121.100.152.243 > d6991.com. 6000 IN A 121.100.152.244 > d6991.com. 6000 IN A 121.100.152.245 > d6991.com. 6000 IN A 121.100.152.246 > d6991.com. 6000 IN A 121.100.152.247 > d6991.com. 6000 IN A 121.100.152.248 > d6991.com. 6000 IN A 121.100.152.249 > d6991.com. 6000 IN A 121.100.152.250 > d6991.com. 6000 IN A 121.100.152.251 > d6991.com. 6000 IN A 121.100.152.252 > d6991.com. 6000 IN A 121.100.152.253 > d6991.com. 6000 IN A 121.100.152.254 > > ;; Query time: 2 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Sep 23 19:06:40 2013 > ;; MSG SIZE rcvd: 4123 > > > > % [whois.apnic.net] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > % Information related to '121.100.128.0 - 121.100.191.255' > > inetnum: 121.100.128.0 - 121.100.191.255 > netname: YanYang-network > descr: Beijing Yan Yang Century Science & Technology Co., LTD > descr: 9-605 Xuhuiaodu, Lishuiqiao south, Chaoyang District, > Beijing > country: CN > admin-c: ZM675-AP > tech-c: ZM676-AP > mnt-by: MAINT-CNNIC-AP > mnt-lower: MAINT-CNNIC-AP > mnt-routes: MAINT-CNNIC-AP > mnt-irt: IRT-CNNIC-CN > status: ALLOCATED PORTABLE > changed: ipas at cnnic.net 20110610 > source: APNIC > > irt: IRT-CNNIC-CN > address: Beijing, China > e-mail: ipas at cnnic.cn > abuse-mailbox: ipas at cnnic.cn > admin-c: IP50-AP > tech-c: IP50-AP > auth: # Filtered > remarks: Please note that CNNIC is not an ISP and is not > remarks: empowered to investigate complaints of network abuse. > remarks: Please contact the tech-c or admin-c of the network. > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.cn 20110428 > source: APNIC > > person: Yanqing Xiao > address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District > address: Beijing, China, 100012 > country: CN > phone: +86-18600090096 > fax-no: +86-010- 59456518 > e-mail: xiaoyanqingvp at 126.com > nic-hdl: ZM675-AP > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.net 20110609 > source: APNIC > > person: Jian Zhou > address: 9-605 Xuhuiaodu. Lishuiqiao south Chaoyang District > address: Beijing, China, 100012 > country: CN > phone: +86-18611086106 > fax-no: +86-010- 59456518 > e-mail: sxbjzj at 163.com > nic-hdl: ZM676-AP > mnt-by: MAINT-CNNIC-AP > changed: ipas at cnnic.net 20110609 > source: APNIC > > % Information related to '121.100.128.0/19AS4837' > > route: 121.100.128.0/19 > descr: CNC Group CHINA169 Shan1xi Province Network > descr: Addresses from CNNIC > country: CN > origin: AS4837 > mnt-by: MAINT-CNCGROUP-RR > changed: abuse at cnc-noc.net 20060926 > source: APNIC > > % This query was served by the APNIC Whois Service version 1.68 (WHOIS3) > > > - ferg > > > From surfer at mauigateway.com Mon Sep 23 21:07:44 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 23 Sep 2013 14:07:44 -0700 Subject: spam to nanog folks from qualisystems.com? Message-ID: <20130923140744.348E2FBD@m0005310.ppops.net> Did anyone else on this list get spam from qualisystems.com? It looks like they scraped technical mailing list addresses and I am trying to find out where. scott Received: from sjmda14.webex.com (sjmda14.webex.com [64.68.124.162])by dm0208.mta.everyone.net (EON-INBOUND) with ESMTP id dm020 8.523928cf.f24b7ffor ; Mon, 23 Sep 2013 10:20:04 -0700 from rln1rmd001.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-1.webex.com [64.68.121.245])by sjmda14.webex.com (Postfix) with ESMTP id E2078801E8for ; Mon, 23 Sep 2013 17:20:02 +0000 (GMT) from rln1rmd001.webex.com (by rln1rmd001.webex.com (8.13.8/8.13.8) with ESMTP id r8NHK1HX020499for ; M on, 23 Sep 2013 17:20:02 GMT MIME-Version: 1.0 Subject: Invitation to Free Web seminar: Is Your Test Lab Software Defined? X-Eon-DM: dm0208 Return-Path: X-Priority: 3 Date: Mon, 23 Sep 2013 17:20:01 +0000 (GMT+00:00) X-WBX-Info: X-WBX-SID=689084, X-WBX-CID=1340760526, X-WBX-TID=e7112d5afd588e8ae040fd0a2d045737, X-WBX-RID=E7112D5B12FF8E8AE040FD0A 2D045737, X-WBX-SVC:Event Center, X-WBX-TT:Invitation to Participants that does not Require Enrollment_html, Date:Mon Sep 23 17:20:01 GMT+00:00 2013 RMD2.2.8 Importance: normal Content-Type: multipart/mixed; boundary="----=_Part_455900_1589876324.1379956801898" Reply-To: revital.r at qualisystems.com Message-ID: <172116371.2291621379956801898.JavaMail.nobody at rln1rmd001.webex.com> To: surfer at mauigateway.com From: QualiSystems From eric at mail.rockefeller.edu Mon Sep 23 22:47:30 2013 From: eric at mail.rockefeller.edu (Eric Davis) Date: Mon, 23 Sep 2013 22:47:30 +0000 Subject: NIH.gov Message-ID: <54CBB3D067EE024D823BDA66EADEBE4E0F44BB3A@RUMBX2.rockefeller.edu> Did anyone notice a problem getting to NIH.gov today? It seemed inaccessible from a lot of ISP's. Our grant writers were a little nervous about deadlines. Eric From sgtphou at fire-eyes.org Tue Sep 24 00:01:24 2013 From: sgtphou at fire-eyes.org (fire-eyes) Date: Mon, 23 Sep 2013 20:01:24 -0400 Subject: d6991.com traffic In-Reply-To: References: Message-ID: <5240D654.1010402@fire-eyes.org> It's DNS reflection attack noise: http://dnsamplificationattacks.blogspot.com/2013/09/domain-d6991com.html This is a good blog for observing the domains and frequent correlation of items in whois and other traits that indicate much of this is done by the same actors. On 09/23/2013 12:55 PM, Christopher Hunt wrote: > Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. > 75% of the traffic is for d6991.com. Does anyone else see this? Who are > these folks (WEBNIC.CC)? > > -chris > From fergdawgster at mykolab.com Tue Sep 24 00:11:03 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 23 Sep 2013 17:11:03 -0700 Subject: d6991.com traffic In-Reply-To: <5240D654.1010402@fire-eyes.org> References: <5240D654.1010402@fire-eyes.org> Message-ID: <5240D897.5000008@mykolab.com> On 9/23/2013 5:01 PM, fire-eyes wrote: > It's DNS reflection attack noise: > > http://dnsamplificationattacks.blogspot.com/2013/09/domain-d6991com.html > > This is a good blog for observing the domains and frequent correlation > of items in whois and other traits that indicate much of this is done by > the same actors. > Thanks for the pointer. :-) - ferg > On 09/23/2013 12:55 PM, Christopher Hunt wrote: >> Beginning about 0900UTC we began seeing about 50x our usual DNS traffic. >> 75% of the traffic is for d6991.com. Does anyone else see this? >> Who are >> these folks (WEBNIC.CC)? >> >> -chris >> > > > > -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com From alvarezp at alvarezp.ods.org Tue Sep 24 00:52:27 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 23 Sep 2013 17:52:27 -0700 Subject: iOS 7 update traffic In-Reply-To: References: <523B3B15.5090603@people.ops-trust.net> <523B3B40.5070309@mykolab.com> <1379928743.85504.YahooMailNeo@web133101.mail.ir2.yahoo.com> <52401F2F.8010209@tonal.clara.co.uk> Message-ID: <5240E24B.3080001@alvarezp.ods.org> That's just the typical Bittorrent /client/, but the idea of using Bittorrent means the /protocol/. A special Bittorrent client could be written for ISPs with uploads disabled and Apple could also disable them on the update-downloading Bittorrent client for the phones. The clients (be it Bittorrent or not) would still download the MD5 hash after the download finishes to verify the integrity of the download, and Apple would still be able to measure the amount of downloaded images. For the ISP, this would mean minimal amount of effective downloads. On 09/23/2013 07:31 AM, Blake Dunlap wrote: > Bit torrent is a way to lighten the load on the originator, and to increase > the speed of the acquisition from the receivers. It is not a tool to > decrease network load, if anything it does the opposite most of the time. > > Every now and then, a client will find a local network peer, but its > usually an accident more than anything from the algorithm it uses to try to > find the fastest senders with pieces it needs. This is most often a product > of far end congestion and what pieces are completed, and rarely upstream > related barring major issues. The algorithim is self greedy, not > altruistic, and definitely not written with ISP load issues in mind. > > I'd much prefer CDN content over bittorrent from the ISP side. From jgreco at ns.sol.net Tue Sep 24 01:36:30 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 23 Sep 2013 20:36:30 -0500 (CDT) Subject: iOS 7 update traffic In-Reply-To: <5240E24B.3080001@alvarezp.ods.org> Message-ID: <201309240136.r8O1aUCo091712@aurora.sol.net> > That's just the typical Bittorrent /client/, but the idea of using > Bittorrent means the /protocol/. A special Bittorrent client could be > written for ISPs with uploads disabled and Apple could also disable them > on the update-downloading Bittorrent client for the phones. > > The clients (be it Bittorrent or not) would still download the MD5 hash > after the download finishes to verify the integrity of the download, and > Apple would still be able to measure the amount of downloaded images. So then all the networks that have done $things to BitTorrent to demote it to second-rate traffic will suddenly have a bunch of very angry Apple fans whose downloads are mysteriously having issues. And then - assuming you intend for more things than just Apple to go this route - all the CDN's would need to be redesigned to support BT too. It seems like it'd be simpler for Apple to figure out how to validate a partial download and then resume. It isn't like that would be cutting edge technology. I think I might even have seen it happen before. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jeff-kell at utc.edu Tue Sep 24 01:57:00 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 23 Sep 2013 21:57:00 -0400 Subject: iOS 7 update traffic In-Reply-To: <201309240136.r8O1aUCo091712@aurora.sol.net> References: <201309240136.r8O1aUCo091712@aurora.sol.net> Message-ID: <5240F16C.9070707@utc.edu> On 9/23/2013 9:36 PM, Joe Greco wrote: > So then all the networks that have done $things to BitTorrent to > demote it to second-rate traffic will suddenly have a bunch of very > angry Apple fans whose downloads are mysteriously having issues. Just ask the Blizzard fans (World of Warcraft) about this phenomenon... Jeff From randy at psg.com Tue Sep 24 02:16:55 2013 From: randy at psg.com (Randy Bush) Date: Mon, 23 Sep 2013 16:16:55 -1000 Subject: iOS 7 update traffic In-Reply-To: <5240F16C.9070707@utc.edu> References: <201309240136.r8O1aUCo091712@aurora.sol.net> <5240F16C.9070707@utc.edu> Message-ID: >> So then all the networks that have done $things to BitTorrent to >> demote it to second-rate traffic will suddenly have a bunch of very >> angry Apple fans whose downloads are mysteriously having issues. > Just ask the Blizzard fans (World of Warcraft) about this > phenomenon... i love the business plan of preventing the users from getting what they want. i think all my competitors should follow it. randy, who uses a bunch of bittorrent, try btsync for more private dropbox From jra at baylink.com Tue Sep 24 04:45:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 24 Sep 2013 00:45:52 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: Message-ID: <3561395.8489.1379997952336.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Randy Bush" > i love the business plan of preventing the users from getting what > they want. i think all my competitors should follow it. Strawman, Randy. Clearly, the Internet is *not* up to the task of 1) updating several dozen million devices 2) on links of various quality, 3) with 650MB to 1.2GB downloads and 4) a client that doesn't understand how to restart 5) all at once, cause, over all, it went very poorly. The people negatively impacted by that poor engineering planning on Apple's part *are Apple's customers*, quite apart from any negative impact it had on Everyone Else. Fixing 4 (which is an easy engineering issue) and 5 (which is an operations policy issue that, by and large, most people in that situation understand), *would have had a direct positive effect on Apple's paying customers*. "Preventing them from getting what they want" is made up, and I'm pretty sure you know that. Staging FW update rollouts over networks is old hat. Even I know better than to make that mistake, and I don't know anything. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From alvarezp at alvarezp.ods.org Tue Sep 24 04:52:24 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 23 Sep 2013 23:52:24 -0500 Subject: iOS 7 update traffic In-Reply-To: <201309240136.r8O1aUCo091712@aurora.sol.net> References: <201309240136.r8O1aUCo091712@aurora.sol.net> Message-ID: <52411A88.8060507@alvarezp.ods.org> On 09/23/2013 08:36 PM, Joe Greco wrote: >> That's just the typical Bittorrent /client/, but the idea of using >> Bittorrent means the /protocol/. A special Bittorrent client could be >> written for ISPs with uploads disabled and Apple could also disable them >> on the update-downloading Bittorrent client for the phones. >> >> The clients (be it Bittorrent or not) would still download the MD5 hash >> after the download finishes to verify the integrity of the download, and >> Apple would still be able to measure the amount of downloaded images. > > So then all the networks that have done $things to BitTorrent to demote it > to second-rate traffic will suddenly have a bunch of very angry Apple fans > whose downloads are mysteriously having issues. No, usually that traffic is demoted right before upstream (or in some way not very near to the provider-edge-to-customer device). Once the download is ready on the ISP, that would be a solved problem. And also, the phone could support two protocols as a transition. It's the easiest solution I've read so far. There are others but not as easy. > And then - assuming you intend for more things than just Apple to go this > route - all the CDN's would need to be redesigned to support BT too. Why can't it be implemented as an independent mean of delivering updates? > It seems like it'd be simpler for Apple to figure out how to validate a > partial download and then resume. It isn't like that would be cutting > edge technology. I think I might even have seen it happen before. Validate partial download? How would that help to reduce the overall load on the ISP? That is only limited to reducing the "redundant" traffic, where "redundant" means "twice per device", not "twice per content", which is the real problem. Cheers. From swmike at swm.pp.se Tue Sep 24 08:07:06 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 24 Sep 2013 10:07:06 +0200 (CEST) Subject: iOS 7 update traffic In-Reply-To: <3561395.8489.1379997952336.JavaMail.root@benjamin.baylink.com> References: <3561395.8489.1379997952336.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, 24 Sep 2013, Jay Ashworth wrote: > Fixing 4 (which is an easy engineering issue) and 5 (which is an > operations policy issue that, by and large, most people in that > situation understand), *would have had a direct positive effect on > Apple's paying customers*. Fixing 4 is something apple should do. 5 is a marketing decision for them. People are used to queuing *for things*. If the apple updates break your network instead of just the apple updates, then that is your fault as an ISP. For me, nothing more than the apple updates were broken during those hours, that I could tell anyway. "The Internet" wasn't broken. -- Mikael Abrahamsson email: swmike at swm.pp.se From jcurran at arin.net Tue Sep 24 11:58:22 2013 From: jcurran at arin.net (John Curran) Date: Tue, 24 Sep 2013 11:58:22 +0000 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <20130919024604.69F776FB858@rock.dv.isc.org> References: <20130919010210.11321.qmail@joyce.lan> <523A6203.8090504@trelane.net> <20130919024604.69F776FB858@rock.dv.isc.org> Message-ID: <1DE437AE-3D55-417E-A932-4A40ECD4841C@corp.arin.net> On Sep 18, 2013, at 10:46 PM, Mark Andrews wrote: > Which is irrelevent to removing a address block on the basis of a > RIR recording that the block has been reallocated. A reallocation > already goes through a quarantine period though that may get shorter > as time goes on. > > A transfer on the other hand doesn't. Correct. A transfer is not an issuance of space, and could very easily be to a recipient related to the original party that caused the current reputation. Whereas the issuance of address space to a qualified requestor (even if previously issued and now returned to ARIN) is far more likely to an unrelated new party than anyone related to the original block holder. > There may be some use in recording whether a address block is > transfered or allocated. Note I'm not sure if the allocation > date gets updated on a transfer or not. The arin-issued feed is simply issued resources (not transfers) - It is highly recommended that folks running reputation systems monitor this feed and avoid penalizing parties being issued resources, as those requesting have no control over the prior history of these blocks before their return to ARIN. We are going to see quite a bit more of reissued blocks as we get down towards the bottom of the available pool in this region (i.e. over the next 6 to 12 months) Thanks! /John John Curran President and CEO ARIN From jared at puck.nether.net Tue Sep 24 13:32:22 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 Sep 2013 09:32:22 -0400 Subject: iOS 7 update traffic In-Reply-To: <3561395.8489.1379997952336.JavaMail.root@benjamin.baylink.com> References: <3561395.8489.1379997952336.JavaMail.root@benjamin.baylink.com> Message-ID: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> On Sep 24, 2013, at 12:45 AM, Jay Ashworth wrote: > Strawman, Randy. > > Clearly, the Internet is *not* up to the task of > > 1) updating several dozen million devices > 2) on links of various quality, > 3) with 650MB to 1.2GB downloads and > 4) a client that doesn't understand how to restart > 5) all at once, > > cause, over all, it went very poorly. It went well for most users, it seems the 1-5% of people with "odd" configs are the problem. Keep in mind that on any average day about 3% of the networks out there are broken based on pre-ipv6 day measurements. That is, their IPv4 is completely busted. Having the error/problem rate being down in that area is reasonable to me. How many code-red/slammer scans do you still see a decade on? Overall this was surely a network traffic event, and those that observed the IOS6 impact a year ago realized it would occur again with IOS7 and monitored for it. Not everything will work for everyone, but for the majority of users it was fine. (This from surveying my non-geek friends). Traffic levels will lower about 7 days post-release. Also, NYC and other police departments are advocating people update immediately for the anti-theft upgrades provided in the new software. Let me know how your conversation with them goes. - Jared From nccariaga at stluke.com.ph Tue Sep 24 13:49:33 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 24 Sep 2013 21:49:33 +0800 Subject: minimum IPv6 announcement size Message-ID: <5241986D.60902@stluke.com.ph> Hi, Just wondering if anyone could shed light on my concern..... I've been Google-ing about if there is such a standard that sets the minimum IPv6 advertisement on BGP. My concern is that I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR, I figured out I would it would be best for us to break down the /48 into smaller chunks (i.e /56s) and farm it out to our sites since a single /48 will be very big for our single site. Any advise will be very much appreciated. Regards, -- -nathan From otis at ocosa.com Tue Sep 24 13:47:24 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Tue, 24 Sep 2013 08:47:24 -0500 Subject: minimum IPv6 announcement size In-Reply-To: <5241986D.60902@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B01883B@ocsbs.ocosa.com> -----Original Message----- From: Nathanael C. Cariaga [mailto:nccariaga at stluke.com.ph] Sent: Tuesday, September 24, 2013 8:50 AM To: NANOG Mailing List Subject: minimum IPv6 announcement size >Hi, > >Just wondering if anyone could shed light on my concern..... > >I've been Google-ing about if there is such a standard that sets the minimum IPv6 advertisement on BGP. My concern is that I am running a network that is operating on multiple sites and currently rolling >out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR, I figured out I would it would be best for us to break down the >/48 into smaller chunks (i.e /56s) and farm it out to our sites since a single /48 will be very big for our single site. > >Any advise will be very much appreciated. > > >Regards, > >-- >-nathan Minimum announcement for IPv6 as I recall is /48. Some providers might accept less for their networks. -Otis From joelja at bogus.com Tue Sep 24 14:00:07 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 24 Sep 2013 07:00:07 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B01883B@ocsbs.ocosa.com> References: <5241986D.60902@stluke.com.ph> <5FE1FB6D43B8A647BBC821840C1AEA8B01883B@ocsbs.ocosa.com> Message-ID: <52419AE7.2090505@bogus.com> On 9/24/13 6:47 AM, Otis L. Surratt, Jr. wrote: > -----Original Message----- > From: Nathanael C. Cariaga [mailto:nccariaga at stluke.com.ph] > Sent: Tuesday, September 24, 2013 8:50 AM > To: NANOG Mailing List > Subject: minimum IPv6 announcement size > >> Hi, >> >> Just wondering if anyone could shed light on my concern..... >> >> I've been Google-ing about if there is such a standard that sets the > minimum IPv6 advertisement on BGP. My concern is that I am running a > network that is operating on multiple sites and currently rolling >out > our IPv6 on the perimeter level. Having to get our /48 allocation from > our RIR, I figured out I would it would be best for us to break down the >> /48 into smaller chunks (i.e /56s) and farm it out to our sites since a > single /48 will be very big for our single site. Your RIR ought to make a minimum allocation based on the number of sites you need to deploy to, so something shorter than a /48. clearly you should aim for the highest acheiveable aggregation but that's not always possible. the fact that it is "large for your site" isn't germain to the discussion of what's the minimally accepted size prefix. >> Any advise will be very much appreciated. >> >> >> Regards, >> >> -- >> -nathan > > Minimum announcement for IPv6 as I recall is /48. Some providers might > accept less for their networks. I've seen providers accept longer but not propigate them. we apply filters at the /48 level, That appears to be sufficiently common that it confers herd immunity to shorter prefixes. > -Otis > > From jra at baylink.com Tue Sep 24 14:49:21 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 24 Sep 2013 10:49:21 -0400 (EDT) Subject: iOS 7 update traffic In-Reply-To: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> Message-ID: <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > It went well for most users, it seems the 1-5% of people with "odd" > configs are the problem. [ ... ] > IOS7 and monitored for it. Not everything will work for everyone, but > for the majority of users it was fine. (This from surveying my > non-geek friends). Hmmm. The number of unsolicited reports I saw and received -- both from upgraders and those who didn't even know it was happening, seemed much higher than would support that. When you're upgrading several hundred million devices, the error rate doesn't have to be that high... But the things you *should* do are still a larger list than the things you *must* do; tragedy of the commons and like that. Apple could *easily* have handled it better. That's my story, and I'm stickin' to it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ben+nanog at list-subs.com Tue Sep 24 16:54:19 2013 From: ben+nanog at list-subs.com (Ben) Date: Tue, 24 Sep 2013 17:54:19 +0100 Subject: minimum IPv6 announcement size In-Reply-To: <5241986D.60902@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> Message-ID: <5241C3BB.50200@list-subs.com> On 24/09/2013 14:49, Nathanael C. Cariaga wrote: > Hi, > > Just wondering if anyone could shed light on my concern..... > > I've been Google-ing about if there is such a standard that sets the > minimum IPv6 advertisement on BGP. > You need to work on your google-fu then ... https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering Happy bed time reading ;-) From glen.kent at gmail.com Tue Sep 24 16:55:58 2013 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 24 Sep 2013 22:25:58 +0530 Subject: iOS 7 update traffic In-Reply-To: <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> References: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> Message-ID: Picked this off www.jaluri.com (network and Cisco blog aggregator): > > > http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ > > The consensus seems to be for providers to install CDN servers, if they > arent able to cope up with an occasional OS update traffic. > While his argument for installing CDNs is not entirely incorrect, you should take it with a pound of salt, as the author works for a CDN vendor! :-) http://blog.streamingmedia.com/2009/07/alcatellucent-acquires-cdn-technology-provider-velocix.html > From ben+nanog at list-subs.com Tue Sep 24 17:36:11 2013 From: ben+nanog at list-subs.com (Ben) Date: Tue, 24 Sep 2013 18:36:11 +0100 Subject: iOS 7 update traffic In-Reply-To: References: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> Message-ID: <5241CD8B.5070500@list-subs.com> On 24/09/2013 17:55, Glen Kent wrote: > Picked this off www.jaluri.com (network and Cisco blog aggregator): >> >> >> http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ >> >> The consensus seems to be for providers to install CDN servers, if they >> arent able to cope up with an occasional OS update traffic. Hang on a minute..... That last paragraph in his blog sounds awfully similar to something I posted here the other day ! He says on the 23rd of September : Users are paying service providers to deliver their IP packets. If providers cant handle the volume of traffic that they?re being asked to deliver then its probably time for them to reevaluate their commercial structure (charge customers more) or to redesign/overhaul their networks (invest in CDNs, etc). Remember, with everyone connecting to the ?cloud?, the traffic that providers will be asked to push is only going to increase with time .. I said on the 20th of September : Your user is paying you to push packets. If that's causing you a problem, you either need to review your commercial structure (i.e. charge people more) or your technical network design. Face the facts, what with everyone jumping on the "cloud" bandwagon, the future is only going to see you pushing more packets, not less ! So if you can't stand the heat, get out of the kitchen (or the xSP industry). Hmmmmmm.......... ;-( From fohdeesha at gmail.com Tue Sep 24 17:53:12 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Tue, 24 Sep 2013 13:53:12 -0400 Subject: iOS 7 update traffic In-Reply-To: <5241CD8B.5070500@list-subs.com> References: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> <5241CD8B.5070500@list-subs.com> Message-ID: <5241D188.3050200@gmail.com> You've been robbed! On 9/24/2013 1:36 PM, Ben wrote: > Hang on a minute..... > > That last paragraph in his blog sounds awfully similar to something I > posted here the other day ! > > He says on the 23rd of September : > Users are paying service providers to deliver their IP packets. If > providers cant handle the volume of traffic that they?re being asked > to deliver then its probably time for them to reevaluate their > commercial structure (charge customers more) or to redesign/overhaul > their networks (invest in CDNs, etc). Remember, with everyone > connecting to the ?cloud?, the traffic that providers will be asked to > push is only going to increase with time .. > > > I said on the 20th of September : > Your user is paying you to push packets. If that's causing you a > problem, you either need to review your commercial structure (i.e. > charge people more) or your technical network design. Face the facts, > what with everyone jumping on the "cloud" bandwagon, the future is > only going to see you pushing more packets, not less ! So if you can't > stand the heat, get out of the kitchen (or the xSP industry). > > Hmmmmmm.......... ;-( > -- Jon Sands From randy at psg.com Tue Sep 24 18:00:44 2013 From: randy at psg.com (Randy Bush) Date: Tue, 24 Sep 2013 08:00:44 -1000 Subject: minimum IPv6 announcement size In-Reply-To: <5241986D.60902@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> Message-ID: > I am running a network that is operating on multiple sites and > currently rolling out our IPv6 on the perimeter level. Having to > get our /48 allocation from our RIR excuse, but which rir handed out a /48 under which policy? randy From edward.dore at freethought-internet.co.uk Tue Sep 24 18:09:31 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Tue, 24 Sep 2013 19:09:31 +0100 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: RIPE will give you a /48 of IPv6 PI http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments Edward Dore Freethought Internet On 24 Sep 2013, at 19:00, Randy Bush wrote: >> I am running a network that is operating on multiple sites and >> currently rolling out our IPv6 on the perimeter level. Having to >> get our /48 allocation from our RIR > > excuse, but which rir handed out a /48 under which policy? > > randy > From owen at delong.com Tue Sep 24 18:18:47 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Sep 2013 11:18:47 -0700 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: On Sep 24, 2013, at 11:00 AM, Randy Bush wrote: >> I am running a network that is operating on multiple sites and >> currently rolling out our IPv6 on the perimeter level. Having to >> get our /48 allocation from our RIR > > excuse, but which rir handed out a /48 under which policy? > > randy ARIN will give out /48s to end users. AfriNIC will give out /48s to end users. I believe (but haven't verified) that this is also possible from APNIC and LACNIC. Someone else mentioned that RIPE will as well. Owen From bill at herrin.us Tue Sep 24 18:33:41 2013 From: bill at herrin.us (William Herrin) Date: Tue, 24 Sep 2013 14:33:41 -0400 Subject: minimum IPv6 announcement size In-Reply-To: <5241986D.60902@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> Message-ID: On Tue, Sep 24, 2013 at 9:49 AM, Nathanael C. Cariaga wrote: > I've been Google-ing about if there is such a standard that sets the minimum > IPv6 advertisement on BGP. My concern is that I am running a network that > is operating on multiple sites and currently rolling out our IPv6 on the > perimeter level. Having to get our /48 allocation from our RIR, I figured > out I would it would be best for us to break down the /48 into smaller > chunks (i.e /56s) and farm it out to our sites since a single /48 will be > very big for our single site. Hi Nathanael, Many if not most networks set a limit at /48. Verizon was the last player of consequence to filter at /32, and they moved to /48 a couple years ago. A few also try to limit advertisements within ISP space nearer to /32. Usually not at /32, but a /48 announcement within space allocated to an ISP won't necessarily be honored. If you have distinct networks with distinct routing policies (or can make a reasonable claim to such) and your RIR is ARIN, you can request a block size large enough to provide a /48 to each distinct network. A /44 or whatever. Search through the ARIN NRPM for details. I don't know about the other RIRs; someone in your region (Asia Pacific?) will know. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bryan at serverstack.com Tue Sep 24 18:36:19 2013 From: bryan at serverstack.com (Bryan Socha) Date: Tue, 24 Sep 2013 14:36:19 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: Everyone is following the same policies. a /48 PER SITE. did you request enough addresses from your RIR? Bryan Socha From steve.bertrand at amayagaming.com Tue Sep 24 18:46:56 2013 From: steve.bertrand at amayagaming.com (Steve Bertrand) Date: Tue, 24 Sep 2013 18:46:56 +0000 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: September-24-13 12:19 > To: Randy Bush > Cc: NANOG Mailing List > Subject: Re: minimum IPv6 announcement size > > > On Sep 24, 2013, at 11:00 AM, Randy Bush wrote: > > >> I am running a network that is operating on multiple sites and > >> currently rolling out our IPv6 on the perimeter level. Having > to get > >> our /48 allocation from our RIR > > > > excuse, but which rir handed out a /48 under which policy? > > > > randy > > ARIN will give out /48s to end users. > > AfriNIC will give out /48s to end users. > > I believe (but haven't verified) that this is also possible from > APNIC and LACNIC. APNIC: 7.2.1. Initial Assignments "APNIC will allocate a minimum of a /48 to organizations that can demonstrate..." LACNIC: 4.5.4. Direct Assignments to End Sites In a couple of subsections: "Assignments will be made in blocks smaller than or equal to a /32 but always greater than or equal to a /48." Steve From jcurran at arin.net Tue Sep 24 19:07:03 2013 From: jcurran at arin.net (John Curran) Date: Tue, 24 Sep 2013 19:07:03 +0000 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: <1DE437AE-3D55-417E-A932-4A40ECD4841C@corp.arin.net> References: <20130919010210.11321.qmail@joyce.lan> <523A6203.8090504@trelane.net> <20130919024604.69F776FB858@rock.dv.isc.org> <1DE437AE-3D55-417E-A932-4A40ECD4841C@corp.arin.net> Message-ID: On Sep 24, 2013, at 7:58 AM, John Curran wrote: > On Sep 18, 2013, at 10:46 PM, Mark Andrews wrote: > >> Which is irrelevent to removing a address block on the basis of a >> RIR recording that the block has been reallocated. A reallocation >> already goes through a quarantine period though that may get shorter >> as time goes on. >> >> A transfer on the other hand doesn't. > > Correct. A transfer is not an issuance of space, and could very easily > be to a recipient related to the original party that caused the current > reputation. Okay, my apologies for supplying one piece of information which was not quite correct with respect to the above - A transfer which occurs due to merger or acquisition is simply the updating of the organization and/or contacts, and does not result in a new issue date, nor does it show up in the arin-issued feed as noted above. A sale (aka specified transfer) has a new issued date, and thus does appear in the arin-issued feed. It is still likely that these are to new parties but if an party operating a reputation service is concerned about the risk of "reputation washing via transfer", then they should monitor the list of specified transferred address blocks which is here: Note also, there is more useful aspect of the arin-issued feed for those operating reputation services, and that is with respect to blocks returned to ARIN - Any blocks that come back to ARIN (whether reclaimed/revoked/recovered) are placed in hold status upon receipt. This hold period used to be one year, then was reduced to 6 months, is presently 3 months, and at ARIN IPv4 depletion will be just 1 one month per the ARIN IPv4 countdown plan: References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <002301ceb588$673688d0$35a39a70$@iname.com> Message-ID: On Thu, Sep 19, 2013 at 6:34 PM, Frank Bulk wrote: > Is there an indication or separate list that shows if they've been recycled? Hi Frank, Looks like they post a "remove" message when a block is returned to the registry and then an "add' when it's reassigned. For example, Derrick's block (74.112.96.0/22) was "removed" in November: http://lists.arin.net/pipermail/arin-issued/2012-November/001446.html and then "added" in March: http://lists.arin.net/pipermail/arin-issued/2013-March/001561.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From davidpeahi at gmail.com Tue Sep 24 22:28:42 2013 From: davidpeahi at gmail.com (david peahi) Date: Tue, 24 Sep 2013 15:28:42 -0700 Subject: liveaction qos configurator Message-ID: Any comments on live action Cisco qos configurator would be appreciated Regards David From ben+nanog at list-subs.com Tue Sep 24 22:48:55 2013 From: ben+nanog at list-subs.com (Ben) Date: Tue, 24 Sep 2013 23:48:55 +0100 Subject: iOS 7 update traffic In-Reply-To: <20130924175425.5718165.35281.8388@supermathie.net> References: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> <5241CD8B.5070500@list-subs.com> <20130924175425.5718165.35281.8388@supermathie.net> Message-ID: <524216D7.7020504@list-subs.com> On 24/09/2013 18:54, Michael Brown wrote: > That is most assuredly a rewrite, it's not just your perception. > > M. > Surprise surprise, that page now appears to Error 404... guess he must watch the list quite closely as it didn't take long for him to react ! ;-) Guess I should be flattered someone finds my internet rantings quoteworthy ! Would have appreciated at least a feable attempt at a citation (or at least a generic reference to the Nanog list in general). From nccariaga at stluke.com.ph Wed Sep 25 01:42:34 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 25 Sep 2013 09:42:34 +0800 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: <52423F8A.2040801@stluke.com.ph> We got our /48 from APNIC.. -nathan On 9/25/2013 2:18 AM, Owen DeLong wrote: > On Sep 24, 2013, at 11:00 AM, Randy Bush wrote: > >>> I am running a network that is operating on multiple sites and >>> currently rolling out our IPv6 on the perimeter level. Having to >>> get our /48 allocation from our RIR >> excuse, but which rir handed out a /48 under which policy? >> >> randy > ARIN will give out /48s to end users. > > AfriNIC will give out /48s to end users. > > I believe (but haven't verified) that this is also possible from APNIC and LACNIC. > > Someone else mentioned that RIPE will as well. > > Owen > From nccariaga at stluke.com.ph Wed Sep 25 02:03:52 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 25 Sep 2013 10:03:52 +0800 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: <52424488.7030408@stluke.com.ph> Hi All, Thank you for these insights. We'll look into all of these and review again our options on how we can further proceed in our IPv6 deployment. Regards, -nathan On 9/25/2013 2:33 AM, William Herrin wrote: > On Tue, Sep 24, 2013 at 9:49 AM, Nathanael C. Cariaga > wrote: >> I've been Google-ing about if there is such a standard that sets the minimum >> IPv6 advertisement on BGP. My concern is that I am running a network that >> is operating on multiple sites and currently rolling out our IPv6 on the >> perimeter level. Having to get our /48 allocation from our RIR, I figured >> out I would it would be best for us to break down the /48 into smaller >> chunks (i.e /56s) and farm it out to our sites since a single /48 will be >> very big for our single site. > Hi Nathanael, > > Many if not most networks set a limit at /48. Verizon was the last > player of consequence to filter at /32, and they moved to /48 a couple > years ago. A few also try to limit advertisements within ISP space > nearer to /32. Usually not at /32, but a /48 announcement within space > allocated to an ISP won't necessarily be honored. > > If you have distinct networks with distinct routing policies (or can > make a reasonable claim to such) and your RIR is ARIN, you can request > a block size large enough to provide a /48 to each distinct network. A > /44 or whatever. Search through the ARIN NRPM for details. I don't > know about the other RIRs; someone in your region (Asia Pacific?) will > know. > > Regards, > Bill Herrin > > > From nccariaga at stluke.com.ph Wed Sep 25 03:10:52 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 25 Sep 2013 11:10:52 +0800 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: <5242543C.8020709@stluke.com.ph> Hi, I raised actually this concern during our IP resource application. On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. -nathan On 9/25/2013 2:36 AM, Bryan Socha wrote: > Everyone is following the same policies. a /48 PER SITE. did you > request enough addresses from your RIR? > > Bryan Socha > From joelja at bogus.com Wed Sep 25 03:15:03 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 24 Sep 2013 20:15:03 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <5242543C.8020709@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> Message-ID: <52425537.6030103@bogus.com> On 9/24/13 8:10 PM, Nathanael C. Cariaga wrote: > Hi, > > I raised actually this concern during our IP resource application. > > On a personal note, I think /48 IPv6 allocation is more than enough for > our organization to use for at least the next 5-10 years assuming that > this can be farmed out to our multiple sites. What makes this > complicated for us is that we are operating on a multiple sites > (geographically) with each site is doing multi-homing and having a /48 > in each site would be very big waste of IP resources. It's not waste and you should adjust the expectations somewhat. With a /48 You typically have enough bits to do hierachical addressing plans, prefix delegation and other things which you may need but are not currently planning for. > -nathan > > On 9/25/2013 2:36 AM, Bryan Socha wrote: >> Everyone is following the same policies. a /48 PER SITE. did you >> request enough addresses from your RIR? >> >> Bryan Socha >> > > From swmike at swm.pp.se Wed Sep 25 03:25:14 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 25 Sep 2013 05:25:14 +0200 (CEST) Subject: minimum IPv6 announcement size In-Reply-To: <5242543C.8020709@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> Message-ID: On Wed, 25 Sep 2013, Nathanael C. Cariaga wrote: > doing multi-homing and having a /48 in each site would be very big waste > of IP resources. IPv6 was designed with an expectation of having /48 per geographical site and this is perfectly fine. I have a /48 at home. What is more of a concern is to do aggregation in the DFZ, if every size got itself a /48 PI and announced it in the DFZ then the routing system would not be very happy... -- Mikael Abrahamsson email: swmike at swm.pp.se From nurul at apnic.net Wed Sep 25 04:11:42 2013 From: nurul at apnic.net (Nurul Islam) Date: Wed, 25 Sep 2013 04:11:42 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <52423F8A.2040801@stluke.com.ph> Message-ID: I believe you can get multiple /48 from APNIC. You will not be evaluated under HD ratio but as discrete network (no iBGP running among them). Here it is the policy [http://www.apnic.net/policy/ipv6-address-policy#5.5.2] Regards Roman On 25/09/13 11:42 AM, "Nathanael C. Cariaga" wrote: >We got our /48 from APNIC.. > >-nathan > >On 9/25/2013 2:18 AM, Owen DeLong wrote: >> On Sep 24, 2013, at 11:00 AM, Randy Bush wrote: >> >>>> I am running a network that is operating on multiple sites and >>>> currently rolling out our IPv6 on the perimeter level. Having to >>>> get our /48 allocation from our RIR >>> excuse, but which rir handed out a /48 under which policy? >>> >>> randy >> ARIN will give out /48s to end users. >> >> AfriNIC will give out /48s to end users. >> >> I believe (but haven't verified) that this is also possible from APNIC >>and LACNIC. >> >> Someone else mentioned that RIPE will as well. >> >> Owen >> > > From nccariaga at stluke.com.ph Wed Sep 25 05:25:25 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 25 Sep 2013 13:25:25 +0800 Subject: minimum IPv6 announcement size In-Reply-To: References: Message-ID: <524273C5.3080103@stluke.com.ph> I'll revisit our application then. Thank you for the info. -nathan On 9/25/2013 12:11 PM, Nurul Islam wrote: > I believe you can get multiple /48 from APNIC. You will not be evaluated > under HD ratio but as discrete network (no iBGP running among them). Here > it is the policy [http://www.apnic.net/policy/ipv6-address-policy#5.5.2] > > Regards > > Roman > > > > On 25/09/13 11:42 AM, "Nathanael C. Cariaga" > wrote: > >> We got our /48 from APNIC.. >> >> -nathan >> >> On 9/25/2013 2:18 AM, Owen DeLong wrote: >>> On Sep 24, 2013, at 11:00 AM, Randy Bush wrote: >>> >>>>> I am running a network that is operating on multiple sites and >>>>> currently rolling out our IPv6 on the perimeter level. Having to >>>>> get our /48 allocation from our RIR >>>> excuse, but which rir handed out a /48 under which policy? >>>> >>>> randy >>> ARIN will give out /48s to end users. >>> >>> AfriNIC will give out /48s to end users. >>> >>> I believe (but haven't verified) that this is also possible from APNIC >>> and LACNIC. >>> >>> Someone else mentioned that RIPE will as well. >>> >>> Owen >>> >> From mansaxel at besserwisser.org Wed Sep 25 05:50:51 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 25 Sep 2013 07:50:51 +0200 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> Message-ID: <20130925055051.GC20612@besserwisser.org> Subject: Re: minimum IPv6 announcement size Date: Tue, Sep 24, 2013 at 08:00:44AM -1000 Quoting Randy Bush (randy at psg.com): > > I am running a network that is operating on multiple sites and > > currently rolling out our IPv6 on the perimeter level. Having to > > get our /48 allocation from our RIR > > excuse, but which rir handed out a /48 under which policy? Any of them? % Information related to '2001:67c:d8::/48' inet6num: 2001:67c:d8::/48 netname: SR-V6 descr: Sveriges Radio AB country: SE org: ORG-SR18-RIPE admin-c: MN1334-RIPE admin-c: LEW3-RIPE tech-c: MN1334-RIPE tech-c: LEW3-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-by: SR-MNT mnt-routes: SR-MNT mnt-domains: SR-MNT source: RIPE # Filtered -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now, let's SEND OUT for QUICHE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mansaxel at besserwisser.org Wed Sep 25 05:52:16 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 25 Sep 2013 07:52:16 +0200 Subject: minimum IPv6 announcement size In-Reply-To: <5242543C.8020709@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> Message-ID: <20130925055216.GD20612@besserwisser.org> Subject: Re: minimum IPv6 announcement size Date: Wed, Sep 25, 2013 at 11:10:52AM +0800 Quoting Nathanael C. Cariaga (nccariaga at stluke.com.ph): > Hi, > > I raised actually this concern during our IP resource application. > > On a personal note, I think /48 IPv6 allocation is more than enough > for our organization to use for at least the next 5-10 years > assuming that this can be farmed out to our multiple sites. What > makes this complicated for us is that we are operating on a multiple > sites (geographically) with each site is doing multi-homing and > having a /48 in each site would be very big waste of IP resources. If you've got island networks w/o links between you SHOULD request a /48 per site. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Pardon me, but do you know what it means to be TRULY ONE with your BOOTH! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mpalmer at hezmatt.org Wed Sep 25 08:16:47 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 25 Sep 2013 18:16:47 +1000 Subject: iOS 7 update traffic In-Reply-To: <201309240136.r8O1aUCo091712@aurora.sol.net> References: <5240E24B.3080001@alvarezp.ods.org> <201309240136.r8O1aUCo091712@aurora.sol.net> Message-ID: <20130925081647.GW6478@hezmatt.org> On Mon, Sep 23, 2013 at 08:36:30PM -0500, Joe Greco wrote: > > That's just the typical Bittorrent /client/, but the idea of using > > Bittorrent means the /protocol/. A special Bittorrent client could be > > written for ISPs with uploads disabled and Apple could also disable them > > on the update-downloading Bittorrent client for the phones. > > > > The clients (be it Bittorrent or not) would still download the MD5 hash > > after the download finishes to verify the integrity of the download, and > > Apple would still be able to measure the amount of downloaded images. > > So then all the networks that have done $things to BitTorrent to demote it > to second-rate traffic will suddenly have a bunch of very angry Apple fans > whose downloads are mysteriously having issues. Sounds like a win to me. - Matt -- "Python is a rich scripting language offering a lot of the power of C++ while retaining the ease of use of VBscript." -- The PyWin32 documentation From owen at delong.com Wed Sep 25 13:45:02 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Sep 2013 06:45:02 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <5242543C.8020709@stluke.com.ph> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> Message-ID: <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> Each site should get at least a /48. Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. IPv6 is intended to be sparsely allocated. Owen On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga wrote: > Hi, > > I raised actually this concern during our IP resource application. > > On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. > > -nathan > > On 9/25/2013 2:36 AM, Bryan Socha wrote: >> Everyone is following the same policies. a /48 PER SITE. did you >> request enough addresses from your RIR? >> >> Bryan Socha >> > From BECHA at ripe.net Wed Sep 25 14:45:48 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 25 Sep 2013 16:45:48 +0200 Subject: RIPE NCC is Migrating the RIS Dashboard to RIPEstat In-Reply-To: <5242F69B.9090508@ripe.net> References: <5242F69B.9090508@ripe.net> Message-ID: <5242F71C.1060803@ripe.net> Dear colleagues, I would like to remind you of our announcement, made last month. In the coming days, we will be migrating RIS data visualisation to RIPEstat: http://stat.ripe.net We will, therefore, be decommissioning some of the outdated RIS interfaces and tools, and the old backend. We still welcome your feedback, so please let us know your comments so that we can accommodate your needs. More information can be found in the original announcement, below. Regards, Vesna Manojlovic Our Routing Information Service (RIS) has been collecting global BGP routing information for 12 years now. During this period, many different interfaces to analyse and visualise accumulated data have been developed. In line with our long-term goals to provide more consolidated services, we will be integrating the RIS interface's tools and services into RIPEstat. More information about this is detailed in a new RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/improved-routing-information-available-via-ripestat We invite the community to comment on these upcoming changes at MAT-WG: https://www.ripe.net/ripe/groups/wg/mat Please submit any requests for additional features via email to stat at ripe.net so that we can implement these along with the planned migration of tools and features, or have them added to the RIPEstat Roadmap for later consideration: http://roadmap.ripe.net/ripe-stat/ We look forward to your feedback. Regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net From jared at puck.nether.net Wed Sep 25 15:35:57 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 25 Sep 2013 11:35:57 -0400 Subject: BGP Attribute 128 Message-ID: <9F01FD08-ECF7-4660-ADB9-6EB899F90198@puck.nether.net> I'm curious how others are working with customers running code that drop the session with valid BGP attributes. Anyone else monitoring the proliferation of routes with attribute 128? I'm not really in favor of the features vendors have provided, such as this to just drop the attribute or routes. http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/asr1000/irg-attribute-filter.html - Jared From fakrulalam at gmail.com Wed Sep 25 16:16:23 2013 From: fakrulalam at gmail.com (Fakrul Alam Pappu) Date: Wed, 25 Sep 2013 22:16:23 +0600 Subject: BGPlay as a parameter for upstream stability Message-ID: To identify the stability/quality of upstream/transit provider; can we treat BGPlay output as a parameter? If yes, how authentic it would be. -Fakrul From psirt at cisco.com Wed Sep 25 16:21:58 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:21:58 -0400 Subject: Cisco Security Advisory: Cisco IOS Software IPv6 Virtual Fragmentation Reassembly Denial of Service Vulnerability Message-ID: <201309251221.18.ipv6vfr@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software IPv6 Virtual Fragmentation Reassembly Denial of Service Vulnerability Advisory ID: cisco-sa-20130925-ipv6vfr Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the implementation of the virtual fragmentation reassembly (VFR) feature for IP version 6 (IPv6) in Cisco IOS Software could allow an unauthenticated, remote attacker to cause an affected device to hang or reload, resulting in a denial of service (DoS) condition. The vulnerability is due to a race condition while accessing the reassembly queue for IPv6 fragments. An attacker could exploit this vulnerability by sending a crafted stream of valid IPv6 fragments. Repeated exploitation may result in a sustained DoS condition. Cisco has released free software updates that address this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ipv6vfr Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z0ACgkQUddfH3/BbTon8QD+KjqV+g6xJtyPO04NuZLuUhZf nL+yvKaN2zd0d8DNTXYA/joTFXuponHnVUNni/h5NjU2MaS/ZphGQpuinPUZK5I4 =+5KL -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:22:39 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:22:39 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities Message-ID: <201309251222.18.nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Network Address Translation Vulnerabilities Advisory ID: cisco-sa-20130925-nat Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= The Cisco IOS Software implementation of the network address translation (NAT) feature contains three vulnerabilities when translating IP packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-nat Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z0ACgkQUddfH3/BbTqtUwD/fmE/9ONyzNjrIDni2UklV3M2 8ATQxEVFt1L3ZYUlyA4A/Ax+e0PiSL6ojL9bSgGIM7Y//+c7ga9nsau2mV5r/mhM =u9YC -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:23:10 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:23:10 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Zone-Based Firewall and Content Filtering Vulnerability Message-ID: <201309251223.18.cce@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Zone-Based Firewall and Content Filtering Vulnerability Advisory ID: cisco-sa-20130925-cce Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the Zone-Based Firewall (ZBFW) component of Cisco IOS Software could allow an unauthenticated, remote attacker to cause an affected device to hang or reload. The vulnerability is due to improper processing of specific HTTP packets when the device is configured for either Cisco IOS Content Filtering or HTTP application layer gateway (ALG) inspection. An attacker could exploit this vulnerability by sending specific HTTP packets through an affected device. An exploit could allow the attacker to cause an affected device to hang or reload. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-cce Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6ZwACgkQUddfH3/BbTrfJAEAhPGE6zVhhuxL2YSSqZ9jQ7iB WSXFXha2WZL3zp//WtgA/3B0mrj1OwGNpUouOUDM20cvsxM8RGUUGJqn/UDgbdi4 =yiSp -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:23:38 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:23:38 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Multicast Network Time Protocol Denial of Service Vulnerability Message-ID: <201309251223.18.ntp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Multicast Network Time Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20130925-ntp Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the implementation of the Network Time Protocol (NTP) feature in Cisco IOS Software could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a denial of service (DoS) condition. The vulnerability is due to the improper handling of multicast NTP packets that are sent to an affected device encapsulated in a Multicast Source Discovery Protocol (MSDP) Source-Active (SA) message from a configured MSDP peer. An attacker could exploit this vulnerability by sending multicast NTP packets to an affected device. Repeated exploitation could result in a sustained DoS condition. Cisco has released free software updates that address this vulnerability. A workaround is available to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ntp Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z4ACgkQUddfH3/BbTrDQAD/ZDkeJZRsPNylydioU1nw+yJ+ 8frzFaXjO3g0qqocPjMA/R95PEhewfO2A29QwIyGKLw52QkiSt1sd6e2YsDIN84B =Xa3k -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:24:07 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:24:07 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Queue Wedge Denial of Service Vulnerability Message-ID: <201309251224.18.wedge@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Queue Wedge Denial of Service Vulnerability Advisory ID: cisco-sa-20130925-wedge Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the T1/E1 driver queue implementation of Cisco IOS Software could allow an unauthenticated, remote attacker to cause an interface wedge condition, which could lead to loss of connectivity, loss of routing protocol adjacency, and could result in a denial of service (DoS) scenario. The vulnerability is due to incorrect implementation of the T1/E1 driver queue. An attacker could exploit this vulnerability by sending bursty traffic through the affected interface driver. Repeated exploitation could cause a DoS condition. Workarounds to mitigate this vulnerability are available. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-wedge Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z4ACgkQUddfH3/BbTpEGAD/Ss7zOJllV49QzpGTtRmbXsjK bgypwesmtU9UdOC39kUA/1FGKQ1kn08R7dJ2PcbbLo8PP0OCtQrSyxTeBtmcIsHw =xChY -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:24:34 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:24:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software DHCP Denial of Service Vulnerability Message-ID: <201309251224.18.dhcp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software DHCP Denial of Service Vulnerability Advisory ID: cisco-sa-20130925-dhcp Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the DHCP implementation of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability occurs during the parsing of crafted DHCP packets. An attacker could exploit this vulnerability by sending crafted DHCP packets to an affected device that has the DHCP server or DHCP relay feature enabled. An exploit could allow the attacker to cause a reload of an affected device. Cisco has released free software updates that address this vulnerability. There are no workarounds to this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-dhcp Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z0ACgkQUddfH3/BbToKcAD/Y0gUqLxw1mMs8yqeoREI7H7x /bU2ckuJKhhzJmmqpjEA/3ekjyVjTXoLRR9vQrYnAeJSE4opTRXYTlJtZesv4tIw =zzbX -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:25:03 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:25:03 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Internet Key Exchange Memory Leak Vulnerability Message-ID: <201309251225.18.ike@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Internet Key Exchange Memory Leak Vulnerability Advisory ID: cisco-sa-20130925-ike Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the Internet Key Exchange (IKE) protocol of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak that could lead to a device reload. The vulnerability is due to incorrect handling of malformed IKE packets by the affected software. An attacker could exploit this vulnerability by sending crafted IKE packets to a device configured with features that leverage IKE version 1 (IKEv1). Although IKEv1 is automatically enabled on a Cisco IOS Software and Cisco IOS XE Software when IKEv1 or IKE version 2 (IKEv2) is configured, the vulnerability can be triggered only by sending a malformed IKEv1 packet. In specific conditions, normal IKEv1 packets can also cause an affected release of Cisco IOS Software to leak memory. Only IKEv1 is affected by this vulnerability. An exploit could cause Cisco IOS Software not to release allocated memory, causing a memory leak. A sustained attack may result in a device reload. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ike Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z0ACgkQUddfH3/BbTqlXwEAgh4+BJHc44EE50FqW2sNNo57 l9ZxzwJvzF2Tju/Fa18A/2MRGlAmkyvQZTQ/FT/j9wgW+epGNKAZ+XOL7Kwy6Luz =A0a+ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 25 16:25:32 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Sep 2013 12:25:32 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Resource Reservation Protocol Interface Queue Wedge Vulnerability Message-ID: <201309251225.18.rsvp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Resource Reservation Protocol Interface Queue Wedge Vulnerability Advisory ID: cisco-sa-20130925-rsvp Revision 1.0 For Public Release 2013 September 25 16:00 UTC (GMT) - ---------------------------------------------------------------------- Summary ======= A vulnerability in the Resource Reservation Protocol (RSVP) feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to trigger an interface queue wedge on the affected device. The vulnerability is due to improper parsing of UDP RSVP packets. An attacker could exploit this vulnerability by sending UDP port 1698 RSVP packets to the vulnerable device. An exploit could cause Cisco IOS Software and Cisco IOS XE Software to incorrectly process incoming packets, resulting in an interface queue wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other denial of service (DoS) conditions. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-rsvp Note: The September 25, 2013, Cisco IOS Software Security Advisory bundled publication includes eight Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlJC6Z4ACgkQUddfH3/BbTq2kwEAj4vA8C+M60R9Q3Ytrpq0jvRh HY+VBYi3HMwsH+PmACYA/iBdUCcbxAHyHmip/8yVjs44Ej2r4JLFfvg6vLCQ8o2G =kOF1 -----END PGP SIGNATURE----- From jcurran at arin.net Wed Sep 25 20:39:48 2013 From: jcurran at arin.net (John Curran) Date: Wed, 25 Sep 2013 20:39:48 +0000 Subject: The block message is 521 DNSRBL: Blocked for abuse In-Reply-To: References: <009501ceb4c0$339c12b0$9ad43810$@verizon.net> <002301ceb588$673688d0$35a39a70$@iname.com> Message-ID: On Sep 24, 2013, at 3:38 PM, William Herrin wrote: > On Thu, Sep 19, 2013 at 6:34 PM, Frank Bulk wrote: >> Is there an indication or separate list that shows if they've been recycled? > > Hi Frank, > > Looks like they post a "remove" message when a block is returned to > the registry and then an "add' when it's reassigned. For example, > Derrick's block (74.112.96.0/22) was "removed" in November: > > http://lists.arin.net/pipermail/arin-issued/2012-November/001446.html > > and then "added" in March: > > http://lists.arin.net/pipermail/arin-issued/2013-March/001561.html Basically correct; one small note is that the "Remove" message is actually not when the block is returned to ARIN, but after the end of the hold-down period (it may be several months later that a block in the available pool is actually issued, depending on the already existing inventory and rate of demand for any given block size.) FYI, /John John Curran President and CEO ARIN From glen.kent at gmail.com Thu Sep 26 00:18:04 2013 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 26 Sep 2013 05:48:04 +0530 Subject: Sudan disconnected from the Internet Message-ID: Hi, The report from renesys states that "We initially stated that Sudan?s outage began at 12:47 UTC because that was when virtually all Sudanese routed networks were withdrawn from the global routing table" http://www.renesys.com/2013/09/internet-blackout-sudan/ If its a deliberate action to remove Sudan from the Internet then what exactly would the ISPs in Sudan have done? Drop their peering sessions with the three International gateways? How were the "Sudanese routed networks withdrawn"? Glen From tammy-lists at wiztech.biz Thu Sep 26 00:25:22 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 25 Sep 2013 18:25:22 -0600 Subject: Sudan disconnected from the Internet In-Reply-To: References: Message-ID: <52437EF2.20801@wiztech.biz> On 9/25/13 18:18:04, Glen Kent wrote: > Hi, > > The report from renesys states that > > "We initially stated that Sudan?s outage began at 12:47 UTC because that > was when virtually all Sudanese routed networks were withdrawn from the > global routing table" > > http://www.renesys.com/2013/09/internet-blackout-sudan/ > > If its a deliberate action to remove Sudan from the Internet then what > exactly would the ISPs in Sudan have done? Drop their peering sessions with > the three International gateways? How were the "Sudanese routed networks > withdrawn"? > > Glen > with the old fashioned pair of diagonal cutters applied to fiber? From tammy-lists at wiztech.biz Thu Sep 26 00:34:37 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 25 Sep 2013 18:34:37 -0600 Subject: Sudan disconnected from the Internet In-Reply-To: <52438006.5060506@utc.edu> References: <52437EF2.20801@wiztech.biz> <52438006.5060506@utc.edu> Message-ID: <5243811D.8060301@wiztech.biz> On 9/25/13 18:29:58, Jeff Kell wrote: > On 9/25/2013 8:25 PM, Tammy Firefly wrote: >> with the old fashioned pair of diagonal cutters applied to fiber? > > Yes, interesting to know if it was cut fiber, pressure on the inside > providers (or their feeds), or pressure on the outside providers. > > Traceroutes lend any clue? > > Jeff > If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? From wbailey at satelliteintelligencegroup.com Thu Sep 26 00:38:09 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 26 Sep 2013 00:38:09 +0000 Subject: Sudan disconnected from the Internet In-Reply-To: <5243811D.8060301@wiztech.biz> Message-ID: http://abcnews.go.com/International/wireStory/sudan-security-clashes-subsid y-protesters-20360418 On 9/25/13 5:34 PM, "Tammy Firefly" wrote: >On 9/25/13 18:29:58, Jeff Kell wrote: >> On 9/25/2013 8:25 PM, Tammy Firefly wrote: >>> with the old fashioned pair of diagonal cutters applied to fiber? >> >> Yes, interesting to know if it was cut fiber, pressure on the inside >> providers (or their feeds), or pressure on the outside providers. >> >> Traceroutes lend any clue? >> >> Jeff >> > >If the government did it, I guarantee it was cut fiber. That makes it >difficult to quickly restore. One has to wonder whats going on there >right now that they dont want the world to know about? > > > From tammy-lists at wiztech.biz Thu Sep 26 00:40:30 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Wed, 25 Sep 2013 18:40:30 -0600 Subject: Sudan disconnected from the Internet In-Reply-To: References: Message-ID: <5243827E.6070807@wiztech.biz> On 9/25/13 18:38:09, Warren Bailey wrote: > http://abcnews.go.com/International/wireStory/sudan-security-clashes-subsid > y-protesters-20360418 > > On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > >> On 9/25/13 18:29:58, Jeff Kell wrote: >>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: >>>> with the old fashioned pair of diagonal cutters applied to fiber? >>> >>> Yes, interesting to know if it was cut fiber, pressure on the inside >>> providers (or their feeds), or pressure on the outside providers. >>> >>> Traceroutes lend any clue? >>> >>> Jeff >>> >> >> If the government did it, I guarantee it was cut fiber. That makes it >> difficult to quickly restore. One has to wonder whats going on there >> right now that they dont want the world to know about? >> >> >> > Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well. From george.herbert at gmail.com Thu Sep 26 00:41:27 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 25 Sep 2013 17:41:27 -0700 Subject: Sudan disconnected from the Internet In-Reply-To: <5243811D.8060301@wiztech.biz> References: <52437EF2.20801@wiztech.biz> <52438006.5060506@utc.edu> <5243811D.8060301@wiztech.biz> Message-ID: http://abcnews.go.com/International/wireStory/sudan-security-clashes-subsidy-protesters-20360418 On Wed, Sep 25, 2013 at 5:34 PM, Tammy Firefly wrote: > On 9/25/13 18:29:58, Jeff Kell wrote: > > On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >> with the old fashioned pair of diagonal cutters applied to fiber? > > > > Yes, interesting to know if it was cut fiber, pressure on the inside > > providers (or their feeds), or pressure on the outside providers. > > > > Traceroutes lend any clue? > > > > Jeff > > > > If the government did it, I guarantee it was cut fiber. That makes it > difficult to quickly restore. One has to wonder whats going on there > right now that they dont want the world to know about? > > > > -- -george william herbert george.herbert at gmail.com From wbailey at satelliteintelligencegroup.com Thu Sep 26 00:43:28 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 26 Sep 2013 00:43:28 +0000 Subject: Sudan disconnected from the Internet In-Reply-To: <5243827E.6070807@wiztech.biz> Message-ID: We make Ku-band backpacks for this type of scenario. I would give it 12-18 hours before you see CNN light up with live feeds.. I didn't even KNOW this was happening prior to them doing this. Seems like cutting off access would alert a lot more folks than some people wrecking Sudan over fuel subsidies?? Doesn't look like it's been picked up by CNN substantially yet, but I imagine we'll get "breaking news" soon enough. Would be interesting to see if it was a forced drop or did they actually just take a pair of scissors and murder the internets? On 9/25/13 5:40 PM, "Tammy Firefly" wrote: >On 9/25/13 18:38:09, Warren Bailey wrote: >> >>http://abcnews.go.com/International/wireStory/sudan-security-clashes-subs >>id >> y-protesters-20360418 >> >> On 9/25/13 5:34 PM, "Tammy Firefly" wrote: >> >>> On 9/25/13 18:29:58, Jeff Kell wrote: >>>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: >>>>> with the old fashioned pair of diagonal cutters applied to fiber? >>>> >>>> Yes, interesting to know if it was cut fiber, pressure on the inside >>>> providers (or their feeds), or pressure on the outside providers. >>>> >>>> Traceroutes lend any clue? >>>> >>>> Jeff >>>> >>> >>> If the government did it, I guarantee it was cut fiber. That makes it >>> difficult to quickly restore. One has to wonder whats going on there >>> right now that they dont want the world to know about? >>> >>> >>> >> > >Then its quite likely the government cut the fiber to cover that up :) >wouldnt surprise me if they cut it in multiple places as well. > From glen.kent at gmail.com Thu Sep 26 00:45:48 2013 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 26 Sep 2013 06:15:48 +0530 Subject: Sudan disconnected from the Internet In-Reply-To: <5243827E.6070807@wiztech.biz> References: <5243827E.6070807@wiztech.biz> Message-ID: Thats disappointing. I was imagining some networking trick with which Sudan was being disconnected (prefix hijacking, etc) - didnt strike me that this was also an option available! :-) On Thu, Sep 26, 2013 at 6:10 AM, Tammy Firefly wrote: > On 9/25/13 18:38:09, Warren Bailey wrote: > > > http://abcnews.go.com/International/wireStory/sudan-security-clashes-subsid > > y-protesters-20360418 > > > > On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > > > >> On 9/25/13 18:29:58, Jeff Kell wrote: > >>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >>>> with the old fashioned pair of diagonal cutters applied to fiber? > >>> > >>> Yes, interesting to know if it was cut fiber, pressure on the inside > >>> providers (or their feeds), or pressure on the outside providers. > >>> > >>> Traceroutes lend any clue? > >>> > >>> Jeff > >>> > >> > >> If the government did it, I guarantee it was cut fiber. That makes it > >> difficult to quickly restore. One has to wonder whats going on there > >> right now that they dont want the world to know about? > >> > >> > >> > > > > Then its quite likely the government cut the fiber to cover that up :) > wouldnt surprise me if they cut it in multiple places as well. > > > From jfmezei_nanog at vaxination.ca Thu Sep 26 01:03:19 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 25 Sep 2013 21:03:19 -0400 Subject: Sudan disconnected from the Internet In-Reply-To: References: Message-ID: <524387D7.2040503@vaxination.ca> On 13-09-25 20:43, Warren Bailey wrote: > We make Ku-band backpacks for this type of scenario. I would give it 12-18 > hours before you see CNN light up with live feeds.. Why would an entertainment network cover real news ? BBC or AlJazeera are better news sources for stuff that happens more than 2 bocks away from CNN's atlanta offices. BBC: 25 September 2013 Last updated at 17:54 ET Sudan fuel unrest: Many die in Khartoum as riots continue http://www.bbc.co.uk/news/world-africa-24272835 Al Jazeera: Sudan protests over fuel prices turn deadly Security forces use tear gas to disperse demonstrators in Khartoum amid simmering anger over subsidy cuts. Last Modified: 25 Sep 2013 18:08 > http://www.aljazeera.com/news/africa/2013/09/sudan-protests-over-fuel-turns-deadly-2013925104639248955.html Neither article mentions internet disconnection. From patrick at ianai.net Thu Sep 26 01:04:08 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 25 Sep 2013 21:04:08 -0400 Subject: Sudan disconnected from the Internet In-Reply-To: <524387D7.2040503@vaxination.ca> References: <524387D7.2040503@vaxination.ca> Message-ID: It's not a fiber cut. It did come back for a while at least. -- TTFN, patrick On Sep 25, 2013, at 21:03 , Jean-Francois Mezei wrote: > On 13-09-25 20:43, Warren Bailey wrote: >> We make Ku-band backpacks for this type of scenario. I would give it 12-18 >> hours before you see CNN light up with live feeds.. > > Why would an entertainment network cover real news ? > > BBC or AlJazeera are better news sources for stuff that happens more > than 2 bocks away from CNN's atlanta offices. > > BBC: > 25 September 2013 Last updated at 17:54 ET > > Sudan fuel unrest: Many die in Khartoum as riots continue > http://www.bbc.co.uk/news/world-africa-24272835 > > > Al Jazeera: > Sudan protests over fuel prices turn deadly > Security forces use tear gas to disperse demonstrators in Khartoum amid > simmering anger over subsidy cuts. > Last Modified: 25 Sep 2013 18:08 > >> http://www.aljazeera.com/news/africa/2013/09/sudan-protests-over-fuel-turns-deadly-2013925104639248955.html > > Neither article mentions internet disconnection. > -------------- 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: From wbailey at satelliteintelligencegroup.com Thu Sep 26 01:12:30 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 26 Sep 2013 01:12:30 +0000 Subject: Sudan disconnected from the Internet In-Reply-To: <524387D7.2040503@vaxination.ca> Message-ID: If they don't have news of the internet connection, we're probably both looking at the wrong news feed. ;) Patrick sent a twitter image showing the murder in traffic, but it looks like after the spike SOMETHING came back?? If it was scissor murdered, I would assume it would have been flat lined across the board. Either way, I'm sure this is related and they're monitoring this list closely.. ;) On 9/25/13 6:03 PM, "Jean-Francois Mezei" wrote: >On 13-09-25 20:43, Warren Bailey wrote: >> We make Ku-band backpacks for this type of scenario. I would give it >>12-18 >> hours before you see CNN light up with live feeds.. > >Why would an entertainment network cover real news ? > >BBC or AlJazeera are better news sources for stuff that happens more >than 2 bocks away from CNN's atlanta offices. > >BBC: >25 September 2013 Last updated at 17:54 ET > >Sudan fuel unrest: Many die in Khartoum as riots continue >http://www.bbc.co.uk/news/world-africa-24272835 > > >Al Jazeera: >Sudan protests over fuel prices turn deadly >Security forces use tear gas to disperse demonstrators in Khartoum amid >simmering anger over subsidy cuts. >Last Modified: 25 Sep 2013 18:08 > >> >>http://www.aljazeera.com/news/africa/2013/09/sudan-protests-over-fuel-tur >>ns-deadly-2013925104639248955.html > >Neither article mentions internet disconnection. > From joelja at bogus.com Thu Sep 26 01:16:18 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 25 Sep 2013 18:16:18 -0700 Subject: Sudan disconnected from the Internet In-Reply-To: <52437EF2.20801@wiztech.biz> References: <52437EF2.20801@wiztech.biz> Message-ID: <52438AE2.1010604@bogus.com> On 9/25/13 5:25 PM, Tammy Firefly wrote: > On 9/25/13 18:18:04, Glen Kent wrote: >> Hi, >> >> The report from renesys states that >> >> "We initially stated that Sudan?s outage began at 12:47 UTC because that >> was when virtually all Sudanese routed networks were withdrawn from the >> global routing table" >> >> http://www.renesys.com/2013/09/internet-blackout-sudan/ >> >> If its a deliberate action to remove Sudan from the Internet then what >> exactly would the ISPs in Sudan have done? Drop their peering sessions with >> the three International gateways? How were the "Sudanese routed networks >> withdrawn"? >> >> Glen >> > > with the old fashioned pair of diagonal cutters applied to fiber? when you have the guns you normally just make a phone call... There's no reason to destroy your infrastructure just to deny the usage of it. > From blake.mailinglist at pfankuch.me Thu Sep 26 02:23:37 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Thu, 26 Sep 2013 02:23:37 +0000 Subject: Suggestion on Fiber tester Message-ID: I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. I don't need something super fancy, just need something that gives a good, bad or "holy crap is that concrete you are testing on" for starters. I am also shooting for about $150-250 tops. Any suggestions? Thanks! Blake From djahandarie at gmail.com Thu Sep 26 03:09:17 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 25 Sep 2013 23:09:17 -0400 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: On Wed, Sep 25, 2013 at 10:23 PM, Blake Pfankuch - Mailing List wrote: > I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. > > I don't need something super fancy, just need something that gives a good, bad or "holy crap is that concrete you are testing on" for starters. I am also shooting for about $150-250 tops. > > Any suggestions? The keyword is Optical Power Meter. There are some all-in-one meters and some simpler meters, it depends on exactly what sort of fiber you're testing and so forth. The more advanced tool is an Optical Time-Domain Reflectometer, which can tell you where the splices, breaks, and their locations are, but they are considerably more expensive and that's not what you're looking for from the sound of it. -- Darius Jahandarie From blake.mailinglist at pfankuch.me Thu Sep 26 03:26:54 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Thu, 26 Sep 2013 03:26:54 +0000 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: To follow up, all of this fiber is mm and all light is sx to sfp. Currently all 1gbit, but it will be repulled as 10gbit capable soon... I guess I'm going to have to be a little less cheap and shoot for something under $1000. I had an off list suggestion of the below listed fluke. Any other suggestions or reccomendations? http://www.flukenetworks.com/datacom-cabling/fiber-testing/SimpliFiber-Pro-Optical-Power-Meter-and-Fiber-Test-Kits Thanks, Blake -----Original Message----- From: Darius Jahandarie [mailto:djahandarie at gmail.com] Sent: Wednesday, September 25, 2013 9:09 PM To: Blake Pfankuch - Mailing List Cc: NANOG (nanog at nanog.org) Subject: Re: Suggestion on Fiber tester On Wed, Sep 25, 2013 at 10:23 PM, Blake Pfankuch - Mailing List wrote: > I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. > > I don't need something super fancy, just need something that gives a good, bad or "holy crap is that concrete you are testing on" for starters. I am also shooting for about $150-250 tops. > > Any suggestions? The keyword is Optical Power Meter. There are some all-in-one meters and some simpler meters, it depends on exactly what sort of fiber you're testing and so forth. The more advanced tool is an Optical Time-Domain Reflectometer, which can tell you where the splices, breaks, and their locations are, but they are considerably more expensive and that's not what you're looking for from the sound of it. -- Darius Jahandarie From sjh at waroffice.net Thu Sep 26 08:53:09 2013 From: sjh at waroffice.net (Steven Hill) Date: Thu, 26 Sep 2013 09:53:09 +0100 (BST) Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: On Thu, 26 Sep 2013, Blake Pfankuch - Mailing List wrote: (snip) > $1000 You might get a JDSU OLP meter for that sort of money... http://www.jdsu.com/en-us/test-and-measurement/products/a-z-product-list/Pages/olp-smart.aspx I've used one of theirs (and a matching source) for buzzing out links at work. Simple enough to use, and can withstand my colleague dropping it off the top of a rack. -- Steven Hill I'm not a goth, I just can't afford the colour license From bmanning at vacation.karoshi.com Thu Sep 26 08:52:50 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 26 Sep 2013 08:52:50 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> Message-ID: <20130926085250.GA8058@vacation.karoshi.com.> sounds just like folks in 1985, talking about IPv4... /bill On Wed, Sep 25, 2013 at 06:45:02AM -0700, Owen DeLong wrote: > Each site should get at least a /48. > > Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. IPv6 is intended to be sparsely allocated. > > Owen > > On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga wrote: > > > Hi, > > > > I raised actually this concern during our IP resource application. > > > > On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. > > > > -nathan > > > > On 9/25/2013 2:36 AM, Bryan Socha wrote: > >> Everyone is following the same policies. a /48 PER SITE. did you > >> request enough addresses from your RIR? > >> > >> Bryan Socha > >> > > > > From nanog at haller.ws Thu Sep 26 09:23:26 2013 From: nanog at haller.ws (Patrick) Date: Thu, 26 Sep 2013 17:23:26 +0800 Subject: minimum IPv6 announcement size In-Reply-To: <20130926085250.GA8058@vacation.karoshi.com.> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> Message-ID: <20130926092325.GM16712@haller.ws> On 2013-09-26 08:52, bmanning at vacation.karoshi.com wrote: > sounds just like folks in 1985, talking about IPv4... Yeah, but who doesn't run CIDR now? Get everyone in the IPv6 pool now; we'll inevitably add hacks later.... From emile.aben at ripe.net Thu Sep 26 10:23:04 2013 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 26 Sep 2013 12:23:04 +0200 Subject: Sudan disconnected from the Internet In-Reply-To: References: <524387D7.2040503@vaxination.ca> Message-ID: <52440B08.7080003@ripe.net> On 26/09/2013 03:04, Patrick W. Gilmore wrote: > It's not a fiber cut. It did come back for a while at least. > > > > This is data from RIPEstat / RIPE Atlas: https://labs.ripe.net/Members/emileaben/sudan-internet-disruptions near-realtime stats of visibility of Sudanese prefixes and ASNs: https://stat.ripe.net/SD#tabId=routing Looks like the number of prefixes went up to about normal again the last hour or so. best regards, Emile Aben RIPE NCC From emile.aben at ripe.net Thu Sep 26 10:43:20 2013 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 26 Sep 2013 12:43:20 +0200 Subject: Sudan disconnected from the Internet In-Reply-To: <52440B08.7080003@ripe.net> References: <524387D7.2040503@vaxination.ca> <52440B08.7080003@ripe.net> Message-ID: <52440FC8.2020508@ripe.net> On 26/09/2013 12:23, Emile Aben wrote: > On 26/09/2013 03:04, Patrick W. Gilmore wrote: >> It's not a fiber cut. It did come back for a while at least. >> >> >> >> > This is data from RIPEstat / RIPE Atlas: > > https://labs.ripe.net/Members/emileaben/sudan-internet-disruptions > > near-realtime stats of visibility of Sudanese prefixes and ASNs: > https://stat.ripe.net/SD#tabId=routing > > Looks like the number of prefixes went up to about normal again the > last hour or so. You'll need to zoom to actually see this, here's the zoomed view: https://stat.ripe.net/widget/country-routing-stats#w.resource=sd&w.zoom_start=1380078150593&w.zoom_end=1380191700000&w.comparison=no > > best regards, > Emile Aben > RIPE NCC > From kmedcalf at dessus.com Thu Sep 26 11:23:23 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 26 Sep 2013 05:23:23 -0600 Subject: Sudan disconnected from the Internet In-Reply-To: Message-ID: <000352419979f04d8c2fc9aec9fe43dc@mail.dessus.com> Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Wednesday, 25 September, 2013 18:43 > To: Tammy Firefly > Cc: nanog at nanog.org > Subject: Re: Sudan disconnected from the Internet > > We make Ku-band backpacks for this type of scenario. I would give it 12- > 18 > hours before you see CNN light up with live feeds.. I didn't even KNOW > this was happening prior to them doing this. Seems like cutting off > access > would alert a lot more folks than some people wrecking Sudan over fuel > subsidies?? > > Doesn't look like it's been picked up by CNN substantially yet, but I > imagine we'll get "breaking news" soon enough. Would be interesting to > see > if it was a forced drop or did they actually just take a pair of > scissors > and murder the internets? > > On 9/25/13 5:40 PM, "Tammy Firefly" wrote: > > >On 9/25/13 18:38:09, Warren Bailey wrote: > >> > >>http://abcnews.go.com/International/wireStory/sudan-security-clashes- > subs > >>id > >> y-protesters-20360418 > >> > >> On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > >> > >>> On 9/25/13 18:29:58, Jeff Kell wrote: > >>>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >>>>> with the old fashioned pair of diagonal cutters applied to fiber? > >>>> > >>>> Yes, interesting to know if it was cut fiber, pressure on the > inside > >>>> providers (or their feeds), or pressure on the outside providers. > >>>> > >>>> Traceroutes lend any clue? > >>>> > >>>> Jeff > >>>> > >>> > >>> If the government did it, I guarantee it was cut fiber. That makes > it > >>> difficult to quickly restore. One has to wonder whats going on > there > >>> right now that they dont want the world to know about? > >>> > >>> > >>> > >> > > > >Then its quite likely the government cut the fiber to cover that up :) > >wouldnt surprise me if they cut it in multiple places as well. > > > From universe at truemetal.org Thu Sep 26 11:36:39 2013 From: universe at truemetal.org (Markus) Date: Thu, 26 Sep 2013 13:36:39 +0200 Subject: gmail.com contact Message-ID: <52441C47.6070704@truemetal.org> Hi list, We had a user account compromised a couple of days ago, spam naturally, and now the IP is blocked for delivering to gmail.com. We've completed the delivery problem form at support.google.com but if there is any way to speed up the process our customer and we would appreciate it. Could anyone put me in touch with a gmail.com contact? Thanks! Markus From cconn at b2b2c.ca Thu Sep 26 14:42:50 2013 From: cconn at b2b2c.ca (Chris Conn) Date: Thu, 26 Sep 2013 10:42:50 -0400 Subject: gmail.com contact In-Reply-To: References: Message-ID: <524447EA.9090904@b2b2c.ca> : > > -----Original Message----- > From: Markus [mailto:universe at truemetal.org] > Sent: 26 septembre 2013 07:37 > To: nanog at nanog.org > Subject: gmail.com contact > > Hi list, > > We had a user account compromised a couple of days ago, spam naturally, and now the IP is blocked for delivering to gmail.com. We've completed the delivery problem form at support.google.com but if there is any way to speed up the process our customer and we would appreciate it. Could anyone put me in touch with a gmail.com contact? > > Hi, Good luck. I have been going through the "regular channels" for over a month, to try and de-list a server that has not sent an email for over a month to Google or anyone for that matter, and no such luck. If you get a hold of somebody, pls forward me contact info. I am trying again this morning, I will do the same for you. Cheers, Chris From jcurran at istaff.org Thu Sep 26 15:07:03 2013 From: jcurran at istaff.org (John Curran) Date: Thu, 26 Sep 2013 11:07:03 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: <20130926085250.GA8058@vacation.karoshi.com> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> Message-ID: <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> On Sep 26, 2013, at 4:52 AM, bmanning at vacation.karoshi.com wrote: > sounds just like folks in 1985, talking about IPv4... If there were ever were a need for an market/settlement model, it is with respect to routing table slots. As it is, we have no real feedback mechanism in the present system, just conventions that are variably enforced depending on relative stature of the parties having the discussion. Externalizing the true cost of having a prefix routed would create a more equitable and fair environment (i.e. knowledge that you could have any prefix globally routed for a fairly predictable cost, and ability to weigh the benefits of that versus taking a prefix from your ISP.) It might even spur research into various interesting alternatives such routing costs for smaller scopes (regional, geographic, etc.) and cost implications and technical tradeoffs from various alternative mobility schemes. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal & competitive aspects. However, it would at least be doing something more than crossing our fingers and just hoping for the best out of today's "IPv6 prefixes for all"... Another benefit of such a system (for those fans of market-based approaches) is that we could better utilize IPv4, rather than the currently implied "/24 is routable, /25 is not" filter-based approach which may not survive the market pressures associated with IPv4 depletion in any case... FYI, /John Disclaimer: My views alone. Feel free to ignore this message as desired. From niels=nanog at bakker.net Thu Sep 26 15:43:01 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 26 Sep 2013 17:43:01 +0200 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: <20130926154301.GK3108@burnout.tpb.net> * blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) [Thu 26 Sep 2013, 05:28 CEST]: >To follow up, all of this fiber is mm and all light is sx to sfp. >Currently all 1gbit, but it will be repulled as 10gbit capable >soon... I guess I'm going to have to be a little less cheap and >shoot for something under $1000. I'm not aware of testers in your price range that will tell you "This fiber will/will not work for 10GbE" but can second the recommendation for an OTDR, especially if you have metro fibers. If you're repulling (I'm unfamiliar with the word but assume you mean taking out current infrastructure and putting in new fiber through existing ducts), why not go singlemode? That will save you so much headaches with 10G, and SFP optics are only slightly more expensive. -- Niels. From Marla.Azinger at FTR.com Thu Sep 26 16:16:34 2013 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Thu, 26 Sep 2013 16:16:34 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <20130926092325.GM16712@haller.ws> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <20130926092325.GM16712@haller.ws> Message-ID: There are many ways to mediate this. No matter what one is chosen a balance between market, Networks and policy will need to be met. And in the end Networks will do what is best for their network. However if there is a norm of some kind, then at least there will be a target to hover around. Market & Networks- Pro- Entities managing the health of their network would be less willing to route what would result in overload. Con- The more financially healthy Entities can afford faster turn over and burn to new routers and circuit upgrades. The upper hand of growth goes to them since overload wouldn't be as much as an internal issue as it would be to other smaller networks. The global scheme gets lost in the eye of the mighty dollar. This is not anything new market pattern wise but Larger/Financially healthy entities would survive better than any smaller provider. Policy Pro- there would be a set standard to target Con- policy is managed by the community and not always supporting every business model equally. Plus policy can become a moving target as we have witnessed with IPv4. List Publishing-Policy Pro- qualified ASN's are approved a range of subnet size of route advertisements and any "too specific/smaller" advertisements are ignored if not on the list. Con- this is policy. No one tells a network what to do. Set Boundary policy Pro- something exists as a target to help manage the issue Con- policy is very likely to become a moving target. No one tells a network what to do. Keep Head in Sand Pro- Happy Con- Calamity...but when? Or will there be a new option...the next best thing. Hope in one hand and @#$$ in the other. One usually fills up faster. Somehow the community needs to choose one of these paths. My 2 cents Marla -----Original Message----- From: Patrick [mailto:nanog at haller.ws] Sent: Thursday, September 26, 2013 2:23 AM To: bmanning at vacation.karoshi.com Cc: nanog at nanog.org Subject: Re: minimum IPv6 announcement size On 2013-09-26 08:52, bmanning at vacation.karoshi.com wrote: > sounds just like folks in 1985, talking about IPv4... Yeah, but who doesn't run CIDR now? Get everyone in the IPv6 pool now; we'll inevitably add hacks later.... From niels=nanog at bakker.net Thu Sep 26 16:53:10 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 26 Sep 2013 18:53:10 +0200 Subject: Suggestion on Fiber tester In-Reply-To: <20130926154301.GK3108@burnout.tpb.net> References: <20130926154301.GK3108@burnout.tpb.net> Message-ID: <20130926165310.GM3108@burnout.tpb.net> Welp. Not my duplicate (Received: headers show it happened inside the nanog mailing list server). Already asked them to investigate. -- Niels. From bill at herrin.us Thu Sep 26 17:26:48 2013 From: bill at herrin.us (William Herrin) Date: Thu, 26 Sep 2013 13:26:48 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: On Thu, Sep 26, 2013 at 11:07 AM, John Curran wrote: > On Sep 26, 2013, at 4:52 AM, bmanning at vacation.karoshi.com wrote: > >> sounds just like folks in 1985, talking about IPv4... > > If there were ever were a need for an market/settlement model, it is with respect > to routing table slots. > That's not to say that establishing a framework for externalizing routing costs would > be easy; it's a complicated and twisted matter, and also fraught with various legal & > competitive aspects. Hi John, That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard: 1. The International Clearinghouse Every BGP participant files with a clearinghouse, specifying: a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network. Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity. The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out. The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters. >From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in the organization. A couple billion dollars per year if the routing table maintained its current size. 2. The partial routing scenario Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser. For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation. 3. The routing overlay Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress. The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table. Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination. Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From collin at averysmallbird.com Thu Sep 26 00:58:41 2013 From: collin at averysmallbird.com (Collin Anderson) Date: Wed, 25 Sep 2013 20:58:41 -0400 Subject: Sudan disconnected from the Internet In-Reply-To: References: <5243827E.6070807@wiztech.biz> Message-ID: My recollection is that Renesys classified Sudan as a country vulnerable to disconnection due to low diversification of international transit; the old authoritarian preference on monopolizing the gateways has its advantages. I have been monitoring responsive hosts using ZMap every 15 minutes or so since afternoon. However, it seems probable from the incremental disconnect that this was a legal compliance situation (a fax to the ISP), rather than flipping a switch or cutting a wire? cda.io/r/sudan_1380162900_ICMP.png On Wed, Sep 25, 2013 at 8:43 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > We make Ku-band backpacks for this type of scenario. I would give it 12-18 > hours before you see CNN light up with live feeds.. I didn't even KNOW > this was happening prior to them doing this. Seems like cutting off access > would alert a lot more folks than some people wrecking Sudan over fuel > subsidies?? > > Doesn't look like it's been picked up by CNN substantially yet, but I > imagine we'll get "breaking news" soon enough. Would be interesting to see > if it was a forced drop or did they actually just take a pair of scissors > and murder the internets? > > On 9/25/13 5:40 PM, "Tammy Firefly" wrote: > > >On 9/25/13 18:38:09, Warren Bailey wrote: > >> > >> > http://abcnews.go.com/International/wireStory/sudan-security-clashes-subs > >>id > >> y-protesters-20360418 > >> > >> On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > >> > >>> On 9/25/13 18:29:58, Jeff Kell wrote: > >>>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >>>>> with the old fashioned pair of diagonal cutters applied to fiber? > >>>> > >>>> Yes, interesting to know if it was cut fiber, pressure on the inside > >>>> providers (or their feeds), or pressure on the outside providers. > >>>> > >>>> Traceroutes lend any clue? > >>>> > >>>> Jeff > >>>> > >>> > >>> If the government did it, I guarantee it was cut fiber. That makes it > >>> difficult to quickly restore. One has to wonder whats going on there > >>> right now that they dont want the world to know about? > >>> > >>> > >>> > >> > > > >Then its quite likely the government cut the fiber to cover that up :) > >wouldnt surprise me if they cut it in multiple places as well. > > > > > -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From tempestterror at gmail.com Thu Sep 26 16:47:55 2013 From: tempestterror at gmail.com (Tempest) Date: Thu, 26 Sep 2013 09:47:55 -0700 Subject: Radware vs Arbor Message-ID: Doing a bunch of research, and I can't find a meaningful comparison of these two products. Work for a carrier, and I am looking at implementing a DDoS mitigation service that we can sell to our customers. Radware is cheaper, but I am seeing a lot of noise in various forums that makes me question their viability for what we need. Arbor has most of the market, and I assume there is good reason for it. Both companies seem to be very deceptive about how they compare to the other. Anyone out there with good hands on experience that can compare? Not interested in input from either company, we get plenty of that already. Good experience, or links to good write ups would be excellent... Davis B. From kate at quadranet.com Thu Sep 26 17:02:19 2013 From: kate at quadranet.com (Kate Gerry) Date: Thu, 26 Sep 2013 10:02:19 -0700 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F6E7D8EBAC45@EXCH> If you're looking for cheap then go for a RY3200C, it retails for around $140. Kate From chuckchurch at gmail.com Thu Sep 26 17:39:06 2013 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 26 Sep 2013 13:39:06 -0400 Subject: Sudan disconnected from the Internet In-Reply-To: <000352419979f04d8c2fc9aec9fe43dc@mail.dessus.com> References: <000352419979f04d8c2fc9aec9fe43dc@mail.dessus.com> Message-ID: <00b601cebadf$50b86c20$f2294460$@gmail.com> Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade. Chuck -----Original Message----- From: Keith Medcalf [mailto:kmedcalf at dessus.com] Sent: Thursday, September 26, 2013 7:23 AM To: nanog at nanog.org Subject: RE: Sudan disconnected from the Internet Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Wednesday, 25 September, 2013 18:43 > To: Tammy Firefly > Cc: nanog at nanog.org > Subject: Re: Sudan disconnected from the Internet > > We make Ku-band backpacks for this type of scenario. I would give it > 12- > 18 > hours before you see CNN light up with live feeds.. I didn't even KNOW > this was happening prior to them doing this. Seems like cutting off > access would alert a lot more folks than some people wrecking Sudan > over fuel subsidies?? > > Doesn't look like it's been picked up by CNN substantially yet, but I > imagine we'll get "breaking news" soon enough. Would be interesting to > see if it was a forced drop or did they actually just take a pair of > scissors and murder the internets? > > On 9/25/13 5:40 PM, "Tammy Firefly" wrote: > > >On 9/25/13 18:38:09, Warren Bailey wrote: > >> > >>http://abcnews.go.com/International/wireStory/sudan-security-clashes > >>- > subs > >>id > >> y-protesters-20360418 > >> > >> On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > >> > >>> On 9/25/13 18:29:58, Jeff Kell wrote: > >>>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >>>>> with the old fashioned pair of diagonal cutters applied to fiber? > >>>> > >>>> Yes, interesting to know if it was cut fiber, pressure on the > inside > >>>> providers (or their feeds), or pressure on the outside providers. > >>>> > >>>> Traceroutes lend any clue? > >>>> > >>>> Jeff > >>>> > >>> > >>> If the government did it, I guarantee it was cut fiber. That > >>> makes > it > >>> difficult to quickly restore. One has to wonder whats going on > there > >>> right now that they dont want the world to know about? > >>> > >>> > >>> > >> > > > >Then its quite likely the government cut the fiber to cover that up > >:) wouldnt surprise me if they cut it in multiple places as well. > > > From randy at psg.com Thu Sep 26 17:43:02 2013 From: randy at psg.com (Randy Bush) Date: Thu, 26 Sep 2013 07:43:02 -1000 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: y'know, it's funny. there is a market in ipv4 space. there is no market in routing table slots. perhaps this is not conspiracy but rather the market is speaking. of course, we can use the idea of a market in routing table slots, rack space, or coffee to distract from the artificial problems in the only actual market, ipv4 address space. randy From cra at WPI.EDU Thu Sep 26 17:52:57 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 26 Sep 2013 13:52:57 -0400 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: <20130926175257.GB10467@angus.ind.WPI.EDU> On Thu, Sep 26, 2013 at 02:23:37AM +0000, Blake Pfankuch - Mailing List wrote: > I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. > > I don't need something super fancy, just need something that gives a good, bad or "holy crap is that concrete you are testing on" for starters. I am also shooting for about $150-250 tops. > > Any suggestions? How about using the built-in Digital Optcis Monitoring (DOM/DDM) in modern SFPs? Assuming your switches/routers and SFPs support it, you can read the received power level right from your switches/routers. The cost might be zero if you already have capabile equipment... Combine that with a flashlight for identifying strands, and it might be all you need... From wbailey at satelliteintelligencegroup.com Thu Sep 26 17:57:29 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 26 Sep 2013 17:57:29 +0000 Subject: Sudan disconnected from the Internet In-Reply-To: <00b601cebadf$50b86c20$f2294460$@gmail.com> References: <000352419979f04d8c2fc9aec9fe43dc@mail.dessus.com>, <00b601cebadf$50b86c20$f2294460$@gmail.com> Message-ID: We learned last week that iPhone updates cripple no network as they are regional and magical, simultaneously. ;) Sent from my Mobile Device. -------- Original message -------- From: Chuck Church Date: 09/26/2013 10:44 AM (GMT-08:00) To: nanog at nanog.org Subject: RE: Sudan disconnected from the Internet Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade. Chuck -----Original Message----- From: Keith Medcalf [mailto:kmedcalf at dessus.com] Sent: Thursday, September 26, 2013 7:23 AM To: nanog at nanog.org Subject: RE: Sudan disconnected from the Internet Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Wednesday, 25 September, 2013 18:43 > To: Tammy Firefly > Cc: nanog at nanog.org > Subject: Re: Sudan disconnected from the Internet > > We make Ku-band backpacks for this type of scenario. I would give it > 12- > 18 > hours before you see CNN light up with live feeds.. I didn't even KNOW > this was happening prior to them doing this. Seems like cutting off > access would alert a lot more folks than some people wrecking Sudan > over fuel subsidies?? > > Doesn't look like it's been picked up by CNN substantially yet, but I > imagine we'll get "breaking news" soon enough. Would be interesting to > see if it was a forced drop or did they actually just take a pair of > scissors and murder the internets? > > On 9/25/13 5:40 PM, "Tammy Firefly" wrote: > > >On 9/25/13 18:38:09, Warren Bailey wrote: > >> > >>http://abcnews.go.com/International/wireStory/sudan-security-clashes > >>- > subs > >>id > >> y-protesters-20360418 > >> > >> On 9/25/13 5:34 PM, "Tammy Firefly" wrote: > >> > >>> On 9/25/13 18:29:58, Jeff Kell wrote: > >>>> On 9/25/2013 8:25 PM, Tammy Firefly wrote: > >>>>> with the old fashioned pair of diagonal cutters applied to fiber? > >>>> > >>>> Yes, interesting to know if it was cut fiber, pressure on the > inside > >>>> providers (or their feeds), or pressure on the outside providers. > >>>> > >>>> Traceroutes lend any clue? > >>>> > >>>> Jeff > >>>> > >>> > >>> If the government did it, I guarantee it was cut fiber. That > >>> makes > it > >>> difficult to quickly restore. One has to wonder whats going on > there > >>> right now that they dont want the world to know about? > >>> > >>> > >>> > >> > > > >Then its quite likely the government cut the fiber to cover that up > >:) wouldnt surprise me if they cut it in multiple places as well. > > > From smeuse at mara.org Thu Sep 26 18:55:25 2013 From: smeuse at mara.org (Steve Meuse) Date: Thu, 26 Sep 2013 14:55:25 -0400 Subject: Sudan disconnected from the Internet In-Reply-To: <00b601cebadf$50b86c20$f2294460$@gmail.com> References: <000352419979f04d8c2fc9aec9fe43dc@mail.dessus.com> <00b601cebadf$50b86c20$f2294460$@gmail.com> Message-ID: On Thu, Sep 26, 2013 at 1:39 PM, Chuck Church wrote: > Or the country as a whole had WAY too many iPhones in need of a 7.0 > upgrade. > > Chuck Man, they should really install some Akamai servers! -Steve From nanog at bitfreak.org Thu Sep 26 19:29:17 2013 From: nanog at bitfreak.org (Darren Pilgrim) Date: Thu, 26 Sep 2013 12:29:17 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <20130926085250.GA8058@vacation.karoshi.com.> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> Message-ID: <52448B0D.8030505@bitfreak.org> On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: > sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies. From pfunix at gmail.com Thu Sep 26 19:57:42 2013 From: pfunix at gmail.com (Beavis) Date: Thu, 26 Sep 2013 13:57:42 -0600 Subject: Radware vs Arbor In-Reply-To: References: Message-ID: For a DDoS solution; my experience leans on arbor's peakflow and their partnership with other upstream carrier's (Level3, Peer1, etc.) which makes sense since most of the attacks are distributed having recon work done by an organization like arbor makes you only worry about the attack types that come into your network and not much the top part complexities of it. I am in no relationship with arbor or any of it's employees. this is solely based on my knowledge of the product. regards, -Beavis On Thu, Sep 26, 2013 at 10:47 AM, Tempest wrote: > Doing a bunch of research, and I can't find a meaningful comparison of > these two products. Work for a carrier, and I am looking at implementing a > DDoS mitigation service that we can sell to our customers. Radware is > cheaper, but I am seeing a lot of noise in various forums that makes me > question their viability for what we need. Arbor has most of the market, > and I assume there is good reason for it. Both companies seem to be very > deceptive about how they compare to the other. Anyone out there with good > hands on experience that can compare? Not interested in input from either > company, we get plenty of that already. Good experience, or links to good > write ups would be excellent... > > Davis B. > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From joelja at bogus.com Thu Sep 26 20:07:33 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 26 Sep 2013 13:07:33 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <52448B0D.8030505@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> Message-ID: <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim wrote: > On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: >> sounds just like folks in 1985, talking about IPv4... > > The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 > IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them? allocating enough /48s as part of direct assignments is probably not one of them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nanog at bitfreak.org Thu Sep 26 20:18:50 2013 From: nanog at bitfreak.org (Darren Pilgrim) Date: Thu, 26 Sep 2013 13:18:50 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> Message-ID: <524496AA.5070705@bitfreak.org> On 9/26/2013 1:07 PM, joel jaeggli wrote: > > On Sep 26, 2013, at 12:29 PM, Darren Pilgrim > wrote: > >> On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: >>> sounds just like folks in 1985, talking about IPv4... >> >> The foundation of that, though, was ignorance of address space >> exhaustion. IPv4's address space was too small for such large >> thinking. > > The first dicussion I could find about ipv4 runnout in email > archives is circa 1983 > >> IPv6 is far beyond enough to use such allocation policies. > > There are certain tendencies towards profligacy that might > prematurely influence the question of ipv6 exhaustion and we should > be on guard against them? allocating enough /48s as part of direct > assignments is probably not one of them. That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. We have this idea of the "/64 boundary". All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6. From bill at herrin.us Thu Sep 26 20:34:20 2013 From: bill at herrin.us (William Herrin) Date: Thu, 26 Sep 2013 16:34:20 -0400 Subject: minimum IPv6 announcement size In-Reply-To: <524496AA.5070705@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> Message-ID: On Thu, Sep 26, 2013 at 4:18 PM, Darren Pilgrim wrote: > That's just it, I really don't think we actually have an exhaustion risk > with IPv6. IPv6 is massive beyond massive. Hi Darren, At one point, I saw a proposal to allocate IPv6 /15's to ISPs. One /16 so they could overlay 32 bits of IPv4 using 6rd and deliver a /48 per ipv4 address and the other /16 for their native IPv6 operation, packaged as a /15 so they wouldn't need multiple routes. Yeah. So if we let ourselves assign addresses carelessly we could run out in the first half of this century. And while the plan above didn't fly, IPv6 /19's and /22's have been allocated already. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dennis at justipit.com Thu Sep 26 20:34:44 2013 From: dennis at justipit.com (dennis) Date: Thu, 26 Sep 2013 16:34:44 -0400 Subject: Radware vs Arbor In-Reply-To: References: Message-ID: <502D33E2BFC24F139D9B7668FE8DBA9D@usa.corp.radware.com> Surely both vendors have gear in many of the Tier1 carriers whether it be for layered security or dual vendor approach. When it comes down to deciding between the two you need to consider the deployment models and techniques in use. These two vendors strong points are in two separate areas. Arbor Peakflow is a very good traffic analysis tool which leverages netflow from your existing routers for probes providing good l3-l4 volumetric flood detection. Once a pps/bw anomaly is detected you can decide whether to reroute traffic into a scrubbing device (TMS/Radware, etc). Arbor common deployment is OOP netflow collection with redirection to scrubbing center. On the other hand Radware is a full packet inspection and mitigation (Layers 3-7) appliance. Radware is a transparent device with it's most common deployments inline, scrubbing center and out of path TAP modes. -------------------------------------------------- From: "Beavis" Sent: Thursday, September 26, 2013 3:57 PM To: "Tempest" Cc: Subject: Re: Radware vs Arbor > For a DDoS solution; my experience leans on arbor's peakflow and their > partnership with other upstream carrier's (Level3, Peer1, etc.) which > makes > sense since most of the attacks are distributed having recon work done by > an organization like arbor makes you only worry about the attack types > that > come into your network and not much the top part complexities of it. > > I am in no relationship with arbor or any of it's employees. this is > solely > based on my knowledge of the product. > > > regards, > -Beavis > > > On Thu, Sep 26, 2013 at 10:47 AM, Tempest wrote: > >> Doing a bunch of research, and I can't find a meaningful comparison of >> these two products. Work for a carrier, and I am looking at implementing >> a >> DDoS mitigation service that we can sell to our customers. Radware is >> cheaper, but I am seeing a lot of noise in various forums that makes me >> question their viability for what we need. Arbor has most of the market, >> and I assume there is good reason for it. Both companies seem to be very >> deceptive about how they compare to the other. Anyone out there with >> good >> hands on experience that can compare? Not interested in input from >> either >> company, we get plenty of that already. Good experience, or links to >> good >> write ups would be excellent... >> >> Davis B. >> > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Disclaimer: > http://goldmark.org/jeff/stupid-disclaimers/ > From joelja at bogus.com Thu Sep 26 20:36:07 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 26 Sep 2013 13:36:07 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <524496AA.5070705@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> Message-ID: On Sep 26, 2013, at 1:18 PM, Darren Pilgrim wrote: > On 9/26/2013 1:07 PM, joel jaeggli wrote: >> >> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim >> wrote: >> >>> On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: >>>> sounds just like folks in 1985, talking about IPv4... >>> >>> The foundation of that, though, was ignorance of address space >>> exhaustion. IPv4's address space was too small for such large >>> thinking. >> >> The first dicussion I could find about ipv4 runnout in email >> archives is circa 1983 >> >>> IPv6 is far beyond enough to use such allocation policies. >> >> There are certain tendencies towards profligacy that might >> prematurely influence the question of ipv6 exhaustion and we should >> be on guard against them? allocating enough /48s as part of direct >> assignments is probably not one of them. > > That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. > Instead of explaining to me how awesomely big ipv6 is you might figure out who you're talking to, or maybe consider the problem a bit more. Semantic addressing schemes can soak up as many bits as you're willing to give them. ISP(s) using (for example) 6rd or other automatic prefix mapping mechanisms can potentially use rather large prefixes. 128 bits is not so many that we can't trivially soak them all up and we should not pretend otherwise. We are stewards of the resource and we should manage it with care that reflect's long term thinking, both so that allocations we make now are not inappropriately small in the future and such that we are not again confronting the shortcomings of our decision-making again in 20 years. > We have this idea of the "/64 boundary". All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. > > Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. > > If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. > > That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: > > - 1% utilisation would fit all those /48's into a /62. > - A full /64 of those /48's would be 0.2% utilisation. > - 0.1%? We'd have to steal a bit and hand out /47's instead. > - /47 is ugly. At /52, we'd get .024% (one per 4096). > > That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. > > Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Thu Sep 26 20:41:25 2013 From: randy at psg.com (Randy Bush) Date: Thu, 26 Sep 2013 10:41:25 -1000 Subject: minimum IPv6 announcement size In-Reply-To: <52448B0D.8030505@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> Message-ID: >> sounds just like folks in 1985, talking about IPv4... > The foundation of that, though, was ignorance of address space > exhaustion. no. ipv4 was the second time, not the first randy From scott.brim at gmail.com Thu Sep 26 21:05:02 2013 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 26 Sep 2013 17:05:02 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: Oh this sure will be fun. For a good time, see how GSMA handles connectivity with IPXs. On Sep 26, 2013 1:28 PM, "William Herrin" wrote: > On Thu, Sep 26, 2013 at 11:07 AM, John Curran wrote: > > On Sep 26, 2013, at 4:52 AM, bmanning at vacation.karoshi.com wrote: > > > >> sounds just like folks in 1985, talking about IPv4... > > > > If there were ever were a need for an market/settlement model, it is > with respect > > to routing table slots. > > That's not to say that establishing a framework for externalizing > routing costs would > > be easy; it's a complicated and twisted matter, and also fraught with > various legal & > > competitive aspects. > > Hi John, > > That's putting it mildly. Establishing such a framework would be an > immense challenge. Here are some ideas I've heard: > > > 1. The International Clearinghouse > > Every BGP participant files with a clearinghouse, specifying: > > a. How much they charge to carry 1 route > b. Whether or not they are a leaf node > c. Whether or not they are a transit-free network. > > Any network which is not transit free must implement a default route > which leads to a big transit-free network in order to maintain full > connectivity. > > The BGP participants then publish the exact routes they intend to > announce to the clearinghouse and for each one select which networks > they'll pay to carry the route. The route must still reach each > network via BGP; payment just means that the network won't filter the > route out. > > The clearinghouse then collects payments from everybody and makes > payments to everybody, as well as providing each participant a list of > the routes that are paid for. Sellers are expected to promptly > incorporate new paid routes into their BGP filters. > > From my research a few years ago, a reasonable rate would be around 3 > to 4 cents per year per advertised route per BGP-carrying router in > the organization. A couple billion dollars per year if the routing > table maintained its current size. > > > 2. The partial routing scenario > > Large service providers put bids in to the RIRs for the right to > announce /8 covering routes for each /8 delegated to the RIR. Each /8 > matches exactly one service provider. Smaller BGP system participants > make private arrangements with a small (20 to 30) set of networks > (including their direct ISPs) to carry their advertised routes through > a reasonably redundant number of pathways to (and including) the > winning bidder for the /8 they inhabit. For the sake of performance, > they may also pay additional large networks to shortcut the traffic > towards them rather than let it dump at the /8 advertiser. > > For the folks you don't pay via the clearinghouse, many end-user > systems and the majority of transit systems simply don't carry your > route unless yours is among the handful of systems critically > important to their customers. Instead, traffic to your network follows > the /8 advertisement until it reaches a network which carries your > specific route. > > With the routing costs suitably reduced, settlement for the remaining > routes becomes moot. > > This is usually within a few percent of the routing efficiency that > would have been achieved with total route propagation. > > > 3. The routing overlay > > Establish a semi-stateless tunneling system. Each BGP participant sets > up a tunnel ingress node and links a default route to it. Packets for > a destination not found in the routing table follow the default route > to the tunnel ingress. > > The tunnel device then looks up an tunnel exit node via a mapping > protocol. Both the map server and the exit node have to be hosted on > IP addresses reachable via the normal routing table. > > Having found an exit node, the original packet is encapsulated into a > tunnel packet and sent to the exit node. The exit node is in a part of > the network that carries an explicit route to the destination. > > Then, move the definition of threshold size. Except for whitelisted > critical infrastructure, /24 advertisements would no longer carry an > expectation of universal distribution. To maintain connectivity, folks > at the bottom of the chain would need to establish or subscribe to > tunnel exit nodes that have a route back to them. > > With the routing costs suitably reduced, settlement for the remaining > routes becomes moot. > > The IRTF Routing Research Group studied such protocols a few years ago > and have pretty well fleshed out how to make one work with all the > tangled issues involving path mtu, dead path detection and so on. > Multiple designs sit on a shelf waiting for a promise that the > technology will be purchased if built. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From carlos at race.com Thu Sep 26 21:20:19 2013 From: carlos at race.com (Carlos Alcantar) Date: Thu, 26 Sep 2013 21:20:19 +0000 Subject: Suggestion on Fiber tester In-Reply-To: <20130926175257.GB10467@angus.ind.WPI.EDU> Message-ID: I would also suggest you use a ferrule cleaner every single time you touch an end http://www.fiberoptics4sale.com/p/Fiber_Optic_Connector_Reel_Cleaners/SFM25 0.html Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Chuck Anderson Date: Thursday, September 26, 2013 10:52 AM To: "nanog at nanog.org" Subject: Re: Suggestion on Fiber tester On Thu, Sep 26, 2013 at 02:23:37AM +0000, Blake Pfankuch - Mailing List wrote: > I am in the market for a simple fiber tester. I have about 80 pairs >running through my complex and we are running into some possible issues >with some of the really old ones. The pen light to confirm that it's the >right strand is going to require a little bit more insight to determine >if there is an issue with fiber in conduit or patch. > > I don't need something super fancy, just need something that gives a >good, bad or "holy crap is that concrete you are testing on" for >starters. I am also shooting for about $150-250 tops. > > Any suggestions? How about using the built-in Digital Optcis Monitoring (DOM/DDM) in modern SFPs? Assuming your switches/routers and SFPs support it, you can read the received power level right from your switches/routers. The cost might be zero if you already have capabile equipment... Combine that with a flashlight for identifying strands, and it might be all you need... From marklanc at gmail.com Thu Sep 26 21:22:22 2013 From: marklanc at gmail.com (Mark Lancaster) Date: Thu, 26 Sep 2013 14:22:22 -0700 Subject: iOS 7 update traffic Message-ID: I have heard a lot of questions and debate about whether the iOS updates download automatically: ?Available updates download automatically if your device is connected to Wi-Fi and a power source.? http://support.apple.com/kb/HT4623 /mark From saku at ytti.fi Thu Sep 26 21:28:51 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 27 Sep 2013 00:28:51 +0300 Subject: BGP Attribute 128 In-Reply-To: <9F01FD08-ECF7-4660-ADB9-6EB899F90198@puck.nether.net> References: <9F01FD08-ECF7-4660-ADB9-6EB899F90198@puck.nether.net> Message-ID: <20130926212851.GA15290@pob.ytti.fi> On (2013-09-25 11:35 -0400), Jared Mauch wrote: Hi, > I'm not really in favor of the features vendors have provided, such as this to just drop the attribute or routes. I would encourage customers to require in their transit agreements that bgp updates are not mangled by provider. It would help internally if you have customer backing. I think it's overraction to kill useful features because sometime on some platform there has been NLRI parsing bug which caused issues. Once those filters are deployed there will be strong resistance to remove them. -- ++ytti From james.cutler at consultant.com Thu Sep 26 21:31:51 2013 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 26 Sep 2013 17:31:51 -0400 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: On Sep 26, 2013, at 5:22 PM, Mark Lancaster wrote: > I have heard a lot of questions and debate about whether the iOS updates > download automatically: > > ?Available updates download automatically if your device is connected to > Wi-Fi and a power source.? > > http://support.apple.com/kb/HT4623 > > /mark > The wording in step 2 is poorly done. The availability of updates is what is downloaded. Step 3 indicates an active user input to begin download is required. From jared at puck.nether.net Thu Sep 26 22:02:33 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 26 Sep 2013 17:02:33 -0500 Subject: BGP Attribute 128 In-Reply-To: <20130926212851.GA15290@pob.ytti.fi> References: <9F01FD08-ECF7-4660-ADB9-6EB899F90198@puck.nether.net> <20130926212851.GA15290@pob.ytti.fi> Message-ID: <5009F30A-BB9F-44FB-A21A-23AA5E93CCB7@puck.nether.net> I certainly agree. There is a very narrow case for filtering 128 as it's a VPN attribute that should not be in the big-I Internet. Jared Mauch > On Sep 26, 2013, at 4:28 PM, Saku Ytti wrote: > > Once those filters are deployed there will be strong resistance to remove > them. From geoffk at geoffk.org Thu Sep 26 22:32:21 2013 From: geoffk at geoffk.org (Geoffrey Keating) Date: 26 Sep 2013 15:32:21 -0700 Subject: iOS 7 update traffic In-Reply-To: References: Message-ID: Cutler James R writes: > On Sep 26, 2013, at 5:22 PM, Mark Lancaster wrote: > > > I have heard a lot of questions and debate about whether the iOS updates > > download automatically: > > > > ?Available updates download automatically if your device is connected to > > Wi-Fi and a power source.? > > > > http://support.apple.com/kb/HT4623 > > > > /mark > > > > The wording in step 2 is poorly done. The availability of updates is what is downloaded. > > Step 3 indicates an active user input to begin download is required. The updates do download automatically, but only if the device is on wifi and power at the same time. For iOS 6, a check for available updates will be attempted at a randomly chosen time on a randomly chosen day of the week. If one is found, an automatic download may follow if/when on power and wifi. Opening the Software Update pane will cause an immediate check for available updates. If one is found it will be displayed to the user, who may touch the button, which will complete the download (even if not on power or not on wifi, although there are minimum battery charge requirements and some updates can't be downloaded over cell) as necessary, and then perform the install. So, an ISP will see initial traffic when an update is released, as people manually install it, and some continuing traffic spread over at least the next week as the automatic downloads occur. Then, of course, once people have updated their device, they'll want to use it: update their apps, download a new Siri voice, buy music... From bmanning at vacation.karoshi.com Fri Sep 27 04:50:02 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 27 Sep 2013 04:50:02 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <52448B0D.8030505@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> Message-ID: <20130927045002.GA11933@vacation.karoshi.com.> On Thu, Sep 26, 2013 at 12:29:17PM -0700, Darren Pilgrim wrote: > On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: > > sounds just like folks in 1985, talking about IPv4... > > The foundation of that, though, was ignorance of address space > exhaustion. IPv4's address space was too small for such large thinking. > IPv6 is far beyond enough to use such allocation policies. when concevied, IPv4 was unimaginably large ... /8's were handed out to networks with fewer than 10 devices. Hindsight is 20/20. "those who ignore teh past are doomed to repeat it" /bill From bmanning at vacation.karoshi.com Fri Sep 27 04:57:18 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 27 Sep 2013 04:57:18 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <524496AA.5070705@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> Message-ID: <20130927045718.GB11933@vacation.karoshi.com.> Yup. Seen/Heard all that. Even tooted that horn for a while. /64 is an artifical boundary - many/most IANA/RIR delegations are in the top /32 which is functionally the same as handing out traditional /16s. Some RIR client are "bigger" and demand more, so they get the v6 equvalent of /14s or smaller. Its the _exact_ same model as v4 in the previous decade. With the entire waste in the bottom /64. Its tilting at windmills, but most of the community has "drunk the koolaide" on wasteful /v6 assignment. What a horrific legacy to hand to our children (and yes, it will hit that soon) /bill On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote: > On 9/26/2013 1:07 PM, joel jaeggli wrote: > > > >On Sep 26, 2013, at 12:29 PM, Darren Pilgrim > >wrote: > > > >>On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: > >>>sounds just like folks in 1985, talking about IPv4... > >> > >>The foundation of that, though, was ignorance of address space > >>exhaustion. IPv4's address space was too small for such large > >>thinking. > > > >The first dicussion I could find about ipv4 runnout in email > >archives is circa 1983 > > > >>IPv6 is far beyond enough to use such allocation policies. > > > >There are certain tendencies towards profligacy that might > >prematurely influence the question of ipv6 exhaustion and we should > >be on guard against them allocating enough /48s as part of direct > >assignments is probably not one of them. > > That's just it, I really don't think we actually have an exhaustion risk > with IPv6. IPv6 is massive beyond massive. Let me explain. > > We have this idea of the "/64 boundary". All those nifty automatic > addressing things rely on it. We now have two generations of hardware > and software that would more or less break if we did away with it. In > essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but > still quite large. > > Current science says Earth can support ten billion humans. If we let > the humans proliferate to three times the theoretical upper limit for > Earth's population, a /64 for each human would be at about a /35's worth > of /64's. If we're generous with Earth's carrying capacity, a /36. > > If we handed out /48's instead so each human could give a /64 to each of > their devices, it would all fit in a single /52. Those /48's would > number existance at a rate of one /64 per human, one /64 per device, and > a 65535:1 device:human ratio. That means we could allocate 4000::/3 > just for Earth humans and devices and never need another block for that > purpose. > > That's assuming a very high utilisation ratio, of course, but really no > worse than IPv4 is currently. The problem isn't allocation density, but > router hardware. We need room for route aggregation and other means of > compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% > utilisation, keeping the allocations to just 4000::/3, we'd need less > than a single /60 for all those /48's. If 10% isn't enough, we can go > quite a bit farther: > > - 1% utilisation would fit all those /48's into a /62. > - A full /64 of those /48's would be 0.2% utilisation. > - 0.1%? We'd have to steal a bit and hand out /47's instead. > - /47 is ugly. At /52, we'd get .024% (one per 4096). > > That's while maintaining a practice of one /64 per human or device with > 65535 devices per human. Introduce one /64 per subnet and sub-ppm > utilisation is possible. That would be giving a site a /44 and them > only ever using the ::/64 of it. > > Even with sloppy, sparse allocation policies and allowing limitless > human and device population growth, we very likely can not exhaust IPv6. From saku at ytti.fi Fri Sep 27 06:39:15 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 27 Sep 2013 09:39:15 +0300 Subject: BGP Attribute 128 In-Reply-To: <5009F30A-BB9F-44FB-A21A-23AA5E93CCB7@puck.nether.net> References: <9F01FD08-ECF7-4660-ADB9-6EB899F90198@puck.nether.net> <20130926212851.GA15290@pob.ytti.fi> <5009F30A-BB9F-44FB-A21A-23AA5E93CCB7@puck.nether.net> Message-ID: <20130927063915.GA18526@pob.ytti.fi> On (2013-09-26 17:02 -0500), Jared Mauch wrote: > I certainly agree. There is a very narrow case for filtering 128 as it's a VPN attribute that should not be in the big-I Internet. I can't think of application right now, but I'm not convinced there isn't application for 128 over INET. I know RFC strictly speaks about VPN deployment, but I wouldn't be too surprised if someone would have good use-case for tunneling attributes over INET. -- ++ytti From darrenoc at outlook.com Fri Sep 27 07:49:01 2013 From: darrenoc at outlook.com (Darren O'Connor) Date: Fri, 27 Sep 2013 08:49:01 +0100 Subject: iOS 7 update traffic In-Reply-To: <524216D7.7020504@list-subs.com> References: <6723488B-AB53-47E6-B11E-DE7F1C7628E0@puck.nether.net> <2002623.8491.1380034161284.JavaMail.root@benjamin.baylink.com> <5241CD8B.5070500@list-subs.com> <20130924175425.5718165.35281.8388@supermathie.net> <524216D7.7020504@list-subs.com> Message-ID: It's back with this: "Ben quite succinctly sums it up on a nanog mailing list, ?Your (the service provider) user is paying you to push packets. If that?s causing you a problem, you either need to review your commercial structure (i.e. charge people more) or your technical network design. Face the facts, what with everyone jumping on the ?cloud? bandwagon, the future is only going to see you pushing more packets, not less ! So if you can?t stand the heat, get out of the kitchen (or the xSP industry).? Thanks Darren http://www.mellowd.co.uk/ccie > On 24 Sep 2013, at 23:51, "Ben" wrote: > >> On 24/09/2013 18:54, Michael Brown wrote: >> That is most assuredly a rewrite, it's not just your perception. >> >> M. > > Surprise surprise, that page now appears to Error 404... guess he must watch the list quite closely as it didn't take long for him to react ! ;-) > > Guess I should be flattered someone finds my internet rantings quoteworthy ! Would have appreciated at least a feable attempt at a citation (or at least a generic reference to the Nanog list in general). > > > > From rmcintosh at nitemare.net Fri Sep 27 06:10:47 2013 From: rmcintosh at nitemare.net (Ryan McIntosh) Date: Fri, 27 Sep 2013 02:10:47 -0400 Subject: minimum IPv6 announcement size In-Reply-To: <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: I don't respond to many of these threads but I have to say I've contested this one too only to have to beaten into my head that a /64 is "appropriate".. it still hasn't stuck, but unfortunately rfc's for other protocols depend on the blocks to now be a /64.. It's a waste, even if we're "planning for the future", no one house needs a /64 sitting on their lan.. or at least none I can sensibly think of o_O. Ryan On Fri, Sep 27, 2013 at 12:57 AM, wrote: > Yup. Seen/Heard all that. Even tooted that horn for a while. > /64 is an artifical boundary - many/most IANA/RIR delegations are in the top /32 > which is functionally the same as handing out traditional /16s. Some RIR client > are "bigger" and demand more, so they get the v6 equvalent of /14s or smaller. > Its the _exact_ same model as v4 in the previous decade. With the entire waste > in the bottom /64. > > Its tilting at windmills, but most of the community has "drunk the koolaide" > on wasteful /v6 assignment. What a horrific legacy to hand to our children > (and yes, it will hit that soon) > > /bill > > > On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote: >> On 9/26/2013 1:07 PM, joel jaeggli wrote: >> > >> >On Sep 26, 2013, at 12:29 PM, Darren Pilgrim >> >wrote: >> > >> >>On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: >> >>>sounds just like folks in 1985, talking about IPv4... >> >> >> >>The foundation of that, though, was ignorance of address space >> >>exhaustion. IPv4's address space was too small for such large >> >>thinking. >> > >> >The first dicussion I could find about ipv4 runnout in email >> >archives is circa 1983 >> > >> >>IPv6 is far beyond enough to use such allocation policies. >> > >> >There are certain tendencies towards profligacy that might >> >prematurely influence the question of ipv6 exhaustion and we should >> >be on guard against them allocating enough /48s as part of direct >> >assignments is probably not one of them. >> >> That's just it, I really don't think we actually have an exhaustion risk >> with IPv6. IPv6 is massive beyond massive. Let me explain. >> >> We have this idea of the "/64 boundary". All those nifty automatic >> addressing things rely on it. We now have two generations of hardware >> and software that would more or less break if we did away with it. In >> essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but >> still quite large. >> >> Current science says Earth can support ten billion humans. If we let >> the humans proliferate to three times the theoretical upper limit for >> Earth's population, a /64 for each human would be at about a /35's worth >> of /64's. If we're generous with Earth's carrying capacity, a /36. >> >> If we handed out /48's instead so each human could give a /64 to each of >> their devices, it would all fit in a single /52. Those /48's would >> number existance at a rate of one /64 per human, one /64 per device, and >> a 65535:1 device:human ratio. That means we could allocate 4000::/3 >> just for Earth humans and devices and never need another block for that >> purpose. >> >> That's assuming a very high utilisation ratio, of course, but really no >> worse than IPv4 is currently. The problem isn't allocation density, but >> router hardware. We need room for route aggregation and other means of >> compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% >> utilisation, keeping the allocations to just 4000::/3, we'd need less >> than a single /60 for all those /48's. If 10% isn't enough, we can go >> quite a bit farther: >> >> - 1% utilisation would fit all those /48's into a /62. >> - A full /64 of those /48's would be 0.2% utilisation. >> - 0.1%? We'd have to steal a bit and hand out /47's instead. >> - /47 is ugly. At /52, we'd get .024% (one per 4096). >> >> That's while maintaining a practice of one /64 per human or device with >> 65535 devices per human. Introduce one /64 per subnet and sub-ppm >> utilisation is possible. That would be giving a site a /44 and them >> only ever using the ::/64 of it. >> >> Even with sloppy, sparse allocation policies and allowing limitless >> human and device population growth, we very likely can not exhaust IPv6. > From fdelmotte1 at mac.com Fri Sep 27 09:05:36 2013 From: fdelmotte1 at mac.com (Fabien Delmotte) Date: Fri, 27 Sep 2013 11:05:36 +0200 Subject: Radware vs Arbor In-Reply-To: References: Message-ID: <6DE5C148-F65B-4894-A13E-80E13A93AFA3@mac.com> Hi, Maybe you can see what A10 Networks is doing. They build a new product dedicated to DDOS. Regards Fabien Le 26 sept. 2013 ? 18:47, Tempest a ?crit : > Doing a bunch of research, and I can't find a meaningful comparison of > these two products. Work for a carrier, and I am looking at implementing a > DDoS mitigation service that we can sell to our customers. Radware is > cheaper, but I am seeing a lot of noise in various forums that makes me > question their viability for what we need. Arbor has most of the market, > and I assume there is good reason for it. Both companies seem to be very > deceptive about how they compare to the other. Anyone out there with good > hands on experience that can compare? Not interested in input from either > company, we get plenty of that already. Good experience, or links to good > write ups would be excellent... > > Davis B. From angst1974 at yahoo.com Fri Sep 27 13:08:22 2013 From: angst1974 at yahoo.com (Steve) Date: Fri, 27 Sep 2013 06:08:22 -0700 (PDT) Subject: Radware vs Arbor In-Reply-To: References: Message-ID: <1380287302.13197.YahooMailNeo@web122505.mail.ne1.yahoo.com> A10 is in pretty early stages right now on DDoS , this may be a good thing if you have time to wait and can help mold them a bit. They are still mostly enterprise focused , not really carrier grade . Radware is a little further along, but Arbor is king when it comes suitability for a carrier deployment. ________________________________ ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Sep 2013 11:05:36 +0200 From: Fabien Delmotte To: Tempest Cc: nanog at nanog.org Subject: Re: Radware vs Arbor Message-ID: <6DE5C148-F65B-4894-A13E-80E13A93AFA3 at mac.com> Content-Type: text/plain; charset=iso-8859-1 Hi, Maybe you can see what A10 Networks is doing. They build a new product dedicated to DDOS. Regards Fabien Le 26 sept. 2013 ? 18:47, Tempest a ?crit : > Doing a bunch of research, and I can't find a meaningful comparison of > these two products.? Work for a carrier, and I am looking at implementing a > DDoS mitigation service that we can sell to our customers.? Radware is > cheaper, but I am seeing a lot of noise in various forums that makes me > question their viability for what we need.? Arbor has most of the market, > and I assume there is good reason for it.? Both companies seem to be very > deceptive about how they compare to the other.? Anyone out there with good > hands on experience that can compare?? Not interested in input from either > company, we get plenty of that already.? Good experience, or links to good > write ups would be excellent... > > Davis B. End of NANOG Digest, Vol 68, Issue 80 ************************************* From jcurran at istaff.org Fri Sep 27 13:36:49 2013 From: jcurran at istaff.org (John Curran) Date: Fri, 27 Sep 2013 09:36:49 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: On Sep 26, 2013, at 1:43 PM, Randy Bush wrote: > y'know, it's funny. there is a market in ipv4 space. there is no > market in routing table slots. perhaps this is not conspiracy but > rather the market is speaking. That easily could be the case. So how well is has the current model been working out for IPv4? It appears that only feedback mechanism is the "The Cidr Report" , and last time this topic came up was almost exactly two years ago back at 375000 routes... is this success? Perhaps more conference banners are needed? > of course, we can use the idea of a market in routing table slots, > rack space, or coffee to distract from the artificial problems in > the only actual market, ipv4 address space. No desire at all to distract from the discussions on that topic, and in fact, I'd encourage folks (including yourself) to pop on over to PPML and make suggestions for policy changes as desired. That's not an option available to me, and I was simply commenting on the fact that we're recreating the same IPv6 routing table feedback system which gave us our present "success" with the IPv4 routing table. FYI, /John From bill at herrin.us Fri Sep 27 13:43:55 2013 From: bill at herrin.us (William Herrin) Date: Fri, 27 Sep 2013 09:43:55 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: On Thu, Sep 26, 2013 at 5:05 PM, Scott Brim wrote: > Oh this sure will be fun. For a good time, see how GSMA handles connectivity > with IPXs. Hi Scott, For those of us who aren't deeply engrossed in GSM mobile telecom, would you offer a synopsis? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bross at pobox.com Fri Sep 27 14:40:15 2013 From: bross at pobox.com (Brandon Ross) Date: Fri, 27 Sep 2013 10:40:15 -0400 (EDT) Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Fri, 27 Sep 2013, Ryan McIntosh wrote: > It's a waste, even if we're "planning for the future", no one house > needs a /64 sitting on their lan.. or at least none I can sensibly > think of o_O. Okay, I'm just curious, what size do you (and other's of similar opinion) think the IPv6 space _should_ have been in order to allow us to not have to jump through conservation hoops ever again? 128 bits isn't enough, clearly, 256? 1k? 10k? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jabley at hopcount.ca Fri Sep 27 14:54:48 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 27 Sep 2013 10:54:48 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 2013-09-27, at 10:40, Brandon Ross wrote: > On Fri, 27 Sep 2013, Ryan McIntosh wrote: > >> It's a waste, even if we're "planning for the future", no one house >> needs a /64 sitting on their lan.. or at least none I can sensibly >> think of o_O. > > Okay, I'm just curious, what size do you (and other's of similar opinion) think the IPv6 space _should_ have been in order to allow us to not have to jump through conservation hoops ever again? 128 bits isn't enough, clearly, 256? 1k? 10k? Given the design decision to use the bottom 64 bits to identify an individual host on a broadcast domain, the increase in address size isn't really 32 bits to 128 bits -- if your average v4 subnet size for a vlan is a /27, say, then it's more like an increase of 27 bits to 64 bits from the point of view of global assignment. Alternatively, considering that it's normal to give a service provider at least a /32, whereas the equivalent assignment in v4 might have been something like a /19 (handwave, handwave), it's more like an increase of 13 bits to 32 bits. Alternatively, considering that it's considered reasonable in some quarters to give an end-user a /48 so that they can break out different subnets inside their network whereas with IPv4 you'd give a customer a single address and expect them to use NAT, then it's more like an increase of 31 bits to 48 bits. That's still a lower bound of 2^17 times as many available addresses, and having enough addresses to satisfy a network 131,072 times as big as the current v4 Internet does not seem like a horrible thing. But the oft-repeated mantra that "there are enough addresses to individually number every grain of sand on the world's beaches" doesn't describe reality very well. The IPv6 addressing plan didn't wind up meeting our requirements very well. Film at 11. Joe From bill at herrin.us Fri Sep 27 15:11:50 2013 From: bill at herrin.us (William Herrin) Date: Fri, 27 Sep 2013 11:11:50 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Fri, Sep 27, 2013 at 10:40 AM, Brandon Ross wrote: > Okay, I'm just curious, what size do you (and other's of similar opinion) > think the IPv6 space _should_ have been in order to allow us to not have to > jump through conservation hoops ever again? 128 bits isn't enough, clearly, > 256? 1k? 10k? Hi Brandon, There is no bit length which allocations of /20's and larger won't quickly exhaust. It's not about the number of bits, it's about how we choose to use them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rcarpen at network1.net Fri Sep 27 17:04:23 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 27 Sep 2013 13:04:23 -0400 (EDT) Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> > There is no bit length which allocations of /20's and larger won't > quickly exhaust. It's not about the number of bits, it's about how we > choose to use them. > > Regards, > Bill Herrin True, but how many orgs do we expect to fall into that category? If the majority are getting /32, and only a handful are getting /24 or larger, can we assume that the average is going to be ~/28 ? If that is so, then out of the current /3, we can support over 30,000,000 entities. Actually, I would think the average is much closer to /32, since there are several orders of magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out of the /3. So somewhere between 30 and 500 million orgs. How many ISPs do we expect to be able to support? Also, consider that there are 7 more /3s that could be allocated in the future. As has been said, routing slots in the DFZ get to be problematic much sooner than address runout. Most current routers support ~1 million IPv6 routes. I think it would be reasonable to assume that that number could grow by an order of magnitude or 2, but I don't thin we'll see a billion or more routes in the lifetime of IPv6. Therefore, I don't see any reason to artificially inflate the routing table by conserving, and then making orgs come back for additional allocations. -Randy From joelja at bogus.com Fri Sep 27 18:02:09 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 27 Sep 2013 11:02:09 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> References: <5241986D.60902@stluke.com.ph> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> Message-ID: <1820E607-474D-44BB-B7F2-6691315CFB7E@bogus.com> On Sep 27, 2013, at 10:04 AM, Randy Carpenter wrote: > >> There is no bit length which allocations of /20's and larger won't >> quickly exhaust. It's not about the number of bits, it's about how we >> choose to use them. >> >> Regards, >> Bill Herrin > > True, but how many orgs do we expect to fall into that category? If the majority are getting /32, and only a handful are getting /24 or larger, can we assume that the average is going to be ~/28 ? If that is so, then out of the current /3, we can support over 30,000,000 entities. Actually, I would think the average is much closer to /32, since there are several orders of magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out of the /3. So somewhere between 30 and 500 million orgs. > > How many ISPs do we expect to be able to support? Also, consider that there are 7 more /3s that could be allocated in the future. > > As has been said, routing slots in the DFZ get to be problematic much sooner than address runout. Most current routers support ~1 million IPv6 routes. I think it would be reasonable to assume that that number could grow by an order of magnitude or 2, but I don't thin we'll see a billion or more routes in the lifetime of IPv6. Therefore, I don't see any reason to artificially inflate the routing table by conserving, and then making orgs come back for additional allocations. In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that 18619 ~40% announce only one prefix. given the distribution of prefix counts across ASNs it's quite reasonable to conclude that the consumption of routing table slots is not primarly a property of the number of participants but rather in the hands of a smaller number of large participants many of whom are in this room. > -Randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Fri Sep 27 18:11:02 2013 From: bill at herrin.us (William Herrin) Date: Fri, 27 Sep 2013 14:11:02 -0400 Subject: minimum IPv6 announcement size In-Reply-To: <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> References: <5241986D.60902@stluke.com.ph> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> Message-ID: On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter wrote: > >> There is no bit length which allocations of /20's and larger won't >> quickly exhaust. It's not about the number of bits, it's about how we >> choose to use them. > > True, but how many orgs do we expect to fall into that category? If the majority are getting /32, and only a handful are getting /24 or larger, can we assume that the average is going to be ~/28 ? If that is so, then out of the current /3, we can support over 30,000,000 entities. Actually, I would think the average is much closer to /32, since there are several orders of magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out of the /3. So somewhere between 30 and 500 million orgs. > > How many ISPs do we expect to be able to support? Also, consider that there are 7 more /3s that could be allocated in the future. Hi Randy, If that's how we choose to use IPv6 then runout should be a long way away. That's a big "if". And choosing to stay that course is a form of conservation. > Therefore, I don't see any reason to artificially inflate > the routing table by conserving, and then making > orgs come back for additional allocations. I'm not convinced of that. Suppose the plan was: you start with a /56. When you need more you get a /48. Next is a /40. Next a /32. Next a /28. You can hold exactly one of each size, never more. And the RIRs tell us all which address banks each size comes from. In such a scenario, the RIR doesn't have to reserve a /28 for expansion every time the allocate a /32. 'Cause, you know, that's what they've been doing. And you can easily program your router to discard the TE routes you don't wish to carry since you know what the allocation size was. That means you only have to carry at most 5 routes for any given organization. You'd want to allow some TE for the sake of efficient routing, but you get to choose how much. As things stand now, you're going to allow those guys with the /19s and /22s to do traffic engineering all the way down to /48. You don't have a practical way to say "no." Food for thought. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Sep 27 18:36:05 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Sep 2013 04:36:05 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201309271836.r8RIa5Mj006131@thyme.rand.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, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. 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 . Routing Table Report 04:00 +10GMT Sat 28 Sep, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 468437 Prefixes after maximum aggregation: 188881 Deaggregation factor: 2.48 Unique aggregates announced to Internet: 232188 Total ASes present in the Internet Routing Table: 45071 Prefixes per ASN: 10.39 Origin-only ASes present in the Internet Routing Table: 35211 Origin ASes announcing only one prefix: 16272 Transit ASes present in the Internet Routing Table: 5902 Transit-only ASes present in the Internet Routing Table: 162 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 285 Unregistered ASNs in the Routing Table: 158 Number of 32-bit ASNs allocated by the RIRs: 5110 Number of 32-bit ASNs visible in the Routing Table: 3958 Prefixes from 32-bit ASNs in the Routing Table: 12108 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 596 Number of addresses announced to Internet: 2645071764 Equivalent to 157 /8s, 168 /16s and 151 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.0 Total number of prefixes smaller than registry allocations: 163911 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 111250 Total APNIC prefixes after maximum aggregation: 33714 APNIC Deaggregation factor: 3.30 Prefixes being announced from the APNIC address blocks: 113282 Unique aggregates announced from the APNIC address blocks: 46723 APNIC Region origin ASes present in the Internet Routing Table: 4869 APNIC Prefixes per ASN: 23.27 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 829 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 692 Number of APNIC addresses announced to Internet: 727695360 Equivalent to 43 /8s, 95 /16s and 192 /24s Percentage of available APNIC address space announced: 85.0 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-63999, 131072-133631 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: 162744 Total ARIN prefixes after maximum aggregation: 81490 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 163254 Unique aggregates announced from the ARIN address blocks: 75879 ARIN Region origin ASes present in the Internet Routing Table: 15900 ARIN Prefixes per ASN: 10.27 ARIN Region origin ASes announcing only one prefix: 6024 ARIN Region transit ASes present in the Internet Routing Table: 1653 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 21 Number of ARIN addresses announced to Internet: 1072661120 Equivalent to 63 /8s, 239 /16s and 130 /24s Percentage of available ARIN address space announced: 56.7 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, 393216-394239 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: 118632 Total RIPE prefixes after maximum aggregation: 61255 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 122199 Unique aggregates announced from the RIPE address blocks: 78897 RIPE Region origin ASes present in the Internet Routing Table: 17449 RIPE Prefixes per ASN: 7.00 RIPE Region origin ASes announcing only one prefix: 8272 RIPE Region transit ASes present in the Internet Routing Table: 2805 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2403 Number of RIPE addresses announced to Internet: 657039844 Equivalent to 39 /8s, 41 /16s and 161 /24s Percentage of available RIPE address space announced: 95.5 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-200191 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: 51895 Total LACNIC prefixes after maximum aggregation: 9803 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 56808 Unique aggregates announced from the LACNIC address blocks: 26194 LACNIC Region origin ASes present in the Internet Routing Table: 2025 LACNIC Prefixes per ASN: 28.05 LACNIC Region origin ASes announcing only one prefix: 569 LACNIC Region transit ASes present in the Internet Routing Table: 382 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 836 Number of LACNIC addresses announced to Internet: 139338288 Equivalent to 8 /8s, 78 /16s and 34 /24s Percentage of available LACNIC address space announced: 83.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11674 Total AfriNIC prefixes after maximum aggregation: 2544 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 12298 Unique aggregates announced from the AfriNIC address blocks: 3982 AfriNIC Region origin ASes present in the Internet Routing Table: 653 AfriNIC Prefixes per ASN: 18.83 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 138 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46748928 Equivalent to 2 /8s, 201 /16s and 85 /24s Percentage of available AfriNIC address space announced: 46.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 4766 2936 11562 937 Korea Telecom (KIX) 17974 2691 903 91 PT TELEKOMUNIKASI INDONESIA 7545 2079 321 112 TPG Internet Pty Ltd 4755 1770 391 187 TATA Communications formerly 9829 1545 1238 40 BSNL National Internet Backbo 9583 1233 93 506 Sify Limited 9498 1194 309 72 BHARTI Airtel Ltd. 4808 1192 2131 347 CNCGROUP IP network: China169 7552 1163 1080 13 Vietel Corporation 24560 1090 380 164 Bharti Airtel Ltd., Telemedia 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 6389 3061 3689 59 BellSouth.net Inc. 18566 2067 382 184 Covad Communications 22773 2038 2933 124 Cox Communications, Inc. 1785 2018 679 125 PaeTec Communications, Inc. 20115 1680 1651 628 Charter Communications 4323 1616 1103 417 Time Warner Telecom 701 1523 11149 795 UUNET Technologies, Inc. 30036 1345 304 623 Mediacom Communications Corp 7018 1305 11244 821 AT&T WorldNet Services 6983 1285 756 578 ITC^Deltacom 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 8402 1781 544 17 OJSC "Vimpelcom" 34984 1363 244 221 TELLCOM ILETISIM HIZMETLERI A 20940 1033 377 794 Akamai Technologies European 31148 989 43 19 FreeNet ISP 6830 891 2365 425 UPC Distribution Services 13188 849 99 67 TOV "Bank-Inform" 8551 746 370 41 Bezeq International 12479 676 799 49 Uni2 Autonomous System 35228 528 246 16 Avatar Broadband Limited 3320 511 8416 406 Deutsche Telekom AG 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 28573 3367 1730 94 NET Servicos de Comunicao S.A 10620 2584 421 246 TVCABLE BOGOTA 7303 1715 1133 229 Telecom Argentina Stet-France 18881 1441 844 20 Global Village Telecom 8151 1337 2801 412 UniNet S.A. de C.V. 11830 865 364 15 Instituto Costarricense de El 27947 841 93 94 Telconet S.A 6503 834 434 64 AVANTEL, S.A. 7738 780 1498 36 Telecomunicacoes da Bahia S.A 6147 770 376 21 Telefonica Del Peru 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 36998 1864 112 5 Sudanese Mobile Telephone (ZA 24863 880 306 30 LINKdotNET AS number 6713 554 633 26 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 216 The Internet Solution 29571 223 17 12 Ci Telecom Autonomous system 36992 222 501 28 Etisalat MISR 15706 221 32 6 Sudatel Internet Exchange Aut 29975 192 668 21 Vodacom 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 28573 3367 1730 94 NET Servicos de Comunicao S.A 6389 3061 3689 59 BellSouth.net Inc. 4766 2936 11562 937 Korea Telecom (KIX) 17974 2691 903 91 PT TELEKOMUNIKASI INDONESIA 10620 2584 421 246 TVCABLE BOGOTA 7545 2079 321 112 TPG Internet Pty Ltd 18566 2067 382 184 Covad Communications 22773 2038 2933 124 Cox Communications, Inc. 1785 2018 679 125 PaeTec Communications, Inc. 36998 1864 112 5 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3061 3002 BellSouth.net Inc. 17974 2691 2600 PT TELEKOMUNIKASI INDONESIA 10620 2584 2338 TVCABLE BOGOTA 4766 2936 1999 Korea Telecom (KIX) 7545 2079 1967 TPG Internet Pty Ltd 22773 2038 1914 Cox Communications, Inc. 1785 2018 1893 PaeTec Communications, Inc. 18566 2067 1883 Covad Communications 36998 1864 1859 Sudanese Mobile Telephone (ZA 8402 1781 1764 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.90.192.0/18 36086 Broad Communications Technolo 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.96.0/20 40676 Psychz Networks 23.91.112.0/21 32475 MidPhase Inc. 23.91.160.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.160.0/19 36493 3757277 Canada Inc. (oa 295.c 23.91.164.0/22 36493 3757277 Canada Inc. (oa 295.c 23.91.168.0/22 36493 3757277 Canada Inc. (oa 295.c 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:11 /10:31 /11:92 /12:250 /13:479 /14:916 /15:1628 /16:12805 /17:6693 /18:11207 /19:22943 /20:32591 /21:35192 /22:49711 /23:43071 /24:248290 /25:884 /26:990 /27:477 /28:48 /29:78 /30:20 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 36998 1829 1864 Sudanese Mobile Telephone (ZA 6389 1711 3061 BellSouth.net Inc. 8402 1501 1781 OJSC "Vimpelcom" 22773 1324 2038 Cox Communications, Inc. 30036 1203 1345 Mediacom Communications Corp 11492 1190 1231 Cable One 1785 1084 2018 PaeTec Communications, Inc. 6983 1026 1285 ITC^Deltacom 22561 963 1240 Digital Teleport, Inc Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:847 2:857 3:3 4:17 5:967 6:19 8:609 12:1891 13:3 14:870 15:11 16:3 17:13 18:19 20:21 23:445 24:1729 27:1589 31:1469 32:45 33:2 34:5 36:80 37:1827 38:909 39:3 40:179 41:3282 42:250 44:13 46:2014 47:5 49:677 50:842 52:12 54:39 55:6 57:26 58:1166 59:611 60:344 61:1421 62:1182 63:1990 64:4553 65:2344 66:4181 67:2080 68:1086 69:3325 70:868 71:495 72:2002 74:2561 75:330 76:302 77:1169 78:1052 79:640 80:1330 81:1033 82:623 83:584 84:588 85:1283 86:454 87:996 88:552 89:1731 90:158 91:5647 92:603 93:1617 94:1974 95:1596 96:517 97:343 98:1042 99:43 100:31 101:610 103:3368 105:520 106:143 107:208 108:510 109:1878 110:969 111:1122 112:579 113:800 114:734 115:1010 116:991 117:817 118:1165 119:1292 120:371 121:742 122:1884 123:1244 124:1388 125:1424 128:620 129:321 130:323 131:653 132:348 133:161 134:542 135:67 136:272 137:267 138:350 139:181 140:183 141:325 142:549 143:397 144:498 145:100 146:514 147:401 148:705 149:353 150:158 151:583 152:411 153:197 154:48 155:485 156:279 157:421 158:285 159:768 160:348 161:451 162:716 163:229 164:634 165:575 166:258 167:620 168:1050 169:128 170:1077 171:201 172:25 173:1612 174:664 175:502 176:1215 177:2307 178:1885 179:145 180:1542 181:748 182:1325 183:464 184:654 185:895 186:2592 187:1447 188:1900 189:1327 190:7154 192:6962 193:5633 194:4079 195:3338 196:1322 197:999 198:4688 199:5470 200:6072 201:2545 202:9022 203:8922 204:4510 205:2630 206:2866 207:2896 208:4010 209:3619 210:2938 211:1565 212:2262 213:2025 214:927 215:99 216:5338 217:1663 218:623 219:324 220:1279 221:565 222:326 223:504 End of report From rcarpen at network1.net Fri Sep 27 18:41:27 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 27 Sep 2013 14:41:27 -0400 (EDT) Subject: minimum IPv6 announcement size In-Reply-To: <1820E607-474D-44BB-B7F2-6691315CFB7E@bogus.com> References: <5241986D.60902@stluke.com.ph> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> <1820E607-474D-44BB-B7F2-6691315CFB7E@bogus.com> Message-ID: <1090776086.831770.1380307287064.JavaMail.zimbra@network1.net> > In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that > 18619 ~40% announce only one prefix. given the distribution of prefix counts > across ASNs it's quite reasonable to conclude that the consumption of > routing table slots is not primarly a property of the number of participants > but rather in the hands of a smaller number of large participants many of > whom are in this room. Which, compounds the idea that routing slots are going to be more of an issue than allocation size. -Randy From bill at herrin.us Fri Sep 27 20:10:23 2013 From: bill at herrin.us (William Herrin) Date: Fri, 27 Sep 2013 16:10:23 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> <545577352.831569.1380301463237.JavaMail.zimbra@network1.net> Message-ID: On Fri, Sep 27, 2013 at 2:11 PM, William Herrin wrote: > On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter wrote: >> Therefore, I don't see any reason to artificially inflate >> the routing table by conserving, and then making >> orgs come back for additional allocations. > > I'm not convinced of that. Suppose the plan was: you start with a /56. > When you need more you get a /48. Next is a /40. Next a /32. Next a > /28. You can hold exactly one of each size, never more. And the RIRs > tell us all which address banks each size comes from. > > In such a scenario, the RIR doesn't have to reserve a /28 for > expansion every time the allocate a /32. 'Cause, you know, that's what > they've been doing. And you can easily program your router to discard > the TE routes you don't wish to carry since you know what the > allocation size was. That means you only have to carry at most 5 > routes for any given organization. You'd want to allow some TE for the > sake of efficient routing, but you get to choose how much. > > As things stand now, you're going to allow those guys with the /19s > and /22s to do traffic engineering all the way down to /48. You don't > have a practical way to say "no." Point is: there are a number of address management practices which significantly impact the routing table size. The ones that jump to mind are: 1. Receiving discontiguous blocks from the registry on subsequent requests. If the blocks can't aggregate then they consume two routes even if they don't need to. Registry-level mitigations: allocate in excess of immediate need. Reserve additional space to allow subsequent allocations by changing the netmask on the same contiguous block. 2. Registry assignments to single-homed users. Registry assignments can't aggregate, even if their use shares fate with another AS's routes. Registry-level mitigations:minimize allocations to organizations which are not multihomed. 3. Traffic engineering. Fine tuning how data flows by cutting up an address block into smaller announced routes. Registry-level mitigations: Standardize allocation sizes and allocate from blocks reserved for that particular allocation size. Do not change a netmask in order to reduce or enlarge an allocation. This allows the recipients of TE advertisements to identify them and, if desired, filter them. 4. ISP assignments to multihomed users. In other networks, assignments to end users from your space are likely to be indistinguishable from traffic engineering routes. TE filtering is impossible if some of the announcements are multihomed customers whose fate is not shared with the ISP to whom the space was allocated. Registry-level mitigations: Direct assignment to all multihomed networks. Discourage ISPs from assigning subnets to multihomed customers. Note the contradictory mitigations. Standardized block sizes increases the number of discontiguous blocks. Netmask changes defeat standardized block sizes. So, it's a balancing act. Does more route bloat come from filterable TE? Or from discontiguous allocations? The customer lock-in from being the organization who assigns the customer's IP addresses turns around and bites you in the form of unfilterable traffic engineering routes. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cidr-report at potaroo.net Fri Sep 27 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Sep 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201309272200.r8RM00Of047421@wattle.apnic.net> This report has been generated at Fri Sep 27 21:13:30 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-09-13 482319 274366 21-09-13 482135 273979 22-09-13 481598 272878 23-09-13 479675 273689 24-09-13 480062 273326 25-09-13 479995 271315 26-09-13 478029 271319 27-09-13 480420 271265 AS Summary 45219 Number of ASes in routing system 18603 Number of ASes announcing only one prefix 4178 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118059200 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Sep13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 480472 271304 209168 43.5% All ASes AS6389 3061 62 2999 98.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3366 647 2719 80.8% NET Servi?os de Comunica??o S.A. AS17974 2690 184 2506 93.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4178 1856 2322 55.6% WINDSTREAM - Windstream Communications Inc AS4766 2936 945 1991 67.8% KIXS-AS-KR Korea Telecom AS22773 2041 135 1906 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2584 1023 1561 60.4% Telmex Colombia S.A. AS36998 1864 369 1495 80.2% SDN-MOBITEL AS18566 2066 572 1494 72.3% COVAD - Covad Communications Co. AS4323 2952 1533 1419 48.1% TWTC - tw telecom holdings, inc. AS18881 1440 68 1372 95.3% Global Village Telecom AS7303 1715 462 1253 73.1% Telecom Argentina S.A. AS1785 2019 810 1209 59.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1770 586 1184 66.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1252 157 1095 87.5% VIETEL-AS-AP Vietel Corporation AS22561 1240 215 1025 82.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS18101 982 180 802 81.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1192 402 790 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 2080 1321 759 36.5% TPG-INTERNET-AP TPG Telecom Limited AS11830 866 118 748 86.4% Instituto Costarricense de Electricidad y Telecom. AS701 1524 799 725 47.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1090 372 718 65.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1340 630 710 53.0% Uninet S.A. de C.V. AS13977 853 146 707 82.9% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS6983 1285 584 701 54.6% ITCDELTA - ITC^Deltacom AS6147 770 75 695 90.3% Telefonica del Peru S.A.A. AS855 733 55 678 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7738 780 138 642 82.3% Telemar Norte Leste S.A. AS17676 767 140 627 81.7% GIGAINFRA Softbank BB Corp. AS9808 809 209 600 74.2% CMNET-GD Guangdong Mobile Communication Co.Ltd. Total 52245 14793 37452 71.7% Top 30 total Possible Bogus Routes 23.92.128.0/17 AS42981 RES-PL RES.PL ISP S.C. 23.92.224.0/23 AS55048 VMWARE - VMware, Inc. 23.234.64.0/18 AS11878 TZULO - tzulo, inc. 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 31.13.184.0/21 AS42981 RES-PL RES.PL ISP S.C. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 82.103.0.0/18 AS30901 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.200.188.0/22 AS44016 91.205.188.0/22 AS47983 91.207.178.0/23 AS48274 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.9.220.0/24 AS13230 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 164.40.184.0/24 AS19821 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.9.59.0/24 AS1257 TELE2 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.30.0/23 AS24734 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.254.250.0/23 AS25349 193.254.250.0/24 AS25349 193.254.251.0/24 AS25349 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.84.16.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.84.17.0/24 AS17781 XINHUA Xinhua News Agency 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.225.0/24 AS3549 GBLX Global Crossing Ltd. 208.66.227.0/24 AS3549 GBLX Global Crossing Ltd. 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.87.144.0/21 AS21919 209.87.152.0/22 AS21919 209.87.156.0/24 AS21919 209.87.157.0/24 AS21919 209.87.158.0/24 AS21919 209.87.159.0/24 AS21919 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS1915 SEQUOIA-AS - National Science Foundation 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Sep 27 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Sep 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201309272200.r8RM01Q0047435@wattle.apnic.net> BGP Update Report Interval: 19-Sep-13 -to- 26-Sep-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 63716 2.4% 34.2 -- SDN-MOBITEL 2 - AS15003 57887 2.1% 42.2 -- NOBIS-TECH - Nobis Technology Group, LLC 3 - AS9829 48078 1.8% 38.7 -- BSNL-NIB National Internet Backbone 4 - AS8402 41150 1.5% 23.3 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS3816 39534 1.5% 53.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - AS10620 30502 1.1% 12.7 -- Telmex Colombia S.A. 7 - AS27738 29717 1.1% 51.5 -- Ecuadortelecom S.A. 8 - AS28573 25385 0.9% 7.3 -- NET Servi?os de Comunica??o S.A. 9 - AS4538 23805 0.9% 46.5 -- ERX-CERNET-BKB China Education and Research Network Center 10 - AS13118 22268 0.8% 473.8 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS8151 17767 0.7% 14.1 -- Uninet S.A. de C.V. 12 - AS4775 16050 0.6% 211.2 -- GLOBE-TELECOM-AS Globe Telecoms 13 - AS7552 14728 0.5% 11.7 -- VIETEL-AS-AP Vietel Corporation 14 - AS35819 13635 0.5% 24.4 -- MOBILY-AS Etihad Etisalat Company (Mobily) 15 - AS9416 12971 0.5% 1621.4 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 16 - AS11976 12348 0.5% 127.3 -- FIDN - Fidelity Communication International Inc. 17 - AS31148 10965 0.4% 11.1 -- FREENET-AS Freenet Ltd. 18 - AS1785 10962 0.4% 5.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS17974 10759 0.4% 4.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS23966 10687 0.4% 31.9 -- LDN-AS-PK LINKdotNET Telecom Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6174 7108 0.3% 3554.0 -- SPRINTLINK8 - Sprint 2 - AS42334 3185 0.1% 3185.0 -- BBP-AS Broadband Plus s.a.l. 3 - AS37367 3179 0.1% 3179.0 -- CALLKEY 4 - AS2 2732 0.1% 1985.0 -- CONTROLVM-MY ControlVM Technology 5 - AS19779 5317 0.2% 2658.5 -- 6 - AS11533 2026 0.1% 2026.0 -- VERITY-AS - Verity, Inc. 7 - AS9416 12971 0.5% 1621.4 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - AS6629 8989 0.3% 998.8 -- NOAA-AS - NOAA 9 - AS38000 1767 0.1% 883.5 -- CRISIL-AS [CRISIL Limited.Autonomous System] 10 - AS38268 826 0.0% 826.0 -- POINTWEST-AS-AP Pointwest Technologies Corp. 11 - AS7202 8640 0.3% 785.5 -- FAMU - Florida A & M University 12 - AS58085 6035 0.2% 754.4 -- TCE-ASN Esfahan Telecommunication Company (P.J.S.) 13 - AS48612 9507 0.3% 679.1 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 14 - AS53229 2002 0.1% 667.3 -- Industrias Arteb S.A 15 - AS18115 5934 0.2% 659.3 -- JGS-AS-AP JG Group of Companies 16 - AS45808 582 0.0% 582.0 -- UTP-MY Bandar Seri Iskandar 17 - AS58492 2966 0.1% 494.3 -- UNISSULA-AS-ID Universitas Islam Sultan Agung 18 - AS22688 986 0.0% 493.0 -- DOLGENCORP - Dollar General Corporation 19 - AS13118 22268 0.8% 473.8 -- ASN-YARTELECOM OJSC Rostelecom 20 - AS3 447 0.0% 307.0 -- RAFFEL-INTERNET Raffel Internet B.V. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21631 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 92.246.207.0/24 9453 0.3% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 192.58.232.0/24 8960 0.3% AS6629 -- NOAA-AS - NOAA 4 - 222.127.0.0/24 8058 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 5 - 120.28.62.0/24 7830 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 6 - 202.154.17.0/24 6874 0.2% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 7 - 203.118.232.0/21 6557 0.2% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - 203.118.224.0/21 6407 0.2% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - 67.210.190.0/23 6173 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 10 - 67.210.188.0/23 5727 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 11 - 204.29.132.0/23 4729 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 12 - 69.38.178.0/24 4455 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 13 - 115.170.128.0/17 4434 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 14 - 168.223.200.0/22 4321 0.1% AS7202 -- FAMU - Florida A & M University 15 - 168.223.206.0/23 4299 0.1% AS7202 -- FAMU - Florida A & M University 16 - 208.16.110.0/24 3556 0.1% AS6174 -- SPRINTLINK8 - Sprint 17 - 206.105.75.0/24 3552 0.1% AS6174 -- SPRINTLINK8 - Sprint 18 - 62.84.76.0/24 3185 0.1% AS42334 -- BBP-AS Broadband Plus s.a.l. 19 - 90.90.90.0/24 3181 0.1% AS58085 -- TCE-ASN Esfahan Telecommunication Company (P.J.S.) 20 - 41.75.40.0/21 3179 0.1% AS37367 -- CALLKEY Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Sep 27 22:42:41 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Sep 2013 15:42:41 -0700 Subject: minimum IPv6 announcement size In-Reply-To: <524496AA.5070705@bitfreak.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> Message-ID: <44351D76-7DFC-49F9-B732-27D4CB972AA8@delong.com> On Sep 26, 2013, at 13:18 , Darren Pilgrim wrote: > On 9/26/2013 1:07 PM, joel jaeggli wrote: >> >> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim >> wrote: >> >>> On 9/26/2013 1:52 AM, bmanning at vacation.karoshi.com wrote: >>>> sounds just like folks in 1985, talking about IPv4... >>> >>> The foundation of that, though, was ignorance of address space >>> exhaustion. IPv4's address space was too small for such large >>> thinking. >> >> The first dicussion I could find about ipv4 runnout in email >> archives is circa 1983 >> >>> IPv6 is far beyond enough to use such allocation policies. >> >> There are certain tendencies towards profligacy that might >> prematurely influence the question of ipv6 exhaustion and we should >> be on guard against them? allocating enough /48s as part of direct >> assignments is probably not one of them. > > That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. > There are some (bizarre) ideas for using IPv6 in really stupid ways that would profligately waste /12 and larger blocks of IPv6. There are no more /12s in IPv6 than there are /12s in IPv4... Exactly 4096 of them. If we waste ~4000 /12s, we might be in trouble. > Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. But a /64 is nowhere near enough. You should, instead, be presuming the following: a /48 for each human's tablet a /48 for each human's phone a /48 for each human household (~1 /48 per 3 humans) a /48 for each human business site (hard to develop a good ratio here, but I'd guess something like 20 wouldn't be unreasonable, so that's another /48 for every 20 humans). Then, add to that network infrastructure, servers, etc. Additionally, we expect IPv6 to last long enough that you may not be able to depend on Earth as a bounding limitation, nor can you count on the limits of current science as a population limit. > If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. You can't fit multiple /48s in a single /52, so that doesn't work. There are only 4096 /64s in a /52. > That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: This just doesn't work mathematically. You can't put multiple /48s into a /60... A /48 consists of 4096 /60s. > > - 1% utilisation would fit all those /48's into a /62. > - A full /64 of those /48's would be 0.2% utilisation. > - 0.1%? We'd have to steal a bit and hand out /47's instead. > - /47 is ugly. At /52, we'd get .024% (one per 4096). It's really hard to follow what you are trying to claim given that you seem to have the bit math all backwards. > > That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. I'm not sure what this is supposed to mean. > > Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6. In terms of current allocation policies for humans, devices, and infrastructure, that is true. However, at one point, many ISPs wanted a /16 in order to be able to give each IPv4 subscriber a /48 based on their current IPv4 unicast address(es) for 6rd. There are only 65,536 /16s in IPv6. (Which is one of the many reasons this proposal did not make it into policy without moving some bits to the right). Fortunately, few operators actually implemented 6rd in such a profligate way anyway, so little harm was done. There are other proposals that have been made. One proposal was to map VIN numbers onto /48 prefixes and give each car manufactured a /48 that would be permanently allocated to the vehicle. Since these network numbers would not be reliably reclaimable at vehicle end-of-life, this usage pattern could become problematic over time. There have been others as well. It is these unusual "special" uses that I think Joel is referring to. Not traditional assignments for traditional internet purposes. Owen From streiner at cluebyfour.org Thu Sep 26 10:53:53 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 26 Sep 2013 06:53:53 -0400 (EDT) Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: On Thu, 26 Sep 2013, Blake Pfankuch - Mailing List wrote: > To follow up, all of this fiber is mm and all light is sx to sfp. > Currently all 1gbit, but it will be repulled as 10gbit capable soon... I > guess I'm going to have to be a little less cheap and shoot for > something under $1000. I had an off list suggestion of the below > listed fluke. Any other suggestions or reccomendations? Fluke makes good stuff. What flavor of multimode fiber are you dealing with? The answer and the distance you can run becomes substantially more important at 10G. Hopefully you're at least dealing with OM3. OM1/OM2 imposes distance limitations and you'll likely need mode-conditioning jumpers to work at 10G. jms From mpalmer at hezmatt.org Fri Sep 27 23:17:15 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 28 Sep 2013 09:17:15 +1000 Subject: minimum IPv6 announcement size In-Reply-To: References: <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org> <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com> <524496AA.5070705@bitfreak.org> <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <20130927231715.GE6478@hezmatt.org> On Fri, Sep 27, 2013 at 02:10:47AM -0400, Ryan McIntosh wrote: > I don't respond to many of these threads but I have to say I've > contested this one too only to have to beaten into my head that a /64 > is "appropriate".. it still hasn't stuck, but unfortunately rfc's for > other protocols depend on the blocks to now be a /64.. I became a "convert" to the school of thought that hands out a /48 to every end user when I realised that the current, *most* profligate addressing scheme anyone's recommending involves essentially giving out an IPv6 /48 to anyone who's currently getting an IPv4 /32 (eyeball SP end-users, and dedicated server / VPS customers). Even with this scheme, we have an address space over eight *thousand* times greater than what we have now[1]. If I am the current IPv4 Internet, then we can have more IPv6 Internets than there are people in the town I live in. Once that sunk in, I realised that, practically speaking, we're solid. Yes, there have been a few "big" blocks like /20s handed out, but they're few and far between. I work for a comparatively *tiny* hosting company, and we've got 3 IPv4 /20s, and yet the single IPv6 /32 we've got should more than do us for a *very* long time to come[2]. I'm now firmly in the camp that the resource to be worrying about is routing table slots, not address space exhaustion. > It's a waste, even if we're "planning for the future", no one house > needs a /64 sitting on their lan.. or at least none I can sensibly > think of o_O. I prefer to think of it as simply "enough address space I don't have to worry about manual assignment", rather than "I'm 'wasting' 18446744073709551612 addresses". Thinking of IPv6 as being a 48-bit or 64-bit address space that also has the added bonus of never having to worry about host addressing makes things a lot more palatable. - Matt [1] And that's assuming that we only use 2000::/3 for this go around, which is one of six /3 blocks that we have to play with. If we completely fuck this up, we've effectively got IPv's 7 through 11 to try different ideas without having to change addressing formats. [2] To be fair, we're using an IPv6 addressing scheme that involves a lot more compaction than "/48s for everyone!", but even if we were handing out /48s for every machine in our facilities (which we wouldn't need to do, because plenty of customers have multiple machines, and thus would get a single /48 for all their machines), we'd still not be running out any time soon -- we've got ~65k IPv6 /48s, compared to ~12k IPv4 /32s, so yeah... -- Generally the folk who love the environment in vague, frilly ways are at odds with folk who love the environment next to the mashed potatoes. -- Anthony de Boer, in a place that does not exist From jeff-kell at utc.edu Fri Sep 27 23:36:28 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 27 Sep 2013 19:36:28 -0400 Subject: Suggestion on Fiber tester In-Reply-To: References: Message-ID: <5246167C.5030200@utc.edu> On 9/26/2013 6:53 AM, Justin M. Streiner wrote: > What flavor of multimode fiber are you dealing with? The answer and > the distance you can run becomes substantially more important at 10G. > > Hopefully you're at least dealing with OM3. OM1/OM2 imposes distance > limitations and you'll likely need mode-conditioning jumpers to work > at 10G. Excellent point. We have some over-a-decade old 62.5u MM that is useless for 10G (practically useless at 1G). It was fine at the time for 10Mb 10FL, but is now deprecated into oblivion. New runs are SM between buildings, and 50u OM3/OM4 inside. Another surprise that can vary by vendor... but "retail" Cisco LRM is cheaper than their SR, and is made for MM fiber (granted, OM3/OM4 ideally). Jeff From smb at cs.columbia.edu Sat Sep 28 23:10:29 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 28 Sep 2013 19:10:29 -0400 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> Message-ID: <8F02FE41-6198-4572-854A-CBDE23F68198@cs.columbia.edu> On Sep 26, 2013, at 11:07 AM, John Curran wrote: > On Sep 26, 2013, at 4:52 AM, bmanning at vacation.karoshi.com wrote: > >> sounds just like folks in 1985, talking about IPv4... > > If there were ever were a need for an market/settlement model, it is with respect > to routing table slots. https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997. We even had a BoF at an IETF, but you can imagine the reaction it got. --Steve Bellovin, https://www.cs.columbia.edu/~smb From chris at bigcommerce.com Sat Sep 28 11:15:22 2013 From: chris at bigcommerce.com (Chris Boulton) Date: Sat, 28 Sep 2013 21:15:22 +1000 Subject: Issues with connectivity through CoreSite & Voxel in LAX (help!) Message-ID: Hi all, We're having a hell of a time at the moment, with upstream connectivity issues for traffic going through Voxel in LAX. We're a few hops away (our provider peers with CoreSite who peer with Voxel), and aren't having much luck getting assistance on getting this resolved. We're 8 hours in to these issues. If there's anyone from CoreSite or Voxel about that could reply off list, can provide additional info and would be super grateful. Thanks, Chris Boulton Bigcommerce From ikiris at gmail.com Sun Sep 29 03:49:43 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 28 Sep 2013 22:49:43 -0500 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: <8F02FE41-6198-4572-854A-CBDE23F68198@cs.columbia.edu> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> <8F02FE41-6198-4572-854A-CBDE23F68198@cs.columbia.edu> Message-ID: Yes, I was lazy in most of the adaptation, but I think it serves a good starting point for market based suggestions to the route slot problem. Your post advocates a (X) technical ( ) legislative (X) market-based ( ) vigilante approach to fighting spam^H^H^H^H route deaggregation. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) (X) No one will be able to find the guy or collect the money (X) End Users will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it (X) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once ( ) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it (X) Lack of centrally controlling authority for routing ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats (X) Jurisdictional problems (X) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP^H^H^H^H BGP ( ) Susceptibility of protocols other than SMTP^H^H^H^H BGP to attack (X) Eternal arms race involved in all filtering approaches (X) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers (X) Dishonesty on the part of spammers themselves (X) Bandwidth costs that are unaffected by client filtering ( ) Outlook and the following philosophical objections may also apply: (X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable (X) SMTP headers^H^H^H^H^H^H^H Routing should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (X) Countermeasures must work if phased in gradually ( ) Sending email should be free (X) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: ( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down! -Blake On Sat, Sep 28, 2013 at 6:10 PM, Steven Bellovin wrote: > > On Sep 26, 2013, at 11:07 AM, John Curran wrote: > > > On Sep 26, 2013, at 4:52 AM, bmanning at vacation.karoshi.com wrote: > > > >> sounds just like folks in 1985, talking about IPv4... > > > > If there were ever were a need for an market/settlement model, it is > with respect > > to routing table slots. > > https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997. > > We even had a BoF at an IETF, but you can imagine the reaction it got. > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > From ben+nanog at list-subs.com Mon Sep 30 12:05:01 2013 From: ben+nanog at list-subs.com (Ben) Date: Mon, 30 Sep 2013 13:05:01 +0100 Subject: minimum IPv6 announcement size In-Reply-To: <20130926085250.GA8058@vacation.karoshi.com.> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> Message-ID: <524968ED.5010102@list-subs.com> On 26/09/2013 09:52, bmanning at vacation.karoshi.com wrote: > sounds just like folks in 1985, talking about IPv4... > Most people here were probably not of working age in 1985 ;-) From alexander at neilson.net.nz Mon Sep 30 12:58:29 2013 From: alexander at neilson.net.nz (Alexander Neilson) Date: Tue, 1 Oct 2013 01:58:29 +1300 Subject: Fwd: minimum IPv6 announcement size References: <524968ED.5010102@list-subs.com> Message-ID: <500F8ABA-5B72-4E17-985B-CCF167871B38@neilson.net.nz> *Beer* - sorry to take this further off topic. Regards Alexander Alexander Neilson Neilson Productions Limited alexander at neilson.net.nz 021 329 681 022 456 2326 Begin forwarded message: > From: Ben > Subject: Re: minimum IPv6 announcement size > Date: 1 October 2013 1:05:01 AM NZDT > To: nanog at nanog.org > > On 26/09/2013 09:52, bmanning at vacation.karoshi.com wrote: >> sounds just like folks in 1985, talking about IPv4... >> > > Most people here were probably not of working age in 1985 ;-) > > Working age?? some of us weren't even born yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4154 bytes Desc: not available URL: From bill at herrin.us Mon Sep 30 14:32:51 2013 From: bill at herrin.us (William Herrin) Date: Mon, 30 Sep 2013 10:32:51 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <52448B0D.8030505@bitfreak.org> Message-ID: On Thu, Sep 26, 2013 at 4:41 PM, Randy Bush wrote: >>> sounds just like folks in 1985, talking about IPv4... >> The foundation of that, though, was ignorance of address space >> exhaustion. > > no. ipv4 was the second time, not the first Hi Randy, The first time they had 256 addresses (8 bits) right? That's where the original /8 assignments in IPv4 came from, the folks listed back in RFC 758 who had an IP address before IPv4. IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Mon Sep 30 14:40:31 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 Sep 2013 10:40:31 -0400 Subject: minimum IPv6 announcement size In-Reply-To: Your message of "Mon, 30 Sep 2013 13:05:01 +0100." <524968ED.5010102@list-subs.com> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <524968ED.5010102@list-subs.com> Message-ID: <10865.1380552031@turing-police.cc.vt.edu> On Mon, 30 Sep 2013 13:05:01 +0100, Ben said: > Most people here were probably not of working age in 1985 ;-) "All you kids, get off my Proteon!" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From grpjl at iastate.edu Mon Sep 30 14:44:09 2013 From: grpjl at iastate.edu (Lustgraaf, Paul J [ITNET]) Date: Mon, 30 Sep 2013 14:44:09 +0000 Subject: minimum IPv6 announcement size In-Reply-To: <10865.1380552031@turing-police.cc.vt.edu> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <524968ED.5010102@list-subs.com> <10865.1380552031@turing-police.cc.vt.edu> Message-ID: Stop, you're giving me nightmares! Paul Lustgraaf grpjl at iastate.edu "Change is inevitable. Progress is not." Network Engineer, Iowa State University IT Services 515-294-0324 -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Monday, September 30, 2013 9:41 AM To: Ben Cc: nanog at nanog.org Subject: Re: minimum IPv6 announcement size On Mon, 30 Sep 2013 13:05:01 +0100, Ben said: > Most people here were probably not of working age in 1985 ;-) "All you kids, get off my Proteon!" :) From trejrco at gmail.com Mon Sep 30 14:46:51 2013 From: trejrco at gmail.com (TJ) Date: Mon, 30 Sep 2013 09:46:51 -0500 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <52448B0D.8030505@bitfreak.org> Message-ID: On Mon, Sep 30, 2013 at 9:32 AM, William Herrin wrote: > > IPv4 jumped from 8 bits to > 32 bits. Which when you think about it is the same ratio as jumping > from 32 bits to 128 bits. > Only insofar as the jump from 1 to 1000 is the same as the jump from 1000 is to 1000000 ... :) /TJ From bill at herrin.us Mon Sep 30 15:27:26 2013 From: bill at herrin.us (William Herrin) Date: Mon, 30 Sep 2013 11:27:26 -0400 Subject: minimum IPv6 announcement size In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <52448B0D.8030505@bitfreak.org> Message-ID: On Mon, Sep 30, 2013 at 10:46 AM, TJ wrote: > On Mon, Sep 30, 2013 at 9:32 AM, William Herrin wrote: >> IPv4 jumped from 8 bits to >> 32 bits. Which when you think about it is the same ratio as jumping >> from 32 bits to 128 bits. > > Only insofar as the jump from 1 to 1000 is the same as the jump from 1000 > is to 1000000 ... :) If we're on an exponential growth curve, it's the same ratio. Are we? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Mon Sep 30 17:15:55 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 30 Sep 2013 17:15:55 +0000 Subject: minimum IPv6 announcement size In-Reply-To: References: <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <52448B0D.8030505@bitfreak.org> Message-ID: <20130930171555.GA4209@vacation.karoshi.com.> On Mon, Sep 30, 2013 at 11:27:26AM -0400, William Herrin wrote: > On Mon, Sep 30, 2013 at 10:46 AM, TJ wrote: > > On Mon, Sep 30, 2013 at 9:32 AM, William Herrin wrote: > >> IPv4 jumped from 8 bits to > >> 32 bits. Which when you think about it is the same ratio as jumping > >> from 32 bits to 128 bits. > > > > Only insofar as the jump from 1 to 1000 is the same as the jump from 1000 > > is to 1000000 ... :) > > If we're on an exponential growth curve, it's the same ratio. Are we? > > Regards, > Bill Herrin sure... and I appreciate you advertizing all that unused "dark" space for me to hide my spam return addresses in. grateful you have enough bandwidth to absorb the incoming DDoS packets for non-existent hosts. profound thanks. /bill From jcurran at istaff.org Mon Sep 30 23:41:07 2013 From: jcurran at istaff.org (John Curran) Date: Mon, 30 Sep 2013 20:41:07 -0300 Subject: Filter-based routing table management (was: Re: minimum IPv6 announcement size) In-Reply-To: References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com> <0562B8C3-6E9B-483C-B1EC-4151B6072F0C@istaff.org> <8F02FE41-6198-4572-854A-CBDE23F68198@cs.columbia.edu> Message-ID: <80C73FBA-5D6A-4D4F-9624-D6C3C2E2943A@istaff.org> On Sep 29, 2013, at 12:49 AM, Blake Dunlap wrote: > Yes, I was lazy in most of the adaptation, but I think it serves a > good starting point for market based suggestions to the route slot > problem. > > Your post advocates a > > (X) technical ( ) legislative (X) market-based ( ) vigilante > > approach to fighting spam^H^H^H^H route deaggregation. Your idea will > not work. Here is why it won't work. > ... There's actually no new technology involved, and you're overlooking the fact that there already _is_ market operating when it comes to routing table slots - try asking your ISP if they'll accept and propagate more specifics and your answer is going based on imputed worth to them as a customer... you just have no visibility into their assessment of your value, nor any way to make the judgement yourself and pay accordingly. FYI, /John From elouie at yahoo.com Mon Sep 30 23:54:48 2013 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 30 Sep 2013 16:54:48 -0700 (PDT) Subject: minimum IPv6 announcement size In-Reply-To: <10865.1380552031@turing-police.cc.vt.edu> References: <5241986D.60902@stluke.com.ph> <5242543C.8020709@stluke.com.ph> <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com> <20130926085250.GA8058@vacation.karoshi.com.> <524968ED.5010102@list-subs.com> <10865.1380552031@turing-police.cc.vt.edu> Message-ID: <1380585288.12967.YahooMailNeo@web181601.mail.ne1.yahoo.com> "...and leave my BN alone, please - go play with the AGS" >________________________________ > From: "Valdis.Kletnieks at vt.edu" >To: Ben >Cc: nanog at nanog.org >Sent: Monday, September 30, 2013 7:40 AM >Subject: Re: minimum IPv6 announcement size > > >On Mon, 30 Sep 2013 13:05:01 +0100, Ben said: > >> Most people here were probably not of working age in 1985 ;-) > >"All you kids, get off my Proteon!" :) > > >