From johnl at iecc.com Fri Dec 1 01:47:47 2017 From: johnl at iecc.com (John Levine) Date: 1 Dec 2017 01:47:47 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <3d84c686-aa5f-8180-8a37-be77fef949a8@tnetconsulting.net> Message-ID: <20171201014747.25961.qmail@ary.lan> In article <3d84c686-aa5f-8180-8a37-be77fef949a8 at tnetconsulting.net> you write: >I would also configure MLMs to forward unknown bounces to the -owner. >Hopefully the -owner would then feed (a sanitized copy of) the unknown >bounce type the MLM maintainer(s) to improve said MLM. I suppose that would make sense for the 0.1% of mailing lists run by people with the skill and interest to hack on their list software. >> It's a rathole, it doesn't scale, and it is not a bug that you can >> send mail to people who you don't already know. > >I wasn't aware that DKIM-ATPS necessitated needing to know who you were >going to send to. ATPS was an experiment that failed. Nobody uses it, it didn't scale. >> If identities were a magic bullet, we'd all be signing with S/MIME. > >I am (and have been for years) a proponent of S/MIME. I can't help but note the absence of S/MIME signatures on roughly 100% of all of the messages in this thread. >(I think we're still talking about how can an intermediate mail server >be authorized to be part of the SMTP end-to-end mail delivery chain. >Even if said intermediate mail server is downstream of the sender.) Yeah, that's what ARC is intended to do. R's, John From owen at delong.com Fri Dec 1 02:26:04 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 18:26:04 -0800 Subject: WiFi - login page redirection not working In-Reply-To: References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: > On Nov 30, 2017, at 13:24 , Josh Luthman wrote: > > non-SSL requests are not the issue. > > SSL requests are. For example, Google cache's their 301 redirect from http://www.google.com to https://www.google.com which means clients that had access while that browser ps stays active will still attempt https instead of http, regardless of what you actually type. Right, you’re talking about HSTS as I mentioned below. However, if there’s a well known URL for getting the captive portal to work (e.g. http://captive.portal), then we educate users (or browsers that they can type captive.portal (or whatever URL we choose) instead of google (which was my traditional go to before HSTS, I admit) and voila… Problem solved. I’m fortunate enough to have my own non-HSTS domain that I use for this purpose and it’s quite easy and effective. Owen > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong > wrote: > > > On Nov 30, 2017, at 08:20 , Josh Luthman > wrote: > > > >> If TLS would somehow allow you to redirect... > > > > No but it would be nice to have a solution that redirects the user instead > > of "this page can't load" creating confusion. > > A well-known non-SSL (non-HSTS) URL that users could use for this purpose would > serve the same purpose without producing the security problems mentioned. > > Owen > > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess > wrote: > > > >> On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish > > >> wrote: > >> > >> > >>> Two points with this problem: 1)Is there a "non client" solution to the > >>> problem of the WiFi login notification not showing up on the clients > >> after > >>> connecting to the WiFi network? > >>> > >> > >> A Captive portal embedding WispR XML data > >> for connections from browsers/OSes that request a test page upon network > >> access. > >> https://stackoverflow.com/questions/3615147/how-to- > >> create-wifi-popup-login-page > >> > >> However if WPA2 authentication is not method used for access, then network > >> traffic is > >> vulnerable and not secured. > >> > >> AP solutions that are non-standard being a "Non client" solution and using > >> "Open Wireless" mode SSIDs are likely so deficient in security as to be > >> an unreasonable risk for users to actually connect to. > >> > >> > >>> Second, anything to be done from the AP to show the landing page even if > >>> the page requested is HTTPs? > >>> > >> > >> If TLS would somehow allow you to redirect or create a HTTPS connection > >> from > >> a domain name that is not yours, then this could obviously be exploited for > >> attacks..... > >> > >> -- > >> -JH > >> > > From gtaylor at tnetconsulting.net Fri Dec 1 02:35:05 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Nov 2017 19:35:05 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171201014747.25961.qmail@ary.lan> References: <20171201014747.25961.qmail@ary.lan> Message-ID: <0410015a-acae-1fa2-8bfb-acc92a652357@tnetconsulting.net> On 11/30/2017 06:47 PM, John Levine wrote: > I suppose that would make sense for the 0.1% of mailing lists run by > people with the skill and interest to hack on their list software. I guess I'm in the 0.1% then. > ATPS was an experiment that failed. Nobody uses it, it didn't scale. That's sort of what I've gathered. > I can't help but note the absence of S/MIME signatures on roughly 100% > of all of the messages in this thread. I believe that's because the mailing list strips non-text MIME parts, including the S/MIME signatures. > Yeah, that's what ARC is intended to do. Hum. My understanding of ARC is that it's a way for a server to assert things about what it received. - Where as my interpretation of what we were discussing is the sender authorizing intermediary MTAs to send the message. The former is after the fact, and the latter is before hand. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Fri Dec 1 02:38:00 2017 From: johnl at iecc.com (John R. Levine) Date: 30 Nov 2017 21:38:00 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <0410015a-acae-1fa2-8bfb-acc92a652357@tnetconsulting.net> References: <20171201014747.25961.qmail@ary.lan> <0410015a-acae-1fa2-8bfb-acc92a652357@tnetconsulting.net> Message-ID: >> Yeah, that's what ARC is intended to do. > > Hum. My understanding of ARC is that it's a way for a server to assert > things about what it received. - Where as my interpretation of what we were > discussing is the sender authorizing intermediary MTAs to send the message. > The former is after the fact, and the latter is before hand. I did a draft of a double signing thing that let the sender say who's expected to sign a modified forwarded version. The big mail systems weren't interested. They want the recipient system to decide. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From sean at donelan.com Fri Dec 1 03:34:33 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 30 Nov 2017 22:34:33 -0500 (EST) Subject: End of 2017 hurricane season Message-ID: November 30 is the official end of hurricane season in North America. Puerto Rico's Internet routing announcements are 95% of pre-Maria levels. US Virgin Islands Internet routing announcements are 80% of pre-Maria levels. The #(provider name)sucks tweets on twitter in South Florida and South Texas have essentially stopped. I assume this means that providers have repaired almost all Hurricane Harvey and Hurricane Irma damage. From colton.conor at gmail.com Fri Dec 1 04:56:29 2017 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 30 Nov 2017 22:56:29 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: Jared, Which Arista box do you use for FTTH features? Whats the cost like as FTTH boxes are usually inexpensive, and Arista is not know to be inexpensive compared to something like Calix or Adtran. On Thu, Nov 30, 2017 at 1:32 PM, Jared Mauch wrote: > > > > On Nov 30, 2017, at 2:17 PM, Ken Chase wrote: > > > > Back to this discussion! :) Arista as a viable full-table PE router. Was > hoping > > for better experience reports since last mention. > > > > To make the Q bit more general, are there any PE routers yet that can > handle 3-8 > > full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito > whitebox/ > > open routers still for that (bird/openbgp?) or microtiks? > > The 7280 is likely what you’re looking at. Lots of folks also use > MikroTik as well if > the traffic is in the 1G range or so. > > I for one use Arista for Layer3 for FTTH purposes as it gives me good > software/hardware > support for my features. > > - Jared From john at souvestre.com Fri Dec 1 06:15:01 2017 From: john at souvestre.com (John Souvestre) Date: Fri, 1 Dec 2017 00:15:01 -0600 Subject: End of 2017 hurricane season In-Reply-To: References: Message-ID: <000501d36a6b$b8ab10e0$2a0132a0$@Souvestre.com> Any idea what their pre and post traffic levels are? John     John Souvestre - New Orleans LA -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan Sent: 2017 November 30, Thu 21:35 To: nanog at nanog.org Subject: End of 2017 hurricane season November 30 is the official end of hurricane season in North America. Puerto Rico's Internet routing announcements are 95% of pre-Maria levels. US Virgin Islands Internet routing announcements are 80% of pre-Maria levels. The #(provider name)sucks tweets on twitter in South Florida and South Texas have essentially stopped. I assume this means that providers have repaired almost all Hurricane Harvey and Hurricane Irma damage. From bernat at luffy.cx Fri Dec 1 06:32:13 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 01 Dec 2017 07:32:13 +0100 Subject: WiFi - login page redirection not working In-Reply-To: (Owen DeLong's message of "Thu, 30 Nov 2017 18:26:04 -0800") References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: ❦ 30 novembre 2017 18:26 -0800, Owen DeLong  : >> SSL requests are. For example, Google cache's their 301 redirect >> from http://www.google.com to >> https://www.google.com which means clients >> that had access while that browser ps stays active will still >> attempt https instead of http, regardless of what you actually type. > > Right, you’re talking about HSTS as I mentioned below. > > However, if there’s a well known URL for getting the captive portal to > work (e.g. http://captive.portal), then we educate users (or > browsers that they can type captive.portal (or whatever URL we choose) > instead of google (which was my traditional go to before HSTS, > I admit) and voila… Problem solved. You can use http://neverssl.com/. But as mentioned earlier in the discussion, most OS have a non-HTTPS URL to detect a captive portal. They can display notifications to the user when they detect a captive portal. Browsers have that too. iOS/macOS: http://captive.apple.com/hotspot-detect.html Windows: http://www.msftncsi.com/ncsi.txt Ubuntu: http://start.ubuntu.com/connectivity-check Firefox: http://detectportal.firefox.com/ Chromium: http://clients3.google.com/generate_204 DHCP and neighbor discovery can also provide the information of the login page: https://tools.ietf.org/html/rfc7710 -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare From ruairi.carroll at gmail.com Fri Dec 1 09:09:06 2017 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Fri, 1 Dec 2017 09:09:06 +0000 Subject: Arista Layer3 In-Reply-To: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: Their L3 stuff is as stable as their L2 stuff, in general. MP-BGP and VRFs are a tiny bit bleeding edge/lacking features, however for plain OSPF/BGP, they're great. /Ruairi On 30 November 2017 at 18:36, Romeo Czumbil wrote: > So I've been using Arista as layer2 for quite some time, and I'm pretty > happy with them. > Kicking the idea around to turn on some Layer3 features but I've been > hearing some negative feedback. > The people that I did hear negative feedback don't use Arista themselves. > (they just heard....) > > So do we have any Arista L3 people out here that can share some negatives > or positives? > > Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > Maybe 20k routes (no full internet routes) > 7050 Series > 7280 Series > > -Romeo > From nanog at studio442.com.au Fri Dec 1 10:09:38 2017 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 1 Dec 2017 21:09:38 +1100 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <20171130202734.GA95926@vurt.meerval.net> References: <20171130200748.GC42601@vurt.meerval.net> <20171130202734.GA95926@vurt.meerval.net> Message-ID: <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> On 01/12/17 07:27, Job Snijders wrote: > Someone suggested I should clarify what 'aggregate6' actually does :-) > > aggregate6 takes a list of IPv4 and/or IPv6 prefixes in conventional > format, and performs two optimisations to attempt to reduce the length > of the prefix list. > > The first optimisation is to remove any supplied prefixes which are > superfluous because they are already included in another supplied > prefix. For example, 2001:67c:208c:10::/64 would be removed if > 2001:67c:208c::/48 was also supplied. > > The second optimisation identifies adjacent prefixes that can be > combined under a single, shorter-length prefix. For example, > 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the > single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and > 10.0.1.0/24 can be joined into 10.0.0.0/23. Will it catch cases like: 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22 > The above two optimalisations are useful in context of firewall rule > generation or generation of BGP prefix-list filters. Or being a nice citizen and rationalising your announcements. From elmi at 4ever.de Fri Dec 1 10:16:37 2017 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 1 Dec 2017 11:16:37 +0100 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> References: <20171130200748.GC42601@vurt.meerval.net> <20171130202734.GA95926@vurt.meerval.net> <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> Message-ID: <20171201101637.e42dwc3bcprkzh3j@nbmacvieebi.local> nanog at studio442.com.au (Julien Goodwin) wrote: > > The first optimisation is to remove any supplied prefixes which are > > superfluous because they are already included in another supplied > > prefix. For example, 2001:67c:208c:10::/64 would be removed if > > 2001:67c:208c::/48 was also supplied. > > > > The second optimisation identifies adjacent prefixes that can be > > combined under a single, shorter-length prefix. For example, > > 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the > > single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and > > 10.0.1.0/24 can be joined into 10.0.0.0/23. > > Will it catch cases like: > 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22 I guess the developers will have implemented a loop that runs until no more optimizations have been found. Which would of course catch it as Iteration 1 10.0.0.0/24 + 10.0.1.0/24 -> 10.0.0.0/23 Iteration 2 10.0.0.0/23 + 10.0.2.0/23 -> 10.0.0.0/22 From job at ntt.net Fri Dec 1 10:27:01 2017 From: job at ntt.net (Job Snijders) Date: Fri, 1 Dec 2017 11:27:01 +0100 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> References: <20171130200748.GC42601@vurt.meerval.net> <20171130202734.GA95926@vurt.meerval.net> <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> Message-ID: <20171201102701.GC1369@hanna.meerval.net> On Fri, Dec 01, 2017 at 09:09:38PM +1100, Julien Goodwin wrote: > Will it catch cases like: > 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22 Yes it does! hanna:~ job$ echo 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 | aggregate6 10.0.0.0/22 hanna:~ job$ Kind regards, Job From jared at puck.nether.net Fri Dec 1 11:16:03 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Dec 2017 06:16:03 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: > On Nov 30, 2017, at 11:56 PM, Colton Conor wrote: > > Jared, > > Which Arista box do you use for FTTH features? Whats the cost like as FTTH boxes are usually inexpensive, and Arista is not know to be inexpensive compared to something like Calix or Adtran. I use the DCS-7050S-52-F. This is because I get good routed features to meet my use-case, and the cost per SFP port was right. I’m purchasing them used, so my price per 1G port (that can also do 10G to uplink/infrastructure) is comparable to the per-port price of other BCM based SFP switches, and the software quality is much much higher. I don’t need 10’s of these either, so my use case is perhaps unique. I really need some basic routing support, DHCP relay w/ circuit id, etc. Ping me offline if you want more details about my use-case. Once I have a few more things sorted, expect a full nanog talk about my problem & solution. - Jared From shopik+lists at nvcube.net Fri Dec 1 12:02:37 2017 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Fri, 1 Dec 2017 15:02:37 +0300 Subject: WiFi - login page redirection not working In-Reply-To: References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: <98ae50fd-dda4-febe-5120-7585847dac2a@nvcube.net> On 01/12/17 09:32, Vincent Bernat wrote: > DHCP and neighbor discovery can also provide the information of the > login page: https://tools.ietf.org/html/rfc7710 I don't think it got support in any os. Current take on that is capport WG https://datatracker.ietf.org/wg/capport/documents/ From bernat at luffy.cx Fri Dec 1 12:16:23 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 01 Dec 2017 13:16:23 +0100 Subject: WiFi - login page redirection not working In-Reply-To: <98ae50fd-dda4-febe-5120-7585847dac2a@nvcube.net> (Nikolay Shopik's message of "Fri, 1 Dec 2017 15:02:37 +0300") References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> <98ae50fd-dda4-febe-5120-7585847dac2a@nvcube.net> Message-ID: <871skeod7s.fsf@luffy.cx> ❦ 1 décembre 2017 15:02 +0300, Nikolay Shopik  : >> DHCP and neighbor discovery can also provide the information of the >> login page: https://tools.ietf.org/html/rfc7710 > > I don't think it got support in any os. It's supported on Linux by Network Manager. -- All things that are, are with more spirit chased than enjoyed. -- Shakespeare, "Merchant of Venice" From craigwashington01 at hotmail.com Fri Dec 1 15:06:34 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Fri, 1 Dec 2017 15:06:34 +0000 Subject: BGP next-hop self benefits Message-ID: Hello everyone, Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor. Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links? Is there a added benefit to using next hop self in this situation? Any feedback is much appreciated, either for the question specifically or whatever else you got 😊, L3VPN's or underlying technology that has to have that. Thanks From gfocaccio at cari.net Fri Dec 1 01:06:14 2017 From: gfocaccio at cari.net (Gregorio Focaccio) Date: Fri, 1 Dec 2017 01:06:14 +0000 Subject: Update: Packet Loss through Level 3 in Southern California? Message-ID: Hi All, We have continued our investigation and data seem to show a more focused issue at the peering between Level 3 (CenturyLink) and MSN in LA. Can someone look at our data (new data below) and see if this seems like a reasonable conclusion? >From our network (San Diego) to an MSN Azure sever through the "Cogent | MSN Portal in LA" has no loss, but the same server has loss when going through the "Level 3 | MSN Portal in LA" Also, we have data showing no packet loss through the same Level 3 LA (LosAngeles1) nodes to Cogent to Texas, so data seems to clear the Level 3 Los Angeles and Cogent peering. Thanks, Greg Testing data: IPERF UDP results looks good on path through Level 3 (CenturyLink) in LA (LosAngeles1) when going to a server in Texas (non-MSN Azure) gfxc0.localdomain (0.0.0.0) Thu Nov 30 16:16:02 2017 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 216.75.40.1 0.0% 86 0.3 7.1 0.3 172.4 27.4 2. xe-8-3-3.bar1.SanDiego1.Level3.net 0.0% 86 3.3 3.6 3.3 25.4 2.4 3. ae-3-3.ebr1.LosAngeles1.Level3.net 90.6% 86 3.6 3.6 3.6 3.7 0.0 4. ae-1-51.ear2.LosAngeles1.Level3.net 95.3% 86 7225. 7157. 7134. 7225. 45.4 5. Cogent-level3-100G.LosAngeles1.Level3.net 0.0% 86 3.8 3.9 3.6 5.7 0.2 6. be3360.ccr42.lax01.atlas.cogentco.com 0.0% 86 3.6 3.7 3.5 4.0 0.0 7. be2932.ccr32.phx01.atlas.cogentco.com 0.0% 86 12.6 12.6 12.4 13.0 0.0 8. be2930.ccr21.elp01.atlas.cogentco.com 0.0% 85 20.7 20.9 20.6 22.5 0.2 9. be2928.ccr42.iah01.atlas.cogentco.com 0.0% 85 36.8 36.6 36.4 37.1 0.0 10. be2443.ccr32.dfw01.atlas.cogentco.com 0.0% 85 41.6 41.7 41.5 42.6 0.0 11. be2939.rcr21.dfw04.atlas.cogentco.com 0.0% 85 42.6 42.7 42.3 44.0 0.2 12. te0-0-1-1.nr12.b028597-0.dfw04.atlas.cogentco.com 0.0% 85 43.2 43.2 43.1 43.5 0.0 13. 38.122.200.202 0.0% 85 42.4 42.4 42.3 42.7 0.0 14. 138.128.243.167 0.0% 85 42.6 42.7 42.4 48.2 0.7 [root at gfxc0 ~]# iperf3 -uZVc 138.128.243.167 -b10m -t15 --get-server-output iperf 3.1.3 Linux gfxc0.localdomain 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 Time: Fri, 01 Dec 2017 00:17:19 GMT Connecting to host 138.128.243.167, port 5201 Cookie: gfxc0.localdomain.1512087439.341597. [ 4] local 216.75.40.2 port 42277 connected to 138.128.243.167 port 5201 Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 15 second test [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 1.09 MBytes 9.11 Mbits/sec 139 [ 4] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 6.00-7.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 7.00-8.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 10.00-11.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 11.00-12.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 14.00-15.00 sec 1.19 MBytes 9.96 Mbits/sec 152 - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-15.00 sec 17.8 MBytes 9.94 Mbits/sec 0.057 ms 0/2274 (0%) [ 4] Sent 2274 datagrams CPU Utilization: local/sender 0.7% (0.1%u/0.6%s), remote/receiver 0.1% (0.1%u/0.0%s) Server output: Accepted connection from 216.75.40.2, port 43300 [ 5] local 138.128.243.167 port 5201 connected to 216.75.40.2 port 42277 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 1.08 MBytes 9.04 Mbits/sec 0.068 ms 0/138 (0%) [ 5] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 0.060 ms 0/153 (0%) [ 5] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 0.058 ms 0/152 (0%) [ 5] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 0.058 ms 0/153 (0%) [ 5] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 0.061 ms 0/152 (0%) [ 5] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 0.121 ms 0/153 (0%) [ 5] 6.00-7.00 sec 1.19 MBytes 9.96 Mbits/sec 0.057 ms 0/152 (0%) [ 5] 7.00-8.00 sec 1.20 MBytes 10.0 Mbits/sec 0.056 ms 0/153 (0%) [ 5] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 0.106 ms 0/153 (0%) [ 5] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 0.083 ms 0/152 (0%) [ 5] 10.00-11.00 sec 1.20 MBytes 9.99 Mbits/sec 0.069 ms 0/153 (0%) [ 5] 11.00-12.00 sec 1.19 MBytes 10.0 Mbits/sec 0.054 ms 0/152 (0%) [ 5] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 0.061 ms 0/153 (0%) [ 5] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 0.063 ms 0/153 (0%) [ 5] 14.00-15.00 sec 1.19 MBytes 9.96 Mbits/sec 0.057 ms 0/152 (0%) iperf Done. [root at gfxc0 ~]# Results still look NOT OK when going through same Level 3 (CenturyLink) LA (LosAngeles1) nodes ebr1 and ear2 to an MSN Azure server My traceroute [v0.87] gfxc0.localdomain (0.0.0.0) Thu Nov 30 16:24:54 2017 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 216.75.40.1 0.0% 95 0.3 10.9 0.2 199.5 38.9 2. xe-8-3-3.bar1.SanDiego1.Level3.net 0.0% 95 3.3 3.7 3.2 20.6 1.9 3. ae-3-3.ebr1.LosAngeles1.Level3.net 98.9% 95 4.0 4.0 4.0 4.0 0.0 4. ae-1-51.ear2.LosAngeles1.Level3.net 96.8% 95 7101. 7046. 7004. 7101. 50.0 5. Microsoft-level3-20G.LosAngeles1.Level3.net 0.0% 95 15.2 17.7 9.3 20.8 2.4 6. be-63-0.ibr01.lax03.ntwk.msn.net 1.1% 95 29.9 30.1 22.7 34.0 2.6 7. be-4-0.ibr01.by2.ntwk.msn.net 1.1% 95 31.6 30.2 20.4 33.9 2.6 8. 104.44.7.198 0.0% 94 29.8 29.9 20.3 33.7 2.7 9. ae102-0.icr02.by21.ntwk.msn.net 0.0% 94 35.7 29.2 20.5 41.4 2.7 10. ??? [root at gfxc0 ~]# iperf3 -uZVc 13.91.55.110 -b10m -t15 --get-server-output iperf 3.1.3 Linux gfxc0.localdomain 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 Time: Fri, 01 Dec 2017 00:25:50 GMT Connecting to host 13.91.55.110, port 5201 Cookie: gfxc0.localdomain.1512087950.883346. [ 4] local 216.75.40.2 port 34611 connected to 13.91.55.110 port 5201 Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 15 second test [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 1.09 MBytes 9.11 Mbits/sec 139 [ 4] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 6.00-7.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 7.00-8.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 10.00-11.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 11.00-12.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 14.00-15.00 sec 1.19 MBytes 9.96 Mbits/sec 152 - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-15.00 sec 17.8 MBytes 9.94 Mbits/sec 0.141 ms 102/2274 (4.5%) [ 4] Sent 2274 datagrams CPU Utilization: local/sender 0.7% (0.1%u/0.6%s), remote/receiver 0.1% (0.0%u/0.1%s) Server output: ----------------------------------------------------------- Accepted connection from 216.75.40.2, port 44374 [ 5] local 10.0.0.4 port 5201 connected to 216.75.40.2 port 34611 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 1.08 MBytes 9.04 Mbits/sec 0.174 ms 0/138 (0%) [ 5] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 0.203 ms 0/153 (0%) [ 5] 2.00-3.00 sec 1.17 MBytes 9.83 Mbits/sec 0.196 ms 2/152 (1.3%) [ 5] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 0.110 ms 0/153 (0%) [ 5] 4.00-5.00 sec 1.16 MBytes 9.69 Mbits/sec 0.120 ms 4/152 (2.6%) [ 5] 5.00-6.00 sec 1.11 MBytes 9.31 Mbits/sec 0.106 ms 11/153 (7.2%) [ 5] 6.00-7.00 sec 1.13 MBytes 9.50 Mbits/sec 0.313 ms 7/152 (4.6%) [ 5] 7.00-8.00 sec 992 KBytes 8.13 Mbits/sec 0.163 ms 29/153 (19%) [ 5] 8.00-9.00 sec 1.06 MBytes 8.91 Mbits/sec 0.129 ms 17/153 (11%) [ 5] 9.00-10.00 sec 1.12 MBytes 9.37 Mbits/sec 0.131 ms 9/152 (5.9%) [ 5] 10.00-11.00 sec 1.19 MBytes 9.96 Mbits/sec 0.155 ms 1/153 (0.65%) [ 5] 11.00-12.00 sec 1.12 MBytes 9.44 Mbits/sec 0.336 ms 5/149 (3.4%) [ 5] 12.00-13.00 sec 1.09 MBytes 9.18 Mbits/sec 0.166 ms 16/156 (10%) [ 5] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 0.109 ms 0/153 (0%) [ 5] 14.00-15.00 sec 1.18 MBytes 9.90 Mbits/sec 0.141 ms 1/152 (0.66%) iperf Done. [root at gfxc0 ~]# "tcp slowdown" [root at gfxc0 ~]# iperf3 -ZVc 13.91.55.110 -b20m -t15 --get-server-output iperf 3.1.3 Linux gfxc0.localdomain 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 Time: Fri, 01 Dec 2017 00:30:16 GMT Connecting to host 13.91.55.110, port 5201 Cookie: gfxc0.localdomain.1512088216.384940. TCP MSS: 1428 (default) [ 4] local 216.75.40.2 port 44388 connected to 13.91.55.110 port 5201 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 15 second test [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 2.33 MBytes 19.6 Mbits/sec 13 411 KBytes [ 4] 1.00-2.00 sec 2.38 MBytes 19.9 Mbits/sec 13 201 KBytes [ 4] 2.00-3.00 sec 2.38 MBytes 19.9 Mbits/sec 3 105 KBytes [ 4] 3.00-4.00 sec 2.45 MBytes 20.6 Mbits/sec 3 64.1 KBytes [ 4] 4.00-5.00 sec 1.91 MBytes 16.1 Mbits/sec 10 44.6 KBytes [ 4] 5.00-6.00 sec 1.26 MBytes 10.5 Mbits/sec 8 36.3 KBytes [ 4] 6.00-7.00 sec 1.26 MBytes 10.6 Mbits/sec 6 20.9 KBytes [ 4] 7.00-8.00 sec 803 KBytes 6.58 Mbits/sec 3 22.3 KBytes [ 4] 8.00-9.00 sec 697 KBytes 5.71 Mbits/sec 3 25.1 KBytes [ 4] 9.00-10.00 sec 1.27 MBytes 10.6 Mbits/sec 0 48.8 KBytes [ 4] 10.00-11.00 sec 1.53 MBytes 12.9 Mbits/sec 4 37.7 KBytes [ 4] 11.00-12.00 sec 1.21 MBytes 10.1 Mbits/sec 5 33.5 KBytes [ 4] 12.00-13.00 sec 1.35 MBytes 11.3 Mbits/sec 1 40.4 KBytes [ 4] 13.00-14.00 sec 1.33 MBytes 11.1 Mbits/sec 1 51.6 KBytes [ 4] 14.00-15.00 sec 2.28 MBytes 19.1 Mbits/sec 2 53.0 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-15.00 sec 24.4 MBytes 13.6 Mbits/sec 75 sender [ 4] 0.00-15.00 sec 24.1 MBytes 13.5 Mbits/sec receiver CPU Utilization: local/sender 0.7% (0.1%u/0.6%s), remote/receiver 0.2% (0.0%u/0.2%s) Server output: ----------------------------------------------------------- Accepted connection from 216.75.40.2, port 44386 [ 5] local 10.0.0.4 port 5201 connected to 216.75.40.2 port 44388 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 2.21 MBytes 18.5 Mbits/sec [ 5] 1.00-2.00 sec 2.38 MBytes 19.9 Mbits/sec [ 5] 2.00-3.00 sec 2.38 MBytes 19.9 Mbits/sec [ 5] 3.00-4.00 sec 2.23 MBytes 18.7 Mbits/sec [ 5] 4.00-5.00 sec 1.93 MBytes 16.2 Mbits/sec [ 5] 5.00-6.00 sec 1.26 MBytes 10.6 Mbits/sec [ 5] 6.00-7.00 sec 1.27 MBytes 10.6 Mbits/sec [ 5] 7.00-8.00 sec 800 KBytes 6.56 Mbits/sec [ 5] 8.00-9.00 sec 692 KBytes 5.67 Mbits/sec [ 5] 9.00-10.00 sec 1.27 MBytes 10.7 Mbits/sec [ 5] 10.00-11.00 sec 1.53 MBytes 12.9 Mbits/sec [ 5] 11.00-12.00 sec 1.21 MBytes 10.2 Mbits/sec [ 5] 12.00-13.00 sec 1.35 MBytes 11.3 Mbits/sec [ 5] 13.00-14.00 sec 1.32 MBytes 11.1 Mbits/sec [ 5] 14.00-15.00 sec 2.26 MBytes 18.9 Mbits/sec iperf Done. [root at gfxc0 ~]# ...but then results look OK to same Azure server when traffic forced to get to MSN via Cogent My traceroute [v0.87] gfxc0.localdomain (0.0.0.0) Thu Nov 30 16:20:50 2017 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 216.75.40.1 0.0% 19 0.3 9.9 0.3 124.0 30.6 2. 216.98.153.90 0.0% 19 63.8 10.0 0.3 117.3 29.8 3. te0-0-2-2.agr11.san01.atlas.cogentco.com 0.0% 19 1.6 0.9 0.7 1.6 0.0 4. te0-0-0-3.rcr12.san01.atlas.cogentco.com 0.0% 19 1.0 1.0 0.8 1.2 0.0 5. be2937.rcr12.sna02.atlas.cogentco.com 0.0% 19 3.2 3.3 3.2 3.5 0.0 6. be2463.agr22.lax01.atlas.cogentco.com 0.0% 19 4.0 4.3 4.0 6.7 0.5 7. be2586.ccr41.lax01.atlas.cogentco.com 0.0% 19 4.1 4.1 4.0 4.4 0.0 8. be3271.ccr41.lax04.atlas.cogentco.com 0.0% 19 4.9 4.7 4.0 9.2 1.0 9. 38.142.33.250 0.0% 19 4.0 3.9 3.8 4.0 0.0 10. be-63-0.ibr01.lax03.ntwk.msn.net 0.0% 19 17.0 16.6 15.6 17.4 0.2 11. be-4-0.ibr01.by2.ntwk.msn.net 0.0% 19 17.2 16.9 15.9 17.9 0.0 12. 104.44.7.198 0.0% 19 16.1 17.0 16.1 17.8 0.2 13. ae103-0.icr02.by4.ntwk.msn.net 0.0% 19 15.2 15.3 15.1 17.3 0.4 14. ??? [root at gfxc0 ~]# iperf3 -uZVc 13.91.55.110 -b10m -t15 --get-server-output iperf 3.1.3 Linux gfxc0.localdomain 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 Time: Fri, 01 Dec 2017 00:21:51 GMT Connecting to host 13.91.55.110, port 5201 Cookie: gfxc0.localdomain.1512087711.332144. [ 4] local 216.75.40.2 port 43882 connected to 13.91.55.110 port 5201 Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 15 second test [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 1.09 MBytes 9.11 Mbits/sec 139 [ 4] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 6.00-7.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 7.00-8.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 10.00-11.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 11.00-12.00 sec 1.19 MBytes 9.96 Mbits/sec 152 [ 4] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 153 [ 4] 14.00-15.00 sec 1.19 MBytes 9.96 Mbits/sec 152 - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-15.00 sec 17.8 MBytes 9.94 Mbits/sec 0.046 ms 0/2274 (0%) [ 4] Sent 2274 datagrams CPU Utilization: local/sender 0.7% (0.1%u/0.7%s), remote/receiver 0.0% (0.0%u/0.0%s) Server output: ----------------------------------------------------------- Accepted connection from 216.75.40.2, port 44356 [ 5] local 10.0.0.4 port 5201 connected to 216.75.40.2 port 43882 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 1.08 MBytes 9.04 Mbits/sec 0.036 ms 0/138 (0%) [ 5] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 0.057 ms 0/153 (0%) [ 5] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 0.047 ms 0/152 (0%) [ 5] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 0.049 ms 0/153 (0%) [ 5] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 0.064 ms 0/152 (0%) [ 5] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 0.059 ms 0/153 (0%) [ 5] 6.00-7.00 sec 1.19 MBytes 9.96 Mbits/sec 0.056 ms 0/152 (0%) [ 5] 7.00-8.00 sec 1.20 MBytes 10.0 Mbits/sec 0.055 ms 0/153 (0%) [ 5] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 0.061 ms 0/153 (0%) [ 5] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 0.051 ms 0/152 (0%) [ 5] 10.00-11.00 sec 1.20 MBytes 10.0 Mbits/sec 0.057 ms 0/153 (0%) [ 5] 11.00-12.00 sec 1.19 MBytes 9.96 Mbits/sec 0.053 ms 0/152 (0%) [ 5] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 0.055 ms 0/153 (0%) [ 5] 13.00-14.00 sec 1.20 MBytes 10.0 Mbits/sec 0.063 ms 0/153 (0%) [ 5] 14.00-15.00 sec 1.19 MBytes 9.96 Mbits/sec 0.046 ms 0/152 (0%) iperf Done. [root at gfxc0 ~]# From: Gregorio Focaccio Sent: Tuesday, November 28, 2017 2:05 PM To: 'nanog at nanog.org' Subject: Packet Loss through Level 3 in Southern California? Hi All, We are a multi-datacenter MSP in San Diego that also offers Colo and Cloud hosting. We are multi-homed with Level 3 and Cogent. A client reported newly slow FTP transfers, so we started a network investigation. Our data (see below) seem to show packet loss through Level 3 with associated slow TCP based data transfers. Is anyone else seeing packet loss and consequent slow TCP based transfers when going through Level 3 in Southern California? Thanks, Greg Focaccio CARI.net Testing Data: ********** Internal tests - OK ********** FTP transfers from client server to another server 3 hops away in our adjacent datacenter was normal ********** Level 3 data - packet loss ********** External tests via Level 3 - 12% Packet Loss - see data below UDP IPERF testing from our data center (through Level 3 and Microsoft - trace below) to an Azure server showed repeatable packet loss TCP based testing - such as FTP or SCP transfers - the rate was very slow about 4Mbps [root at raynor ~]# iperf3 -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 55684 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1001 KBytes 8.20 Mbits/sec 34 9.76 KBytes [ 4] 1.00-2.00 sec 503 KBytes 4.12 Mbits/sec 12 11.2 KBytes [ 4] 2.00-3.00 sec 502 KBytes 4.11 Mbits/sec 3 25.1 KBytes [ 4] 3.00-4.00 sec 502 KBytes 4.11 Mbits/sec 12 11.2 KBytes [ 4] 4.00-5.00 sec 377 KBytes 3.08 Mbits/sec 9 15.3 KBytes [ 4] 5.00-6.00 sec 502 KBytes 4.11 Mbits/sec 10 19.5 KBytes [ 4] 6.00-7.00 sec 377 KBytes 3.09 Mbits/sec 13 6.97 KBytes [ 4] 7.00-8.00 sec 251 KBytes 2.06 Mbits/sec 9 5.58 KBytes [ 4] 8.00-9.00 sec 251 KBytes 2.06 Mbits/sec 6 9.76 KBytes [ 4] 9.00-10.00 sec 251 KBytes 2.06 Mbits/sec 10 12.6 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 4.41 MBytes 3.70 Mbits/sec 118 sender [ 4] 0.00-10.00 sec 4.24 MBytes 3.56 Mbits/sec receiver iperf Done. [root at raynor ~]# iperf3 -u -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 39221 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 85.0 MBytes 712 Mbits/sec 62402 [ 4] 1.00-2.00 sec 94.0 MBytes 789 Mbits/sec 69043 [ 4] 2.00-3.00 sec 92.6 MBytes 777 Mbits/sec 68030 [ 4] 3.00-4.00 sec 76.5 MBytes 641 Mbits/sec 56153 [ 4] 4.00-5.00 sec 94.9 MBytes 796 Mbits/sec 69662 [ 4] 5.00-6.00 sec 97.7 MBytes 819 Mbits/sec 71713 [ 4] 6.00-7.00 sec 98.5 MBytes 826 Mbits/sec 72347 [ 4] 7.00-8.00 sec 92.7 MBytes 778 Mbits/sec 68085 [ 4] 8.00-9.00 sec 91.3 MBytes 765 Mbits/sec 67045 [ 4] 9.00-10.00 sec 59.3 MBytes 498 Mbits/sec 43551 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 883 MBytes 740 Mbits/sec 0.014 ms 75647/647955 (12%) [ 4] Sent 647955 datagrams iperf Done. [root at raynor ~]# traceroute 40.80.156.2 traceroute to 40.80.156.2 (40.80.156.2), 30 hops max, 60 byte packets 1 gateway (71.6.220.97) 6.170 ms 7.827 ms 10.718 ms 2 209.126.134.65 (209.126.134.65) 0.426 ms 0.420 ms 0.543 ms 3 216.98.153.21 (216.98.153.21) 159.936 ms 160.215 ms 160.209 ms 4 gi1-2.gw65-50.c5.sdcix.net (216.98.153.89) 170.977 ms 170.972 ms 170.964 ms 5 xe-8-3-3.bar1.SanDiego1.Level3.net (4.16.105.93) 0.547 ms 0.586 ms 0.533 ms 6 * * * 7 * * * 8 Microsoft-level3-20G.LosAngeles1.Level3.net (4.68.111.122) 17.296 ms 18.026 ms 20.200 ms 9 be-61-0.ibr01.lax03.ntwk.msn.net (104.44.8.104) 30.108 ms 32.300 ms 32.283 ms 10 be-4-0.ibr01.by2.ntwk.msn.net (104.44.4.3) 30.364 ms 30.961 ms 28.960 ms 11 104.44.7.198 (104.44.7.198) 31.870 ms 30.120 ms 29.636 ms 12 ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 27.828 ms ae101-0.icr01.by4.ntwk.msn.net (104.44.11.193) 29.611 ms ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 27.710 ms 13 * * * [root at raynor ~]# scp ubuntu-14.04.5-desktop-amd64.iso carinet at 40.80.156.2:/home/carinet/ubuntunew11.iso ubuntu-14.04.5-desktop-amd64.iso 100% 1053MB 730.8KB/s 24:35 LEVEL3 - summary CARIcloud to Azure 2 Mbits/s TCP iperf 800 Mbits/s UDP iperf 24m and 35s 1053 MB upload to Azure through SCP ********** Cogent data - OK ********** External tests via Cogent - OK - No significant loss - see IPERF and trace data below [root at raynor ~]# iperf3 -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 45076 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 149 MBytes 1.25 Gbits/sec 0 4.58 MBytes [ 4] 1.00-2.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 2.00-3.00 sec 178 MBytes 1.50 Gbits/sec 0 4.58 MBytes [ 4] 3.00-4.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 4.00-5.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 5.00-6.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 6.00-7.00 sec 179 MBytes 1.50 Gbits/sec 0 4.58 MBytes [ 4] 7.00-8.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 8.00-9.00 sec 181 MBytes 1.52 Gbits/sec 0 4.58 MBytes [ 4] 9.00-10.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec receiver iperf Done. [root at raynor ~]# iperf3 -u -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 39130 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 101 MBytes 844 Mbits/sec 73869 [ 4] 1.00-2.00 sec 103 MBytes 861 Mbits/sec 75344 [ 4] 2.00-3.00 sec 99.0 MBytes 830 Mbits/sec 72700 [ 4] 3.00-4.00 sec 97.9 MBytes 821 Mbits/sec 71885 [ 4] 4.00-5.00 sec 98.0 MBytes 822 Mbits/sec 71979 [ 4] 5.00-6.00 sec 100 MBytes 841 Mbits/sec 73640 [ 4] 6.00-7.00 sec 69.8 MBytes 585 Mbits/sec 51237 [ 4] 7.00-8.00 sec 94.9 MBytes 796 Mbits/sec 69650 [ 4] 8.00-9.00 sec 102 MBytes 855 Mbits/sec 74804 [ 4] 9.00-10.00 sec 100 MBytes 839 Mbits/sec 73407 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 965 MBytes 809 Mbits/sec 0.004 ms 3194/708505 (0.45%) [ 4] Sent 708505 datagrams iperf Done. [root at raynor ~]# traceroute 40.80.156.2 traceroute to 40.80.156.2 (40.80.156.2), 30 hops max, 60 byte packets 1 gateway (71.6.220.97) 9.892 ms 10.883 ms 15.574 ms 2 209.126.134.65 (209.126.134.65) 1.541 ms 1.966 ms 1.959 ms 3 216.98.153.21 (216.98.153.21) 0.523 ms 0.517 ms 0.511 ms 4 216.98.153.114 (216.98.153.114) 0.589 ms 0.480 ms 0.687 ms 5 te0-0-1-0.nr11.b005949-0.san01.atlas.cogentco.com (38.104.122.61) 1.045 ms 1.039 ms 1.072 ms 6 te0-0-0-3.agr11.san01.atlas.cogentco.com (154.24.32.53) 1.023 ms 0.823 ms te0-0-0-3.agr12.san01.atlas.cogentco.com (154.24.32.65) 1.359 ms 7 te0-0-1-3.rcr11.san01.atlas.cogentco.com (154.24.31.21) 0.919 ms te0-0-1-3.rcr12.san01.atlas.cogentco.com (154.24.31.37) 0.834 ms 0.874 ms 8 be2936.rcr11.sna02.atlas.cogentco.com (154.54.45.166) 3.947 ms 3.726 ms be2937.rcr12.sna02.atlas.cogentco.com (154.54.45.173) 3.221 ms 9 be2463.agr22.lax01.atlas.cogentco.com (154.54.80.61) 4.095 ms 3.960 ms 4.087 ms 10 be2584.ccr41.lax01.atlas.cogentco.com (154.54.29.33) 4.364 ms 3.961 ms be2586.ccr41.lax01.atlas.cogentco.com (154.54.29.245) 4.290 ms 11 be3360.ccr41.lax04.atlas.cogentco.com (154.54.25.150) 4.283 ms be3271.ccr41.lax04.atlas.cogentco.com (154.54.42.102) 4.020 ms 4.003 ms 12 38.142.33.250 (38.142.33.250) 3.828 ms 3.818 ms 3.481 ms 13 be-61-0.ibr01.lax03.ntwk.msn.net (104.44.8.104) 15.565 ms 15.291 ms 15.173 ms 14 be-4-0.ibr01.by2.ntwk.msn.net (104.44.4.3) 14.290 ms 13.903 ms 16.168 ms 15 104.44.7.198 (104.44.7.198) 15.445 ms 14.098 ms 13.866 ms 16 ae102-0.icr02.by21.ntwk.msn.net (104.44.11.198) 13.752 ms ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 14.378 ms ae101-0.icr01.by4.ntwk.msn.net (104.44.11.193) 13.813 ms [root at raynor ~]# scp ubuntu-14.04.5-desktop-amd64.iso carinet at 40.80.156.2:/home/carinet/ubuntunew10.iso ubuntu-14.04.5-desktop-amd64.iso 100% 1053MB 111.5MB/s 00:09 COGENT - summary CARIcloud to Azure 1.5 Gbits/s TCP iperf 850 Mbits/s UDP iperf 9s 1053 MB upload to Azure through SCP From carlosm3011 at gmail.com Fri Dec 1 15:24:27 2017 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Fri, 01 Dec 2017 12:24:27 -0300 Subject: Contacting AS6589 - "Beneficial Technologies" Message-ID: <74AC02BE-35F5-4C0E-8062-0A4B8D6A9940@gmail.com> Hello all, I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are announcing large chunk of LACNIC unallocated space, as can be seen here: https://bgp.he.net/AS6589 Although I usually give people the benefit of doubt, in this case we are talking about 5 /16 prefixes. Talk about fat fingers. Private email is ok. Thanks Carlos LACNIC CTO From Nathan.Brookfield at simtronic.com.au Fri Dec 1 15:30:28 2017 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Fri, 1 Dec 2017 15:30:28 +0000 Subject: Contacting AS6589 - "Beneficial Technologies" In-Reply-To: <74AC02BE-35F5-4C0E-8062-0A4B8D6A9940@gmail.com> References: <74AC02BE-35F5-4C0E-8062-0A4B8D6A9940@gmail.com> Message-ID: <3F60B80E-5726-46A1-9082-C272F6290C94@simtronic.com.au> The remainder of the advertisements being more /16’s from China.... Seems very very bogus. Nathan Brookfield Chief Executive Officer Simtronic Technologies Pty Ltd http://www.simtronic.com.au On 2 Dec 2017, at 02:27, Carlos M. Martinez > wrote: Hello all, I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are announcing large chunk of LACNIC unallocated space, as can be seen here: https://bgp.he.net/AS6589 Although I usually give people the benefit of doubt, in this case we are talking about 5 /16 prefixes. Talk about fat fingers. Private email is ok. Thanks Carlos LACNIC CTO From math at sizone.org Fri Dec 1 15:30:56 2017 From: math at sizone.org (Ken Chase) Date: Fri, 1 Dec 2017 10:30:56 -0500 Subject: BGP next-hop self benefits In-Reply-To: References: Message-ID: <20171201153056.GF9565@sizone.org> On an IX, without next-hop-self peer A leaking peer B's routes they receive to C will have C send direct to B on the IX (assuming flat layer 3 addressing, and not multiple little /30s or /96s everywhere or something - do any exchanges do that?) This may seem more efficient than sending C's traffic to A to get to B (pumping up the IX's usage graphs) but B may not have peering agreements with C. Setting next-hop-self avoids this. An 'advantage' in some views. Not related to n-h-s in an igp specifically, but an interesting (mis)use case. /kc On Fri, Dec 01, 2017 at 03:06:34PM +0000, craig washington said: >Hello everyone, > > >Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor. > >Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links? > >Is there a added benefit to using next hop self in this situation? > > >Any feedback is much appreciated, either for the question specifically or whatever else you got ????, L3VPN's or underlying technology that has to have that. > > >Thanks > > -- Ken Chase - math at sizone.org Guelph Canada From dovid at telecurve.com Fri Dec 1 15:34:26 2017 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 1 Dec 2017 10:34:26 -0500 Subject: Contacting AS6589 - "Beneficial Technologies" In-Reply-To: <3F60B80E-5726-46A1-9082-C272F6290C94@simtronic.com.au> References: <74AC02BE-35F5-4C0E-8062-0A4B8D6A9940@gmail.com> <3F60B80E-5726-46A1-9082-C272F6290C94@simtronic.com.au> Message-ID: Public shaking seems to work. They are no longer advertising those prefixes. On Fri, Dec 1, 2017 at 10:30 AM, Nathan Brookfield < Nathan.Brookfield at simtronic.com.au> wrote: > The remainder of the advertisements being more /16’s from China.... Seems > very very bogus. > > Nathan Brookfield > Chief Executive Officer > > Simtronic Technologies Pty Ltd > http://www.simtronic.com.au > > On 2 Dec 2017, at 02:27, Carlos M. Martinez carlosm3011 at gmail.com>> wrote: > > Hello all, > > I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are > announcing large chunk of LACNIC unallocated space, as can be seen here: > https://bgp.he.net/AS6589 > > Although I usually give people the benefit of doubt, in this case we are > talking about 5 /16 prefixes. Talk about fat fingers. > > Private email is ok. > > Thanks > > Carlos > LACNIC CTO > From frederik at kriewitz.eu Fri Dec 1 15:59:36 2017 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Fri, 1 Dec 2017 16:59:36 +0100 Subject: Arista Layer3 In-Reply-To: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: On Thu, Nov 30, 2017 at 7:36 PM, Romeo Czumbil wrote: > > So do we have any Arista L3 people out here that can share some negatives or positives? We're using the Arista 7280R with Jericho(+) chips as PE routers. We're happy with them. Stable operation, no serious issues so far. Feature wise they're still behind the traditional vendors. Some limitations which come to mind: - reverse path filtering - prefix lists are limited to 65k entries - unexpected behaviour with route-map community add/delete (it's not possible to add a community which would be delted by a previous term) - VRF/MPLS/VPLS support is very basic - no support for unnumbered interfaces - no BGP flowspec - no BGP large communities - no subinterfaces On the other hand all of the above (except unnumbered interfaces) are already on their 2018 road map. Traditionally they focused on their data center customers. But more and more (big) carriers are pushing Arista for the corresponding features needed by carriers. From owen at delong.com Fri Dec 1 17:12:10 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Dec 2017 09:12:10 -0800 Subject: WiFi - login page redirection not working In-Reply-To: <871skeod7s.fsf@luffy.cx> References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> <98ae50fd-dda4-febe-5120-7585847dac2a@nvcube.net> <871skeod7s.fsf@luffy.cx> Message-ID: <0BFF9277-D9E0-4196-A853-66AAE84CF776@delong.com> > On Dec 1, 2017, at 04:16 , Vincent Bernat wrote: > > ❦ 1 décembre 2017 15:02 +0300, Nikolay Shopik : > >>> DHCP and neighbor discovery can also provide the information of the >>> login page: https://tools.ietf.org/html/rfc7710 >> >> I don't think it got support in any os. > > It's supported on Linux by Network Manager. Oh, you mean the first software anyone with clue turns off as soon as they can because of all the problems it causes for networking? Owen From nanog at ics-il.net Fri Dec 1 17:11:50 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 1 Dec 2017 11:11:50 -0600 (CST) Subject: CenturyLink (former MFON) OSP Contact In-Reply-To: <1449471900.6824.1512147088630.JavaMail.mhammett@ThunderFuck> Message-ID: <647467666.6847.1512148306971.JavaMail.mhammett@ThunderFuck> I'm looking for a contact at CenturyLink knowledgeable on one of their routes that originally was built by Midwest Fiber Optic Networks (was a part of LightCore's network). I got conflicting stories from a sales engineer as to the status on the route. We may have better options elsewhere, but I wanted to make sure I explored all options thoroughly. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From cscora at apnic.net Fri Dec 1 18:02:55 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Dec 2017 04:02:55 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171201180255.B07B6B3E2@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Dec, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 672139 Prefixes after maximum aggregation (per Origin AS): 261947 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 325805 Total ASes present in the Internet Routing Table: 59187 Prefixes per ASN: 11.36 Origin-only ASes present in the Internet Routing Table: 51121 Origin ASes announcing only one prefix: 22517 Transit ASes present in the Internet Routing Table: 8066 Transit-only ASes present in the Internet Routing Table: 238 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 23679) 26 Prefixes from unregistered ASNs in the Routing Table: 85 Number of instances of unregistered ASNs: 85 Number of 32-bit ASNs allocated by the RIRs: 20763 Number of 32-bit ASNs visible in the Routing Table: 16600 Prefixes from 32-bit ASNs in the Routing Table: 68130 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 327 Number of addresses announced to Internet: 2861310370 Equivalent to 170 /8s, 140 /16s and 33 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 222321 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184628 Total APNIC prefixes after maximum aggregation: 53090 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 183767 Unique aggregates announced from the APNIC address blocks: 77055 APNIC Region origin ASes present in the Internet Routing Table: 8496 APNIC Prefixes per ASN: 21.63 APNIC Region origin ASes announcing only one prefix: 2393 APNIC Region transit ASes present in the Internet Routing Table: 1231 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 42 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3373 Number of APNIC addresses announced to Internet: 767131170 Equivalent to 45 /8s, 185 /16s and 126 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 201468 Total ARIN prefixes after maximum aggregation: 97048 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 202861 Unique aggregates announced from the ARIN address blocks: 94992 ARIN Region origin ASes present in the Internet Routing Table: 18034 ARIN Prefixes per ASN: 11.25 ARIN Region origin ASes announcing only one prefix: 6676 ARIN Region transit ASes present in the Internet Routing Table: 1784 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2263 Number of ARIN addresses announced to Internet: 1112764192 Equivalent to 66 /8s, 83 /16s and 111 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 181131 Total RIPE prefixes after maximum aggregation: 88587 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 177042 Unique aggregates announced from the RIPE address blocks: 106948 RIPE Region origin ASes present in the Internet Routing Table: 24674 RIPE Prefixes per ASN: 7.18 RIPE Region origin ASes announcing only one prefix: 11273 RIPE Region transit ASes present in the Internet Routing Table: 3496 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6443 Number of RIPE addresses announced to Internet: 713373312 Equivalent to 42 /8s, 133 /16s and 54 /24s 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, 64396-64495 196608-207259 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: 86955 Total LACNIC prefixes after maximum aggregation: 19251 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 88230 Unique aggregates announced from the LACNIC address blocks: 39399 LACNIC Region origin ASes present in the Internet Routing Table: 6620 LACNIC Prefixes per ASN: 13.33 LACNIC Region origin ASes announcing only one prefix: 1819 LACNIC Region transit ASes present in the Internet Routing Table: 1217 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4146 Number of LACNIC addresses announced to Internet: 172636640 Equivalent to 10 /8s, 74 /16s and 57 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17870 Total AfriNIC prefixes after maximum aggregation: 3909 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 19912 Unique aggregates announced from the AfriNIC address blocks: 7142 AfriNIC Region origin ASes present in the Internet Routing Table: 1098 AfriNIC Prefixes per ASN: 18.13 AfriNIC Region origin ASes announcing only one prefix: 355 AfriNIC Region transit ASes present in the Internet Routing Table: 218 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 375 Number of AfriNIC addresses announced to Internet: 95019008 Equivalent to 5 /8s, 169 /16s and 224 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5397 4192 75 ERX-CERNET-BKB China Education and Rese 7545 4067 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2786 11128 757 KIXS-AS-KR Korea Telecom, KR 17974 2778 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2763 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2415 1521 159 VNPT-AS-VN VNPT Corp, VN 7552 2356 1158 55 VIETEL-AS-AP Viettel Group, VN 9394 2168 4931 26 CTTNET China TieTong Telecommunications 4755 2083 421 211 TATACOMM-AS TATA Communications formerl 9808 2068 8699 32 CMNET-GD Guangdong Mobile Communication 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 6327 3340 1323 87 SHAW - Shaw Communications Inc., CA 22773 3303 2951 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2171 405 107 MEGAPATH5-US - MegaPath Corporation, US 20115 2057 2290 455 CHARTER-NET-HKY-NC - Charter Communicat 6389 2012 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 16509 1944 4076 586 AMAZON-02 - Amazon.com, Inc., US 209 1929 5062 646 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1858 331 250 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1686 234 570 CABLEONE - CABLE ONE, INC., US 701 1547 10589 625 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3134 170 23 ALJAWWALSTC-AS, SA 20940 2856 852 2061 AKAMAI-ASN1, US 8551 2493 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2062 1795 695 ROSTELECOM-AS, RU 34984 2059 330 433 TELLCOM-AS, TR 12479 1939 1069 124 UNI2-AS, ES 9121 1875 1691 18 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1221 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 3645 3465 599 Uninet S.A. de C.V., MX 10620 3557 539 276 Telmex Colombia S.A., CO 11830 2647 370 66 Instituto Costarricense de Electricidad 6503 1625 437 53 Axtel, S.A.B. de C.V., MX 7303 1494 1021 195 Telecom Argentina S.A., AR 6147 1222 377 27 Telefonica del Peru S.A.A., PE 3816 1034 512 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1013 2248 191 CLARO S.A., BR 11172 914 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1212 398 48 LINKdotNET-AS, EG 37611 806 91 8 Afrihost, ZA 36903 737 370 135 MT-MPLS, MA 36992 679 1383 31 ETISALAT-MISR, EG 8452 534 1730 17 TE-AS TE-AS, EG 24835 466 850 15 RAYA-AS, EG 29571 435 36 10 CITelecom-AS, CI 37492 425 367 77 ORANGE-, TN 37342 356 32 1 MOVITEL, MZ 15399 349 35 7 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5397 4192 75 ERX-CERNET-BKB China Education and Rese 7545 4067 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 3645 3465 599 Uninet S.A. de C.V., MX 10620 3557 539 276 Telmex Colombia S.A., CO 6327 3340 1323 87 SHAW - Shaw Communications Inc., CA 22773 3303 2951 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 39891 3134 170 23 ALJAWWALSTC-AS, SA 20940 2856 852 2061 AKAMAI-ASN1, US 4766 2786 11128 757 KIXS-AS-KR Korea Telecom, KR 17974 2778 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4067 3659 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3557 3281 Telmex Colombia S.A., CO 6327 3340 3253 SHAW - Shaw Communications Inc., CA 22773 3303 3156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 3134 3111 ALJAWWALSTC-AS, SA 8151 3645 3046 Uninet S.A. de C.V., MX 17974 2778 2702 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2647 2581 Instituto Costarricense de Electricidad y Telec 8551 2493 2451 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2356 2301 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64710 PRIVATE 39.134.26.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.28.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.30.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.31.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.20.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.22.0/24 56042 CMNET-SHANXI-AP China Mobile c 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:285 /13:550 /14:1063 /15:1858 /16:13342 /17:7757 /18:13622 /19:25209 /20:38934 /21:43959 /22:81721 /23:66497 /24:374918 /25:838 /26:621 /27:657 /28:36 /29:21 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3132 3340 SHAW - Shaw Communications Inc., CA 39891 2562 3134 ALJAWWALSTC-AS, SA 22773 2546 3303 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2066 2171 MEGAPATH5-US - MegaPath Corporation, US 11830 1991 2647 Instituto Costarricense de Electricidad y Telec 8551 1957 2493 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1625 1858 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1550 3557 Telmex Colombia S.A., CO 11492 1499 1686 CABLEONE - CABLE ONE, INC., US 34984 1367 2059 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1569 2:818 4:18 5:2605 6:38 8:1078 9:1 12:1849 13:181 14:1741 15:29 16:3 17:185 18:76 20:53 21:1 23:2454 24:1926 25:2 27:2349 31:1961 32:87 35:21 36:449 37:2442 38:1440 39:88 40:100 41:3031 42:524 43:1949 44:83 45:3361 46:2853 47:186 49:1369 50:1040 51:34 52:903 54:354 55:6 56:4 57:42 58:1573 59:996 60:373 61:1997 62:1782 63:1838 64:4605 65:2241 66:4503 67:2293 68:1193 69:3173 70:1134 71:588 72:2096 74:2676 75:390 76:424 77:1545 78:1560 79:1887 80:1442 81:1411 82:1067 83:754 84:998 85:1934 86:484 87:1229 88:904 89:2300 90:174 91:6246 92:1032 93:2093 94:2411 95:2704 96:666 97:351 98:950 99:103 100:153 101:1477 102:1 103:16277 104:3191 105:209 106:517 107:1776 108:814 109:2935 110:1509 111:1730 112:1270 113:1372 114:1071 115:1605 116:1693 117:1625 118:2162 119:1650 120:732 121:1059 122:2401 123:1910 124:1477 125:1825 128:946 129:567 130:442 131:1551 132:599 133:194 134:957 135:228 136:445 137:467 138:1956 139:547 140:381 141:677 142:761 143:947 144:795 145:193 146:1126 147:695 148:1544 149:621 150:711 151:1005 152:731 153:303 154:957 155:740 156:740 157:754 158:593 159:1616 160:817 161:733 162:2541 163:531 164:939 165:1476 166:392 167:1338 168:3121 169:817 170:3553 171:401 172:1018 173:1893 174:836 175:766 176:1887 177:4014 178:2499 179:1148 180:2235 181:2109 182:2403 183:813 184:887 185:11618 186:3356 187:2339 188:2591 189:1975 190:8190 191:1339 192:9701 193:5866 194:4759 195:3972 196:2261 197:1425 198:5551 199:5887 200:7201 201:4854 202:10422 203:9977 204:4551 205:2866 206:3072 207:3094 208:3980 209:3874 210:3975 211:2076 212:2893 213:2599 214:868 215:65 216:5729 217:2098 218:889 219:628 220:1681 221:938 222:734 223:1204 End of report From steve at blighty.com Fri Dec 1 18:09:00 2017 From: steve at blighty.com (Steve Atkins) Date: Fri, 1 Dec 2017 10:09:00 -0800 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <20171201101637.e42dwc3bcprkzh3j@nbmacvieebi.local> References: <20171130200748.GC42601@vurt.meerval.net> <20171130202734.GA95926@vurt.meerval.net> <41359467-1b27-9411-ad43-6e4714f59c41@studio442.com.au> <20171201101637.e42dwc3bcprkzh3j@nbmacvieebi.local> Message-ID: <1DDC4AED-00EC-4C85-912E-CF7D38842FDB@blighty.com> > On Dec 1, 2017, at 2:16 AM, Elmar K. Bins wrote: > > nanog at studio442.com.au (Julien Goodwin) wrote: > >>> The first optimisation is to remove any supplied prefixes which are >>> superfluous because they are already included in another supplied >>> prefix. For example, 2001:67c:208c:10::/64 would be removed if >>> 2001:67c:208c::/48 was also supplied. >>> >>> The second optimisation identifies adjacent prefixes that can be >>> combined under a single, shorter-length prefix. For example, >>> 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the >>> single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and >>> 10.0.1.0/24 can be joined into 10.0.0.0/23. >> >> Will it catch cases like: >> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22 > > I guess the developers will have implemented a loop that runs until no > more optimizations have been found. Which would of course catch it as > > Iteration 1 > 10.0.0.0/24 + 10.0.1.0/24 > -> 10.0.0.0/23 > > Iteration 2 > 10.0.0.0/23 + 10.0.2.0/23 > -> 10.0.0.0/22 > The usual trick is to build a prefix tree then walk the tree, which catches this sort of case in one step. Cheers, Steve From ryan at finnesey.com Fri Dec 1 18:24:51 2017 From: ryan at finnesey.com (Ryan Finnesey) Date: Fri, 1 Dec 2017 18:24:51 +0000 Subject: ccTLDs - Become a Registrar Message-ID: I was wonder if anyone within the group has done this research and might be able to save me a bit of time. I am in the process of putting together a new Registrar and we would like complete ccTLD coverage. I know for example CIRA (.ca) has a Canadian Presence Requirement and we have formed a Canadian Corporation to meet this requirement. I am hoping to find what other TLD operators may have similar requirements. Cheers Ryan From buraglio at es.net Fri Dec 1 16:33:10 2017 From: buraglio at es.net (Nicholas Buraglio) Date: Fri, 1 Dec 2017 10:33:10 -0600 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: While I am personally a fan of mikrotik for their ridiculously inexpensive MPLS features, their total and complete lack of ISIS is a show stopper in a lot of cases (and makes me sad) and their v6 support is mostly-ok-but-still-wonky(which also makes me sad) - and ROS 7 has been "coming soon" in the same way that Apple has been "going out of business" for 30 years. The Arista 7500R series has a lot of promise from a service provider perspective, but the MPLS stack is still under heavy development, but what's actually there has been solid. What I do like about their gear is what has typically been true of younger vendors: they listen and implement. Like Frederik stated, their roadmap is impressively full and my experience has been that they deliver on their roadmap since it's completely customer driven. For complicated SPs with lots of RSVP-TE, segment routing, complex route leaking and other multi-tenant features it may or may not be ready yet but it's getting pretty close. Interface buffers and other SP specific things are there based on their chipsets, which is encouraging, and on paper their programmability is near the top of the heap, especially if you're using something like Ansible or other access to eAPI (FWIW, we've been testing some of the programmability on smaller Arista for a bit and are so far no issues). nb ᐧ --- Nick Buraglio Energy Sciences Network; AS293 Lawrence Berkeley National Laboratory buraglio at es.net +1 (510) 995-6068 On Fri, Dec 1, 2017 at 9:59 AM, Frederik Kriewitz wrote: > On Thu, Nov 30, 2017 at 7:36 PM, Romeo Czumbil < > Romeo.Czumbil at tierpoint.com> > wrote: > > > > So do we have any Arista L3 people out here that can share some negatives > or positives? > > We're using the Arista 7280R with Jericho(+) chips as PE routers. > We're happy with them. > Stable operation, no serious issues so far. > > Feature wise they're still behind the traditional vendors. > Some limitations which come to mind: > - reverse path filtering > - prefix lists are limited to 65k entries > - unexpected behaviour with route-map community add/delete (it's not > possible to add a community which would be delted by a previous term) > - VRF/MPLS/VPLS support is very basic > - no support for unnumbered interfaces > - no BGP flowspec > - no BGP large communities > - no subinterfaces > > On the other hand all of the above (except unnumbered interfaces) are > already on their 2018 road map. > Traditionally they focused on their data center customers. > But more and more (big) carriers are pushing Arista for the corresponding > features needed by carriers. > From michael.d.morrison at me.com Fri Dec 1 16:36:23 2017 From: michael.d.morrison at me.com (Michael Morrison) Date: Fri, 01 Dec 2017 08:36:23 -0800 Subject: CenturyLink VoIP Message-ID: <2FB53311-A3BE-4995-BFF2-02550A6124A0@me.com> Need to get ahold of a CTL VoIP tech, Phone queues seem to be down. Any Help is appreciated. From sheshkaoss at gmail.com Fri Dec 1 17:35:13 2017 From: sheshkaoss at gmail.com (Aliaksei Sheshka) Date: Fri, 1 Dec 2017 12:35:13 -0500 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <20171130200748.GC42601@vurt.meerval.net> References: <20171130200748.GC42601@vurt.meerval.net> Message-ID: On Thu, Nov 30, 2017 at 3:07 PM, Job Snijders wrote: > Dear NANOG, > > I re-implemented the venerable 'aggregate' tool (by Joe Abley & co) in > python under the name of 'aggregate6'. The 'aggregate6' tool is faster > and also has IPv6 support. > > https://github.com/job/aggregate6 > Nice! "-t" from the "classic" IPv4 "aggregate" would be nice. I've sent a pull request. From bryonadams at fastmail.com Fri Dec 1 17:38:30 2017 From: bryonadams at fastmail.com (Bryon Adams) Date: Fri, 01 Dec 2017 09:38:30 -0800 Subject: Fibertech / Lightower Contact? Message-ID: <1512149910.3168022.1190916384.58B6E1A8@webmail.messagingengine.com> Anyone know if they're having trouble? I can't seem to get through to their NOC using a pair of toll frees I have or any of the individual contacts we have numbers for. If someone from there can contact me off list, I just need some info for a new turnup (vlan, port on CPE, etc). -- Bryon Adams bryonadams at fastmail.com From rubensk at gmail.com Fri Dec 1 18:45:37 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 1 Dec 2017 16:45:37 -0200 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: On Fri, Dec 1, 2017 at 4:24 PM, Ryan Finnesey wrote: > I was wonder if anyone within the group has done this research and might > be able to save me a bit of time. I am in the process of putting together > a new Registrar and we would like complete ccTLD coverage. I know for > example CIRA (.ca) has a Canadian Presence Requirement and we have formed > a Canadian Corporation to meet this requirement. > > I am hoping to find what other TLD operators may have similar requirements. > .br also has such requirements. OpenSRS reference chart has a good hint of which ccTLDs have such requirements: http://bit.ly/OpenSRS_TLD_Reference_Chart While it details the registration requirements, usually they are aligned: most ccTLDs that are restricted to local residents also restrict registrars to be locally incorporated. Rubens From michael.d.morrison at me.com Fri Dec 1 18:49:26 2017 From: michael.d.morrison at me.com (Michael Morrison) Date: Fri, 01 Dec 2017 10:49:26 -0800 Subject: CenturyLink VoIP In-Reply-To: <2FB53311-A3BE-4995-BFF2-02550A6124A0@me.com> References: <2FB53311-A3BE-4995-BFF2-02550A6124A0@me.com> Message-ID: <2EBD421D-1A5D-4FA8-A243-CF03F407C583@me.com> It appears there is a major outage in the CenturyLink Network for voip customers, potentially on the SS7 side of the network. Nothing has been confirmed except certain CenturyLink reps have informed me that everything West of Colorado is down. I know this to be true for 3 of my sites, LAX, SFO, and SEA. > On Dec 1, 2017, at 8:36 AM, Michael Morrison wrote: > > Need to get ahold of a CTL VoIP tech, > > Phone queues seem to be down. Any Help is appreciated. > > From morrowc.lists at gmail.com Fri Dec 1 19:20:29 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Dec 2017 14:20:29 -0500 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl wrote: > > .br also has such requirements. OpenSRS reference chart has a good hint of > which ccTLDs have such requirements: > http://bit.ly/OpenSRS_TLD_Reference_Chart wow, 256 of 539 report "no" for DNSSEC. From sthaug at nethelp.no Fri Dec 1 19:25:16 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 01 Dec 2017 20:25:16 +0100 (CET) Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: <20171201.202516.41639812.sthaug@nethelp.no> > > I am hoping to find what other TLD operators may have similar requirements. > > > > .br also has such requirements. OpenSRS reference chart has a good hint of > which ccTLDs have such requirements: > http://bit.ly/OpenSRS_TLD_Reference_Chart It might be advisable to verify the data. For instance, the chart claims no DNSSEC for .no (Norway) - but in reality, .no has been offering DNSSEC since 2014, https://www.norid.no/en/registrar/system/videreutvikling/dnssec/omdnssec/ and about 58% of .no domains use DNSSEC - see graph on the right hand side of https://www.norid.no/en/ Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rubensk at gmail.com Fri Dec 1 19:35:25 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 1 Dec 2017 17:35:25 -0200 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow wrote: > > > On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl wrote: > >> >> .br also has such requirements. OpenSRS reference chart has a good hint of >> which ccTLDs have such requirements: >> http://bit.ly/OpenSRS_TLD_Reference_Chart > > > wow, 256 of 539 report "no" for DNSSEC. > For DNSSEC this one is more reliable: http://rick.eng.br/mon/ Rubens From rubensk at gmail.com Fri Dec 1 19:36:17 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 1 Dec 2017 17:36:17 -0200 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: http://rick.eng.br/dnssecstat/ is more on topic of we what discussing, although the monitor is interesting too. Rubens On Fri, Dec 1, 2017 at 5:35 PM, Rubens Kuhl wrote: > > > On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> >> >> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl wrote: >> >>> >>> .br also has such requirements. OpenSRS reference chart has a good hint >>> of >>> which ccTLDs have such requirements: >>> http://bit.ly/OpenSRS_TLD_Reference_Chart >> >> >> wow, 256 of 539 report "no" for DNSSEC. >> > > For DNSSEC this one is more reliable: > http://rick.eng.br/mon/ > > > Rubens > > > From Jacques.Latour at cira.ca Fri Dec 1 19:51:07 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Fri, 1 Dec 2017 19:51:07 +0000 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: <9891c951f0e14791b848617c39496244@cira.ca> That's why we're working on DNSSEC automation, to let the DNS Operator sign the zone and automate the provisioning of DS record into the registry without registrant or registrar intervention. Multiple methods and approach being work on. API for DNS Operator: https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-04 Registry full zone polling: https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/ Jacques -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rubens Kuhl Sent: December 1, 2017 2:36 PM To: Christopher Morrow Cc: nanog at nanog.org Subject: Re: ccTLDs - Become a Registrar http://rick.eng.br/dnssecstat/ is more on topic of we what discussing, although the monitor is interesting too. Rubens On Fri, Dec 1, 2017 at 5:35 PM, Rubens Kuhl wrote: > > > On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> >> >> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl wrote: >> >>> >>> .br also has such requirements. OpenSRS reference chart has a good hint >>> of >>> which ccTLDs have such requirements: >>> http://bit.ly/OpenSRS_TLD_Reference_Chart >> >> >> wow, 256 of 539 report "no" for DNSSEC. >> > > For DNSSEC this one is more reliable: > http://rick.eng.br/mon/ > > > Rubens > > > From marco-nanog at prause.eu Fri Dec 1 19:38:17 2017 From: marco-nanog at prause.eu (Marco Prause) Date: Fri, 01 Dec 2017 20:38:17 +0100 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: <9A55FC71-7C3E-4DB4-9603-919D64603DDF@prause.eu> >wow, 256 of 539 report "no" for DNSSEC. Having a look at the link, it seems it's representing the options of the opensrs system and not necessarily the options of the registry. For .de e.g. the registry DENIC provides DNSSEC. Just my 2 Cent, Marco From jmcc at hackwatch.com Fri Dec 1 20:31:40 2017 From: jmcc at hackwatch.com (John McCormac) Date: Fri, 1 Dec 2017 20:31:40 +0000 Subject: ccTLDs - Become a Registrar In-Reply-To: References: Message-ID: On 01/12/2017 18:24, Ryan Finnesey wrote: > I was wonder if anyone within the group has done this research and might be able to save me a bit of time. I am in the process of putting together a new Registrar and we would like complete ccTLD coverage. I know for example CIRA (.ca) has a Canadian Presence Requirement and we have formed a Canadian Corporation to meet this requirement. > > I am hoping to find what other TLD operators may have similar requirements. Some have due diligence checks for finance and trade references. However, covering all ccTLDs may not be feasible as some of the smaller ones (<10K registrations) may still use manual processing of applications. From what I remember, some of the EU registries may have liberalised and a point of presence company/corporation within the EU or even a US/Canadian company might be sufficient. The real issue with ccTLDs for end users will be sorting out the requirements for registration. Some ccTLDs like .UK or .ME may have relatively liberal/open registration requirements for their most popular subdomains (e.g .CO.UK) but have, in the case of .UK, different requirements for registering at .UK level. The .EU nominally requires registrants to be within or connected to the EU or European Economic Area. The .DE ccTLD requires a German point of contact for registrations but that might be handled by forming a local company. The main ccTLDs for any new registar venture would be the ones with a liberal registration policy. The more restrictive ones might require a lot more handholding and paperwork for the registrants and unless your new registrar venture is concentrating on brand protection registrations, it might be best to steer clear of these initially. Most ccTLD markets are heavily dominated by in-country registrars and they can be quite difficult for a foreign registrar to gain market share. They also have very different dynamics to the legacy TLDs like COM/NET/ORG and the gTLDs. The one year renewal rates for some of them can be 70% or higher. Web usage also tends to be higher for some ccTLDs so a registrant buying a domain name/hosting package is somewhat more likely to use that hosting. In a ccTLDs Web Usage Survey I ran last month, the Content/No Content rate (the totals of (domain names with developed content) / (domain names on holding pages/PPC/sales/unavailable/no website) ) for .DE ccTLD was 0.92, .ES was 0.48, .EU was 0.37, .FR was 0.58, .UK was 0.39 and .US was 0.13. These are based on random 110,000 domain name samples. It is simpler to express this as a kind of development rate as the surveys have approximately 28 categories of usage. The development rate excludes redirects as it is a simple content related metric. In some markets, the local ccTLD dominates the market and the COM/NET/ORG and gTLDs have gone legacy. The main TLD pair for most developed markets will be the ccTLD/COM. The NET and ORG generally tend to be legacy TLDs rather than attracting high volumes of new registrations in these countries. While you may not be concentrating on the new gTLDs, if you are targeting markets with a strong ccTLD, also consider the new gTLD geo TLD if it is applicable. (.IRISH for Ireland, .LONDON, .SCOT, .CYMRU, .WALES for the UK, .BERLIN, .RUHR etc for Germany, .RIO for Brazil, .NYC, .VEGAS, .MIAMI for the US etc.) Many of these are early stage TLDs (low registration volume and relatively low use but that's typical for new gTLDs as some of these seem to be following a ccTLD development curve rather than a gTLD development curve) but they tend to be different from less precisely targeted new gTLDs. Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc at hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * And Historical DNS Database. Ireland * Over 516 Million Domains Tracked. IE * Skype: hosterstats.com ********************************************************** From job at ntt.net Fri Dec 1 20:42:10 2017 From: job at ntt.net (Job Snijders) Date: Fri, 1 Dec 2017 20:42:10 +0000 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: References: <20171130200748.GC42601@vurt.meerval.net> Message-ID: <20171201204210.GA13959@vurt.meerval.net> On Fri, Dec 01, 2017 at 12:35:13PM -0500, Aliaksei Sheshka wrote: > On Thu, Nov 30, 2017 at 3:07 PM, Job Snijders wrote: > > I re-implemented the venerable 'aggregate' tool (by Joe Abley & co) > > in python under the name of 'aggregate6'. The 'aggregate6' tool is > > faster and also has IPv6 support. > > > > https://github.com/job/aggregate6 > > Nice! > "-t" from the "classic" IPv4 "aggregate" would be nice. I've sent a > pull request. That's best approach to get things done: make suggestions and submit patches. Thank you! Kind regards, Job From mmethw2003 at gmail.com Sat Dec 2 04:51:45 2017 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Sat, 2 Dec 2017 10:21:45 +0530 Subject: OSPF Monitoring Tool Message-ID: Hi Guys, Is anyone knows about a Monitoring tool for OSPF ?? ~~( ŊëŌ )~~ From gtaylor at tnetconsulting.net Sat Dec 2 07:18:17 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 2 Dec 2017 00:18:17 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171201014747.25961.qmail@ary.lan> <0410015a-acae-1fa2-8bfb-acc92a652357@tnetconsulting.net> Message-ID: <6134b4a7-9da8-2935-e9f6-e4374b3fdba4@spamtrap.tnetconsulting.net> On 11/30/2017 07:38 PM, John R. Levine wrote: > I did a draft of a double signing thing that let the sender say who's > expected to sign a modified forwarded version.  The big mail systems > weren't interested.  They want the recipient system to decide. > > https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Okay, I've now read your draft and have some questions. How would the !fs tag enable multiple forwarders? The only way that I can think of is for the originating mail server to DKIM sign the message twice, 1st with the classic DKIM-Signature w/o the !fs tag, and 2nd with a DKIM-Signature that includes the !fs tag with a value of of the recipient's domain. I would assume that would mean that the recipient could then forward the message to a new recipient and that their outgoing mail server would also sign twice, 1st with classic DKIM-Signature w/o the !fs tag, and 2nd with a DKIM-Signature that includes the !fs tag with a value of the new recipient's domain. A1: DKIM-Signature: ... d=domainA.example ... A2: DKIM-Signature: ... d=domainA.example; !fs=domainB.example ... <1st forward> B1: DKIM-Signature: ... d=domainB.example ... B2: DKIM-Signature: ... d=domainB.example; !fs=domainC.example ... <2nd forward> C1: DKIM-Signature: ... d=domainC.example ... C2: DKIM-Signature: ... d=domainC.example; !fs=domainD.example ... <3rd forward> D1: DKIM-Signature: ... d=domainD.example ... D2: DKIM-Signature: ... d=domainD.example; !fs=domainE.example ... <4th forward> E1: DKIM-Signature: ... d=domainE.example ... E2: DKIM-Signature: ... d=domainE.example; !fs=domainF.example ... (I suppose that this pattern could go on forever.) Is this what you were intending? A list of DKIM-Signatures linked via !fs tags? If I do understand correctly, I think that it's intriguing. I'm not aware of anything else that would work quite the same way. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From alan.buxey at gmail.com Sat Dec 2 16:26:29 2017 From: alan.buxey at gmail.com (Alan Buxey) Date: Sat, 2 Dec 2017 16:26:29 +0000 Subject: OSPF Monitoring Tool In-Reply-To: References: Message-ID: Commercial, or free? For commercial route explorer should do the job, for free, run eg quagga or such with relevant actions on logs. alan From EPers at ansencorp.com Sat Dec 2 19:18:00 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Sat, 2 Dec 2017 19:18:00 +0000 Subject: OSPF Monitoring Tool In-Reply-To: References: Message-ID: <95c031a871bc41e7b970c8742f17d6d5@ansencorp.com> I've used librenms and pandorafms for this, librenms is less setup but Pandora is more comprehensive -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Methsri Wickramarathna Sent: Friday, December 1, 2017 11:52 PM To: nanog at nanog.org Subject: OSPF Monitoring Tool Hi Guys, Is anyone knows about a Monitoring tool for OSPF ?? ~~( ŊëŌ )~~ From johnl at iecc.com Sat Dec 2 19:51:16 2017 From: johnl at iecc.com (John R. Levine) Date: 2 Dec 2017 14:51:16 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM (fwd) Message-ID: In article <6134b4a7-9da8-2935-e9f6-e4374b3fdba4 at spamtrap.tnetconsulting.net>, Grant Taylor via NANOG wrote: >> https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ >The only way that I can think of is for the originating mail server to >DKIM sign the message twice, 1st with the classic DKIM-Signature w/o the >!fs tag, and 2nd with a DKIM-Signature that includes the !fs tag with a >value of of the recipient's domain. >Is this what you were intending? A list of DKIM-Signatures linked via >!fs tags? Yup, with the chain typically having no more than one or two links, since legit forwarding of the kind that might break DKIM is pretty rare more than two deep. >If I do understand correctly, I think that it's intriguing. I'm not >aware of anything else that would work quite the same way. That was the plan. I thought it was pretty clever, but like I said, the large mail systems that developed ARC wanted to put the control with the recipients, not the senders. R's, John From michael at wadadli.me Sat Dec 2 18:35:07 2017 From: michael at wadadli.me (Michael S. Singh) Date: Sat, 2 Dec 2017 10:35:07 -0800 Subject: Suggestions for a more privacy conscious email provider Message-ID: Hi all, I am in need of some suggestions for some privacy conscious email providers. I am currently using Migadu email hosting from Switzerland, basically they allow their users to have as many domains and mailboxes without storage limits without extra cost. However they only allow 10 messages to be sent per day on their free tier. -- Sincerely Michael S Singh, M: 914-266-0601 W: www.wadadli.me F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- A non-text attachment was scrubbed... Name: michael.vcf Type: text/x-vcard Size: 434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Sat Dec 2 22:03:31 2017 From: bill at herrin.us (William Herrin) Date: Sat, 2 Dec 2017 17:03:31 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh wrote: > I am in need of some suggestions for some privacy conscious email > providers. I am currently using Migadu [...] > However they only allow 10 messages to be sent per day on their free tier. If you aren't paying for it and it's not a demo meant to get you to pay for it then you're not the customer, you're the product. If you're the product, guess what the customer is paying for. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From fergdawgster at mykolab.com Sat Dec 2 22:20:55 2017 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sat, 2 Dec 2017 14:20:55 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh wrote: > I am in need of some suggestions for some privacy conscious email > providers. I am currently using Migadu [...] I use KolabNow, based in Switzerland, for a lot of personal e-mail communications. They are very, very privacy conscious: - --> https://kolabnow.com/feature/confidence They are *not* free, but quite reasonable, and I am quite happy with the m. - - ferg - -- Paul Ferguson ICEBRG.io, Seattle USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlojJ0cACgkQKJasdVTchbLl5AD/QTSs+qOHuwKIyiBVYgmGR9MQ N8pz3AJ3pyks/IxLxIgA/jNhyl0Dlg97wNiitZm9sAjaxLA7xIPRDACHQICnNSbJ =LCAZ -----END PGP SIGNATURE----- From ryangard at gmail.com Sat Dec 2 22:39:50 2017 From: ryangard at gmail.com (Ryan Gard) Date: Sat, 2 Dec 2017 17:39:50 -0500 Subject: Ticketmaster? Message-ID: Can somebody from ticketmaster contact me off list? These arbitrary blocks are getting ridiculous, and we continue to field a large number of customer complaints from this. Also not impressed with front end customer support continuing to lay blame at the service provider's feet and spread misinformation to end users so they walk away washing their hands for a situation created by ticketmaster (*Oh, you must be sharing your IP with everyone else in your area*) Secondly, if anybody's had luck actually waking somebody up with some sort of sway or pull at ticketmaster, shoot me a line off list if you could. I'd be eternally grateful. Thanks! -- Ryan Gard From eric-list at truenet.com Sun Dec 3 00:43:08 2017 From: eric-list at truenet.com (Eric Tykwinski) Date: Sat, 2 Dec 2017 19:43:08 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: Sort of a side note, but has anyone played with a Magma server? Ladar Levison’s project to create a totally encryption email system. I donated a bit, but have yet found time to beta test anything. Just looking for pro’s/con’s and if it’s even worth spending the time. https://darkmail.info/ > > On Dec 2, 2017, at 1:35 PM, Michael S. Singh wrote: > > Hi all, > > I am in need of some suggestions for some privacy conscious email > providers. I am currently using Migadu email hosting from Switzerland, > basically they allow their users to have as many domains and mailboxes > without storage limits without extra cost. > > However they only allow 10 messages to be sent per day on their free tier. > > -- > Sincerely Michael S Singh, > M: 914-266-0601 > W: www.wadadli.me > F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 > > > > Sent via Migadu.com, world's easiest email hosting > From surfer at mauigateway.com Sun Dec 3 02:41:55 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 2 Dec 2017 18:41:55 -0800 Subject: OSPF Monitoring Tool Message-ID: <20171202184155.E3B7E45@m0117458.ppops.net> --- mmethw2003 at gmail.com wrote: From: Methsri Wickramarathna Is anyone knows about a Monitoring tool for OSPF ?? -------------------------------------- Use SNMP and any graphing tool (such as Cacti, if you don't need to scale to a large size) Some SNMP OIDs: ospfNbrHelloSuppressed 1.3.6.1.2.1.14.10.1.11 ospfNbrState 1.3.6.1.2.1.14.10.1.6 ospfAreaLsaCount 1.3.6.1.2.1.14.2.1.7 ospfLsdbAdvertisement 1.3.6.1.2.1.14.4.1.8 and whatever else you want to monitor. scott From cjwolff at nola.gov Sun Dec 3 14:39:27 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Sun, 3 Dec 2017 14:39:27 +0000 Subject: Alternatives to ISE? Message-ID: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> I've about reached my limit with the dumpster fire that is Cisco's Identity Service Engine. Are there any reliable alternatives that do endpoint classification, central web auth, and .1x auth? Thanks in advance, Christopher From michaelolusegunrufai at gmail.com Sun Dec 3 14:48:29 2017 From: michaelolusegunrufai at gmail.com (segs) Date: Sun, 3 Dec 2017 15:48:29 +0100 Subject: Alternatives to ISE? In-Reply-To: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> Message-ID: Forescout but if you want something simpler with SNMP authentication of switches and Domain Controller of authorized PCs you can have a look at Portnox. Done couple of deployments with Portnox. On Sun, Dec 3, 2017 at 3:39 PM, Christopher J. Wolff wrote: > I've about reached my limit with the dumpster fire that is Cisco's > Identity Service Engine. Are there any reliable alternatives that do > endpoint classification, central web auth, and .1x auth? > > Thanks in advance, > Christopher > From jean at ddostest.me Sun Dec 3 15:06:40 2017 From: jean at ddostest.me (Jean | ddostest.me) Date: Sun, 3 Dec 2017 10:06:40 -0500 Subject: Alternatives to ISE? In-Reply-To: References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> Message-ID: <5369a613-dc01-86ce-6287-a1ba4a82b68f@ddostest.me> I'm about to try this one. https://packetfence.org/ Not sure if it covers all the features you need though, but it seems promising. In case you give it a try, could you share your experience please? Thanks Jean On 17-12-03 09:48 AM, segs wrote: > Forescout but if you want something simpler with SNMP authentication of > switches and Domain Controller of authorized PCs you can have a look at > Portnox. Done couple of deployments with Portnox. > > On Sun, Dec 3, 2017 at 3:39 PM, Christopher J. Wolff > wrote: > >> I've about reached my limit with the dumpster fire that is Cisco's >> Identity Service Engine. Are there any reliable alternatives that do >> endpoint classification, central web auth, and .1x auth? >> >> Thanks in advance, >> Christopher >> From jean at ddostest.me Sun Dec 3 15:12:39 2017 From: jean at ddostest.me (Jean | ddostest.me) Date: Sun, 3 Dec 2017 10:12:39 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: If you plan to use it for a small group of people, you should consider hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6. It could be seen as a personal challenge to achieve. Then if you need real privacy, you will need to encrypt with public keys like PGP or S/MIME. You can upload your public key to the public pgp key servers. I guess that one day this thing will be very popular. Challenge accepted? Jean On 17-12-02 05:20 PM, Paul Ferguson wrote: > On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh > wrote: > >> I am in need of some suggestions for some privacy conscious email >> providers. I am currently using Migadu [...] > > I use KolabNow, based in Switzerland, for a lot of personal e-mail > communications. They are very, very privacy conscious: > > --> https://kolabnow.com/feature/confidence > > They are *not* free, but quite reasonable, and I am quite happy with the > m. > > - ferg > > > From mel at beckman.org Sun Dec 3 15:22:31 2017 From: mel at beckman.org (Mel Beckman) Date: Sun, 3 Dec 2017 15:22:31 +0000 Subject: Alternatives to ISE? In-Reply-To: <5369a613-dc01-86ce-6287-a1ba4a82b68f@ddostest.me> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> <5369a613-dc01-86ce-6287-a1ba4a82b68f@ddostest.me> Message-ID: <4D109356-8C59-4255-839F-8D7538EA0E1E@beckman.org> I’ve used PacketFence for several years, but it’s kind of fragile. Compared to many FOSS systems, it’s exceptionally well documented, and uses reasonably good Web GUI standards. It also supports Cisco switches well. However, I routinely have to twiddle with it when one or another internal components silently crashes. It’s about ads fiddly as Asterisk is for telephony: just when you think you’ve got it working, some unpredicted external event — a new device or an OS security patch — breaks it. What PF really needs is some kind of internal monitoring and notification system to let you know when and what stopped working. Various users have jury rigged their own scripts and published them, but they’re too customized to work generically for any PF installation. I’ve seen commercial NAC systems that appear to be much more reliable. Cisco’s is not among them. I haven’t taken the time to try them out yet, however. -mel > On Dec 3, 2017, at 7:06 AM, Jean | ddostest.me via NANOG wrote: > > I'm about to try this one. > > https://packetfence.org/ > > Not sure if it covers all the features you need though, but it seems > promising. In case you give it a try, could you share your experience > please? > > Thanks > Jean > > On 17-12-03 09:48 AM, segs wrote: >> Forescout but if you want something simpler with SNMP authentication of >> switches and Domain Controller of authorized PCs you can have a look at >> Portnox. Done couple of deployments with Portnox. >> >> On Sun, Dec 3, 2017 at 3:39 PM, Christopher J. Wolff >> wrote: >> >>> I've about reached my limit with the dumpster fire that is Cisco's >>> Identity Service Engine. Are there any reliable alternatives that do >>> endpoint classification, central web auth, and .1x auth? >>> >>> Thanks in advance, >>> Christopher >>> From eriks at netideainc.ca Sun Dec 3 15:36:21 2017 From: eriks at netideainc.ca (Eriks Rugelis) Date: Sun, 3 Dec 2017 10:36:21 -0500 Subject: Alternatives to ISE? In-Reply-To: <5369a613-dc01-86ce-6287-a1ba4a82b68f@ddostest.me> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> <5369a613-dc01-86ce-6287-a1ba4a82b68f@ddostest.me> Message-ID: <93F1A5A6-CE90-4C53-9A96-2BB946EC461A@netideainc.ca> $dayjob is a university where we use PacketFence to support .1x for a population of approx. 28K concurrent Wi-Fi devices. It took us a couple of iterations but we now have a clustered deployment (of VM’s) model which routinely handles >1200 logins per second, has a fair bit of headroom left over and can scale larger as required. We have been very satisfied with the responsiveness and capabilities of tech support by Inverse.ca. All this and the price point is hard to beat. I have no personal interest in Inverse other than as a satisfied customer. Our presentation on the scalable deployment model for PF may be found by searching the web for “Authentication for big Wi-Fi”. Eriks --- Eriks Rugelis Sr. Consultant Netidea Inc. T: +1.416.876.0740 > On Dec 3, 2017, at 10:06, Jean | ddostest.me via NANOG wrote: > > I'm about to try this one. > > https://packetfence.org/ > > Not sure if it covers all the features you need though, but it seems > promising. In case you give it a try, could you share your experience > please? > > Thanks > Jean > >> On 17-12-03 09:48 AM, segs wrote: >> Forescout but if you want something simpler with SNMP authentication of >> switches and Domain Controller of authorized PCs you can have a look at >> Portnox. Done couple of deployments with Portnox. >> >> On Sun, Dec 3, 2017 at 3:39 PM, Christopher J. Wolff >> wrote: >> >>> I've about reached my limit with the dumpster fire that is Cisco's >>> Identity Service Engine. Are there any reliable alternatives that do >>> endpoint classification, central web auth, and .1x auth? >>> >>> Thanks in advance, >>> Christopher >>> > From fhr at fhrnet.eu Sun Dec 3 17:08:33 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Sun, 3 Dec 2017 17:08:33 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> It's kind of a pain to manage a mail server. Even if you have SPF, DKIM correctly setup and you are not on any common blacklists, you constantly have to fight for good deliverability - some mail server solutions will simply reject you no matter what. You might be on some obscure blacklist nobody uses and then you have to waste time sending blacklist removal requests. I personally run my own mail server, but route outgoing emails via Amazon SES. Gives me all the benefits of having my own mail server (domain aliases, extensions, custom spam filter etc) and saves me from the pain of managing outgoing reputation. -- Filip Hruska Linux System Administrator Dne 12/3/17 v 16:12 Jean | ddostest.me via NANOG napsal(a): > If you plan to use it for a small group of people, you should consider > hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6. > > It could be seen as a personal challenge to achieve. > > Then if you need real privacy, you will need to encrypt with public keys > like PGP or S/MIME. You can upload your public key to the public pgp key > servers. I guess that one day this thing will be very popular. > > Challenge accepted? > > Jean > > On 17-12-02 05:20 PM, Paul Ferguson wrote: >> On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh >> wrote: >> >>> I am in need of some suggestions for some privacy conscious email >>> providers. I am currently using Migadu [...] >> I use KolabNow, based in Switzerland, for a lot of personal e-mail >> communications. They are very, very privacy conscious: >> >> --> https://kolabnow.com/feature/confidence >> >> They are *not* free, but quite reasonable, and I am quite happy with the >> m. >> >> - ferg >> >> >> From alan.buxey at gmail.com Sun Dec 3 18:49:24 2017 From: alan.buxey at gmail.com (Alan Buxey) Date: Sun, 3 Dec 2017 18:49:24 +0000 Subject: Alternatives to ISE? In-Reply-To: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> Message-ID: if you're already slurping the commercial koolaid (support contracts, someone to blame etc etc) - then Aruba Clearpass? (otherwise local homebrew with FreeRADIUS core or PacketFence as FOSSOTS ;-) ).... alan From gtaylor at tnetconsulting.net Sun Dec 3 19:31:56 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 3 Dec 2017 12:31:56 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> Message-ID: On 12/03/2017 10:08 AM, Filip Hruska wrote: > It's kind of a pain to manage a mail server. I disagree. I have been running my own mail server for > 15 years and extremely happy with it. I spend less than an hour a month needing to do things to it. Usually that's just the same type of OS updates that I do to my workstation. Having my own mail server gives me a LOT more flexibility than relying on someone else's mail server. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From royce at techsolvency.com Sun Dec 3 19:55:35 2017 From: royce at techsolvency.com (Royce Williams) Date: Sun, 3 Dec 2017 10:55:35 -0900 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> Message-ID: On Sun, Dec 3, 2017 at 10:31 AM, Grant Taylor via NANOG wrote: > On 12/03/2017 10:08 AM, Filip Hruska wrote: > >> It's kind of a pain to manage a mail server. >> > > I disagree. > > I have been running my own mail server for > 15 years and extremely happy > with it. > > I spend less than an hour a month needing to do things to it. Usually > that's just the same type of OS updates that I do to my workstation. > > Having my own mail server gives me a LOT more flexibility than relying on > someone else's mail server. For those of us who have the savvy to do so competently, sure. For others, the key word may be "provider". Setting up a Linode server on static IP space (to avoid being blacklisted), setting up greylisting, antivirus/antispam (maybe?), STARTTLS, etc. ... Maybe the OP is interested in outsourcing all of that - letting someone else stay current with patching, spammer tactics, etc. Royce From gtaylor at tnetconsulting.net Sun Dec 3 20:03:57 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 3 Dec 2017 13:03:57 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> Message-ID: <36cba900-521b-2b7b-644a-b214bae50e57@spamtrap.tnetconsulting.net> On 12/03/2017 12:55 PM, Royce Williams wrote: > Maybe the OP is interested in outsourcing all of that - letting someone > else stay current with patching, spammer tactics, etc. You make a fair point. My point is that it is possible to do yourself /if/ you want to do so. Everyone has to make their own decision. - My goal is to provide information to help make said decision. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From dougb at dougbarton.us Mon Dec 4 03:34:29 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 3 Dec 2017 19:34:29 -0800 Subject: Ticketmaster? In-Reply-To: References: Message-ID: On 12/02/2017 02:39 PM, Ryan Gard wrote: > *Oh, you must be sharing your IP with everyone else in your area* CGNAT by any chance? From mike.lyon at gmail.com Mon Dec 4 03:42:18 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Sun, 3 Dec 2017 19:42:18 -0800 Subject: Ticketmaster? In-Reply-To: References: Message-ID: They’ve blocked a few of my end-user /24s and i’ve had zero luck getting them to unblock them. Just one more reason to hate them and not use them. They are the devil. -Mike > On Dec 3, 2017, at 19:34, Doug Barton wrote: > >> On 12/02/2017 02:39 PM, Ryan Gard wrote: >> *Oh, you must be sharing your IP with everyone else in your area* > > CGNAT by any chance? > From rvandolson at esri.com Mon Dec 4 03:55:17 2017 From: rvandolson at esri.com (Ray Van Dolson) Date: Sun, 3 Dec 2017 19:55:17 -0800 Subject: Alternatives to ISE? In-Reply-To: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> Message-ID: <20171204035517.GA8347@esri.com> On Sun, Dec 03, 2017 at 02:39:27PM +0000, Christopher J. Wolff wrote: > I've about reached my limit with the dumpster fire that is Cisco's > Identity Service Engine. Are there any reliable alternatives that do > endpoint classification, central web auth, and .1x auth? What version of ISE are you running? What are your main frustrations with it? Ray From mpalmer at hezmatt.org Mon Dec 4 04:57:52 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 4 Dec 2017 15:57:52 +1100 Subject: Ticketmaster? In-Reply-To: References: Message-ID: <20171204045752.h7ir52m3h7httyjd@hezmatt.org> On Sun, Dec 03, 2017 at 07:34:29PM -0800, Doug Barton wrote: > On 12/02/2017 02:39 PM, Ryan Gard wrote: > > *Oh, you must be sharing your IP with everyone else in your area* > > CGNAT by any chance? ... and yet: $ dig www.ticketmaster.com aaaa ; <<>> DiG 9.10.3-P4-Debian <<>> www.ticketmaster.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28358 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.ticketmaster.com. IN AAAA ;; AUTHORITY SECTION: ticketmaster.com. 2560 IN SOA a1-157.akam.net. tmhostmaster.ticketmaster.com. 2991260818 600 600 1048576 2560 From rsk at gsp.org Mon Dec 4 07:27:25 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Dec 2017 02:27:25 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> Message-ID: <20171204072725.GA2793@gsp.org> On Sun, Dec 03, 2017 at 05:08:33PM +0000, Filip Hruska wrote: > I personally run my own mail server, but route outgoing emails via Amazon > SES. Not a good idea. Amazon's cloud operations are a constant source of spam and abuse (e.g., brute-force SSH attacks), they refuse to accept complaints per RFC 2142, and -- apparently -- they simply don't care to do anything about it. I've had SES blacklisted in my MTA for years (among other preventative measures) and highly recommend to others. ---rsk From saku at ytti.fi Mon Dec 4 09:41:14 2017 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Dec 2017 11:41:14 +0200 Subject: BGP next-hop self benefits In-Reply-To: <20171201153056.GF9565@sizone.org> References: <20171201153056.GF9565@sizone.org> Message-ID: I'd like to add that one major advantage is limiting next-hops, thus labels in your network. This is not just theoretical concern but there are plenty of practical networks using practical hardware where you simply cannot expose all next-hops to every node. On 1 December 2017 at 17:30, Ken Chase wrote: > On an IX, without next-hop-self peer A leaking peer B's routes they receive to > C will have C send direct to B on the IX (assuming flat layer 3 addressing, > and not multiple little /30s or /96s everywhere or something - do any > exchanges do that?) > > This may seem more efficient than sending C's traffic to A to get to B (pumping up > the IX's usage graphs) but B may not have peering agreements with C. > > Setting next-hop-self avoids this. An 'advantage' in some views. Not related to > n-h-s in an igp specifically, but an interesting (mis)use case. > > /kc > > > On Fri, Dec 01, 2017 at 03:06:34PM +0000, craig washington said: > >Hello everyone, > > > > > >Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor. > > > >Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links? > > > >Is there a added benefit to using next hop self in this situation? > > > > > >Any feedback is much appreciated, either for the question specifically or whatever else you got ????, L3VPN's or underlying technology that has to have that. > > > > > >Thanks > > > > > > -- > Ken Chase - math at sizone.org Guelph Canada -- ++ytti From EPers at ansencorp.com Mon Dec 4 11:19:56 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Mon, 4 Dec 2017 11:19:56 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171204072725.GA2793@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> Message-ID: <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> As an anecdotal aside, approx. 70% of incoming portscanners/rdp bots/ssh bots/etc that hit the firewalls at my sites are coming from AWS. I used to send abuse emails but eventually gave up after receiving nothing beyond "well, aws ip's are dynamic/shared so we can't help you" -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Monday, December 4, 2017 2:27 AM To: nanog at nanog.org Subject: Re: Suggestions for a more privacy conscious email provider On Sun, Dec 03, 2017 at 05:08:33PM +0000, Filip Hruska wrote: > I personally run my own mail server, but route outgoing emails via Amazon > SES. Not a good idea. Amazon's cloud operations are a constant source of spam and abuse (e.g., brute-force SSH attacks), they refuse to accept complaints per RFC 2142, and -- apparently -- they simply don't care to do anything about it. I've had SES blacklisted in my MTA for years (among other preventative measures) and highly recommend to others. ---rsk From baldur.norddahl at gmail.com Mon Dec 4 12:02:56 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 4 Dec 2017 13:02:56 +0100 Subject: BGP next-hop self benefits In-Reply-To: References: Message-ID: <3222d401-5502-91fc-f3c8-215b24882908@gmail.com> Hi For the MPLS L3VPN the answer is that the next hop attribute needs to be an address from the default VRF and if the peering is happening in a VRF context, there is no address from the default VRF you could use as next hop other than self. This can be rather inconvenient as there are advantages to have the real next hop. For example fast rerouting works better when all defective routes can be removed in one go because the next hop was removed by the IGP instantly invalidating the affected routes. Regards, Baldur Den 01/12/2017 kl. 16.06 skrev craig washington: > Hello everyone, > > > Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor. > > Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links? > > Is there a added benefit to using next hop self in this situation? > > > Any feedback is much appreciated, either for the question specifically or whatever else you got 😊, L3VPN's or underlying technology that has to have that. > > > Thanks > > From kmedcalf at dessus.com Mon Dec 4 14:09:31 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 04 Dec 2017 07:09:31 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> Message-ID: On Monday, 4 December, 2017 04:20, Edwin Pers wrote: >As an anecdotal aside, approx. 70% of incoming portscanners/rdp >bots/ssh bots/etc that hit the firewalls at my sites are coming from >AWS. >I used to send abuse emails but eventually gave up after receiving >nothing beyond "well, aws ip's are dynamic/shared so we can't help >you" I tried, once upon a time, to run my private SMTP server as an AWS machine. What a disaster, even with a rubber band IP or whatever it is they call a static IP assignment. Tried sending through SES and that was just as bad. Moved it to a Linode and set up the appropriate DNS including the rDNS delegations and it has been perfectly fine (both on IPv4 and IPv6). I do recall having to do something to get it to initially work (maybe Linode does some outbound blocking of port 25 -- I don't remember exactly as it was several years ago). I know of a couple of other folks that run SMTP on Linodes and a couple of big mailing lists as well, all of which seem to work with no problems. Never had any problems with any listings on any of several hundred DNSbl either. Plus of course it is a pretty cheap way to get a reliable server (albeit virtual) on decently connected and configured infrastructure. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich >Kulawiec >Sent: Monday, December 4, 2017 2:27 AM >To: nanog at nanog.org >Subject: Re: Suggestions for a more privacy conscious email provider > >On Sun, Dec 03, 2017 at 05:08:33PM +0000, Filip Hruska wrote: >> I personally run my own mail server, but route outgoing emails via >Amazon >> SES. > >Not a good idea. Amazon's cloud operations are a constant source of >spam and abuse (e.g., brute-force SSH attacks), they refuse to accept >complaints per RFC 2142, and -- apparently -- they simply don't care >to >do anything about it. I've had SES blacklisted in my MTA for years >(among >other preventative measures) and highly recommend to others. > >---rsk --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From cjwolff at nola.gov Mon Dec 4 15:00:51 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Mon, 4 Dec 2017 15:00:51 +0000 Subject: Alternatives to ISE? In-Reply-To: <20171204035517.GA8347@esri.com> References: <47F264CE123954429FC99B9E768819F262A79DF3@CNO-XCH03.cityofno.com> <20171204035517.GA8347@esri.com> Message-ID: <47F264CE123954429FC99B9E768819F262A79FDC@CNO-XCH03.cityofno.com> Ray, I'm running 2.2 with 17000 endpoints in a 7 node deployment. Main Problems: -Replication slow or failed -Displaying endpoints ends up in a "Shards" error or crashes the GUI (documented Cisco bug) -Wifi Container Service (?) fails -Inaccurate license counts causing license alarms -Moments where unable to add or see network devices -Profile rules are not catching certain hosts (even when you hardcode the OUI) I'm certain I'm forgetting a few but you get the drift. Yours in service, Christopher J. Wolff | Network Operations Information Technology & Innovation City of New Orleans (o) 504.658.7817 (m) 504.265.6306 (e) cjwolff at nola.gov -----Original Message----- From: Ray Van Dolson [mailto:rvandolson at esri.com] Sent: Sunday, December 3, 2017 9:55 PM To: Christopher J. Wolff Cc: nanog at nanog.org Subject: Re: Alternatives to ISE? On Sun, Dec 03, 2017 at 02:39:27PM +0000, Christopher J. Wolff wrote: > I've about reached my limit with the dumpster fire that is Cisco's > Identity Service Engine. Are there any reliable alternatives that do > endpoint classification, central web auth, and .1x auth? What version of ISE are you running? What are your main frustrations with it? Ray From rsk at gsp.org Mon Dec 4 15:47:44 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Dec 2017 10:47:44 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> Message-ID: <20171204154744.GB4874@gsp.org> On Mon, Dec 04, 2017 at 11:19:56AM +0000, Edwin Pers wrote: > As an anecdotal aside, approx. 70% of incoming portscanners/rdp bots/ssh > bots/etc that hit the firewalls at my sites are coming from AWS. Similar observations here. I have found it useful to attempt to enumerate their network allocations and block them from access to any service that requires authentication, e.g., ssh, pops, imaps, etc. Not a panacea by any means, but it does cut down on the noise. ---rsk From michael at wadadli.me Sun Dec 3 17:48:02 2017 From: michael at wadadli.me (Michael S. Singh) Date: Sun, 3 Dec 2017 09:48:02 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> Hi Jean, I appreciate your response. I was considering purchasing a Raspberry Pi and setting up my own mail server on it. Would it be capable of running a personal mail server? I am on the Linux Kernel mailing list which receives around 300 emails a day. Will I also need a static IP address in order to connect to the server from anywhere in the world? On 12/03/2017 07:12 AM, Jean | ddostest.me via NANOG wrote: > If you plan to use it for a small group of people, you should consider > hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6. > > It could be seen as a personal challenge to achieve. > > Then if you need real privacy, you will need to encrypt with public keys > like PGP or S/MIME. You can upload your public key to the public pgp key > servers. I guess that one day this thing will be very popular. > > Challenge accepted? > > Jean > > On 17-12-02 05:20 PM, Paul Ferguson wrote: >> On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh >> wrote: >> >>> I am in need of some suggestions for some privacy conscious email >>> providers. I am currently using Migadu [...] >> I use KolabNow, based in Switzerland, for a lot of personal e-mail >> communications. They are very, very privacy conscious: >> >> --> https://kolabnow.com/feature/confidence >> >> They are *not* free, but quite reasonable, and I am quite happy with the >> m. >> >> - ferg >> >> >> -- Sincerely Michael S Singh, M: 914-266-0601 W: www.wadadli.me F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- A non-text attachment was scrubbed... Name: michael.vcf Type: text/x-vcard Size: 434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From michael at wadadli.me Sun Dec 3 17:57:00 2017 From: michael at wadadli.me (Michael S. Singh) Date: Sun, 3 Dec 2017 09:57:00 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> Message-ID: <37613d30-ae69-9140-5d88-7596857ce99e@wadadli.me> Hi Filip I appreciate the response! Do you host the mail server with a third party provider (e.g Rackspace)  or do you have an 'in-house' solution. If you're able to elaborate more on your setup, I would love to read more about it. I am considering purchasing a Raspberry Pi and hosting my own, as it seems worth the experience. However does it require that I have my own DNS server and a static IP address in order to connect to the mail server from anywhere in the world? On 12/03/2017 09:08 AM, Filip Hruska wrote: > It's kind of a pain to manage a mail server. > > Even if you have SPF, DKIM correctly setup and you are not on any > common blacklists, > you constantly have to fight for good deliverability - some mail > server solutions will simply reject you no matter what. > You might be on some obscure blacklist nobody uses and then you have > to waste time sending blacklist removal requests. > > I personally run my own mail server, but route outgoing emails via > Amazon SES. Gives me all the benefits > of having my own mail server (domain aliases, extensions, custom spam > filter etc) and saves me from the pain > of managing outgoing reputation. > > > -- > Filip Hruska > Linux System Administrator > > Dne 12/3/17 v 16:12 Jean | ddostest.me via NANOG napsal(a): >> If you plan to use it for a small group of people, you should consider >> hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6. >> >> It could be seen as a personal challenge to achieve. >> >> Then if you need real privacy, you will need to encrypt with public keys >> like PGP or S/MIME. You can upload your public key to the public pgp key >> servers. I guess that one day this thing will be very popular. >> >> Challenge accepted? >> >> Jean >> >> On 17-12-02 05:20 PM, Paul Ferguson wrote: >>> On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh >>> wrote: >>> >>>> I am in need of some suggestions for some privacy conscious email >>>> providers. I am currently using Migadu [...] >>> I use KolabNow, based in Switzerland, for a lot of personal e-mail >>> communications. They are very, very privacy conscious: >>> >>> --> https://kolabnow.com/feature/confidence >>> >>> They are *not* free, but quite reasonable, and I am quite happy with >>> the >>> m. >>> >>> - ferg >>> >>> >>> > -- Sincerely Michael S Singh, M: 914-266-0601 W: www.wadadli.me F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- A non-text attachment was scrubbed... Name: michael.vcf Type: text/x-vcard Size: 434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From igor.krneta at elta-kabel.com Mon Dec 4 11:21:50 2017 From: igor.krneta at elta-kabel.com (Igor Krneta) Date: Mon, 4 Dec 2017 12:21:50 +0100 Subject: Contact info, AS4766 Korea Telecom Message-ID: <4aecba74-4007-0bb6-91b3-cab03ea4c94a@elta-kabel.com> Hi, is there anyone from Korea Telecom on this list ? Trying to contact anyone in NOC, it seems that they blacklisted our complete AS (198252) and they are not responding to e-mail. Our customer support is overwhelmed with complaints about non reachable servers hosted in their network. Any help is appreciated. Sincerely, Igor Krneta Elta Kabel d.o.o. From timrutherford at c4.net Mon Dec 4 16:14:14 2017 From: timrutherford at c4.net (timrutherford at c4.net) Date: Mon, 4 Dec 2017 11:14:14 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <37613d30-ae69-9140-5d88-7596857ce99e@wadadli.me> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <37613d30-ae69-9140-5d88-7596857ce99e@wadadli.me> Message-ID: <0d9001d36d1a$edc0a900$c941fb00$@c4.net> You will also need your internet provider to setup reverse DNS for you, otherwise many mail servers may reject your mail if the reverse DNS does not match the hostname of the mail server. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael S. Singh Sent: Sunday, December 3, 2017 12:57 PM To: nanog at nanog.org Subject: Re: Suggestions for a more privacy conscious email provider Hi Filip I appreciate the response! Do you host the mail server with a third party provider (e.g Rackspace) or do you have an 'in-house' solution. If you're able to elaborate more on your setup, I would love to read more about it. I am considering purchasing a Raspberry Pi and hosting my own, as it seems worth the experience. However does it require that I have my own DNS server and a static IP address in order to connect to the mail server from anywhere in the world? On 12/03/2017 09:08 AM, Filip Hruska wrote: > It's kind of a pain to manage a mail server. > > Even if you have SPF, DKIM correctly setup and you are not on any > common blacklists, you constantly have to fight for good > deliverability - some mail server solutions will simply reject you no > matter what. > You might be on some obscure blacklist nobody uses and then you have > to waste time sending blacklist removal requests. > > I personally run my own mail server, but route outgoing emails via > Amazon SES. Gives me all the benefits of having my own mail server > (domain aliases, extensions, custom spam filter etc) and saves me from > the pain of managing outgoing reputation. > > > -- > Filip Hruska > Linux System Administrator > > Dne 12/3/17 v 16:12 Jean | ddostest.me via NANOG napsal(a): >> If you plan to use it for a small group of people, you should >> consider hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6. >> >> It could be seen as a personal challenge to achieve. >> >> Then if you need real privacy, you will need to encrypt with public >> keys like PGP or S/MIME. You can upload your public key to the public >> pgp key servers. I guess that one day this thing will be very popular. >> >> Challenge accepted? >> >> Jean >> >> On 17-12-02 05:20 PM, Paul Ferguson wrote: >>> On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh >>> >>> wrote: >>> >>>> I am in need of some suggestions for some privacy conscious email >>>> providers. I am currently using Migadu [...] >>> I use KolabNow, based in Switzerland, for a lot of personal e-mail >>> communications. They are very, very privacy conscious: >>> >>> --> https://kolabnow.com/feature/confidence >>> >>> They are *not* free, but quite reasonable, and I am quite happy with >>> the m. >>> >>> - ferg >>> >>> >>> > -- Sincerely Michael S Singh, M: 914-266-0601 W: www.wadadli.me F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 Sent via Migadu.com, world's easiest email hosting From valdis.kletnieks at vt.edu Mon Dec 4 17:02:31 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 04 Dec 2017 12:02:31 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> References: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> Message-ID: <24517.1512406951@turing-police.cc.vt.edu> On Sun, 03 Dec 2017 09:48:02 -0800, "Michael S. Singh" said: > I am on the Linux Kernel mailing list which receives around 300 emails a day. If you're only getting 300 a day, your mail infrastructure is severely broken. As I write this, I've gotten 2,151 mails from linux-kernel so far this month, and it's only the 4th. So 600-700/day is closer to what you should be seeing (plus another 300+ if Greg KH patchbombs the list for one of the stable release candidates...) Having said that, a Raspberry Pi is more than capable of that volume - many moons ago I was processing well over 1 million RCPT TO: per day on an IBM RS6000/220, which boasted a whole whopping 128M of RAM and a 133Mhz CPU. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Mon Dec 4 17:04:42 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 4 Dec 2017 10:04:42 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> References: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> Message-ID: <6ee4171b-5e57-0a4c-4604-e371879d030a@spamtrap.tnetconsulting.net> On 12/03/2017 10:48 AM, Michael S. Singh wrote: > I was considering purchasing a Raspberry Pi and setting up my own mail > server on it. Would it be capable of running a personal mail server? I > am on the Linux Kernel mailing list which receives around 300 emails a day. Is a Raspberry Pi capable of functioning as a mail server, sure. Would I recommend it, most likely not. I see two things being a limitation for the Raspberry Pi, 1) lack of memory (for various filters and support daemons) and 2) (lack of) disk. I think you will be spending quite a bit more time than you will likely care to waiting on the Raspberry Pi. An external disk will help. I would strongly suggest that you look at a Linode VPS (which is what I'm using) or something similar. Preferably something that is very well connected (both speed and more diverse back bone connectivity) and SSD backed. > Will I also need a static IP address in order to connect to the server > from anywhere in the world? Technically, no. You can tune your DNS such that the A record that your MX record points to has a low TTL thus avoiding caching and enabling dynamic DNS. - Would I do this for my mail server? Not at all. Would I do this for my home server that smart hosts through my mail mail server (Linode VPS), sure. There is a big difference in what will technically work and what you will want to end up using. If you're serious about this (which I encourage you to scratch the itch if you're so inclined) then I would strongly recommend spending ~$10 a month for a VPS as your primary mail server. (You can then have it forward to an internal mail server if you want to.) Feel free to reply to me (on or off list) if you would like to discuss further details. Note: You will need DNS servers with static IPs that you can configure in your domain registrar. (ProTip: Linode allows you to use their five DNS servers for the low price of having a single Linode VPS.) Everything else is ... technically flexible from that point. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From fhr at fhrnet.eu Mon Dec 4 17:59:30 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 4 Dec 2017 17:59:30 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> Message-ID: <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> AWS is probably the biggest cloud provider in the world. Of course the majority of junk is going to be coming from their network, simply because they are that big. Hovever, I really wanted to see what the bot statistics for my mail server were so I scanned my `Postfix` and `secure` log files for "access denied" entries. In the past 10 hours, there were: * 573 Postfix SASL Auth Failed entries from 106 different IPs * 1479 SSH Auth Failed attempts from 13 different IPs I see lots of OVH, Azure, home/business connection providers (TELSTRA Australia, lot of Asian stuff, Telefonica, Vodafone, Verizon...), some random cloud/dedicated server provider here and there... but not a single Amazon IP - which surprised me quite a bit actually. For reference, this server is with OVH in France and does not have fail2ban installed. Postfix has connection rate limiting enabled though. On another note, I wouldn't recommend blatantly blacklisting anyone, especially not large service/platform/infrastructure providers. Many businesses (such as e-shops) rely completely on AWS (or other cloud) infrastructure. If you don't receive emails containing order details or invoices because you completely blacklisted them... well, that's your problem. If your server is setup correctly, those bots are completely harmless and spamassassin will destroy 99.9% of spam emails, which I call success. The other 0.1% that goes through (that one email a week) I can delete manually. Regards -- Filip Hruska Linux System Administrator Dne 12/4/17 v 12:19 Edwin Pers napsal(a): > As an anecdotal aside, approx. 70% of incoming portscanners/rdp bots/ssh bots/etc that hit the firewalls at my sites are coming from AWS. > I used to send abuse emails but eventually gave up after receiving nothing beyond "well, aws ip's are dynamic/shared so we can't help you" > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec > Sent: Monday, December 4, 2017 2:27 AM > To: nanog at nanog.org > Subject: Re: Suggestions for a more privacy conscious email provider > > On Sun, Dec 03, 2017 at 05:08:33PM +0000, Filip Hruska wrote: >> I personally run my own mail server, but route outgoing emails via Amazon >> SES. > Not a good idea. Amazon's cloud operations are a constant source of > spam and abuse (e.g., brute-force SSH attacks), they refuse to accept > complaints per RFC 2142, and -- apparently -- they simply don't care to > do anything about it. I've had SES blacklisted in my MTA for years (among > other preventative measures) and highly recommend to others. > > ---rsk > From nanog at ics-il.net Mon Dec 4 19:45:45 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 4 Dec 2017 13:45:45 -0600 (CST) Subject: 100G - Whitebox In-Reply-To: <599ABF99.5060507@foobar.org> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> <599A093C.8070706@foobar.org> <599ABF99.5060507@foobar.org> Message-ID: <308587937.8357.1512416744126.JavaMail.mhammett@ThunderFuck> In terms of 1G - 10G steps, it looks like UCSC has done some of that homework already. https://people.ucsc.edu/~warner/Bufs/summary "Ability to buffer 6 Mbytes is sufficient for a 10 Gb/s sender and a 1 Gb/s receiver." I'd suspect 10x would be appropriate for 100G - 10G (certainly made more accurate by testing). http://people.ucsc.edu/~warner/I2-techs.ppt Looking through their table ( https://people.ucsc.edu/~warner/buffer.html ), it looks like more switches than not in the not-100g realm have just enough buffers to handle one, possibly two mis-matches at a time. Some barely don't have enough and others are woefully inadequate. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Mikael Abrahamsson" Cc: "NANOG list" Sent: Monday, August 21, 2017 6:10:17 AM Subject: Re: 100G - Whitebox Mikael Abrahamsson wrote: > On Sun, 20 Aug 2017, Nick Hilliard wrote: >> Mostly you can engineer around this, but it's not as simple as saying >> that small-buffer switches aren't suitable for an IXP. > > Could you please elaborate on this? > > How do you engineer around having basically no buffers at all, and > especially if these very small buffers are shared between ports. you assess and measure, then choose the appropriate set of tools to deal with your requirements and which is cost appropriate for your financials, i.e. the same as in any engineering situation. At an IXP, it comes down to the maximum size of tcp stream you expect to transport. This will vary depending on the stakeholders at the IXP, which usually depends on the size of the IXP. Larger IXPs will have a wider traffic remit and probably a much larger variance in this regard. Smaller IXPs typically transport content to access network data, which is usually well behaved traffic. Traffic drops on the core need to be kept to the minimum, particularly during normal operation. Eliminating traffic drops is unnecessary and unwanted because of how IP works, so in your core you need to aim for either link overengineering or else enough buffering to ensure that site-to-site latency does not exceed X ms and Y% packet loss. Each option has a cost implication. At the IXP participant edge, there is a different set of constraints which will depend on what's downstream of the participant, where the traffic flows are, what size they are, etc. In general, traffic loss at the IXP handoff will tend only to be a problem if there is a disparity between the bandwidth left available on the egress direction and the maximum link speed downstream of the IXP participant. For example, a content network has servers which inject content at 10G, which connects through a 100G IXP port. The egress IXP port is a mid-loaded 1G link which connects through to 10mbit WISP customers. In this case, the ixp will end up doing negligible buffering because most of the buffering load will be handled on the WISP's internal infrastructure, specifically at the core-to-10mbit handoff. The IXP port might end up dropping a packet or two during the initial tcp burst, but that is likely to be latency specific and won't particularly harm overall performance because of tcp slow start. On the other hand, if it were a mid-loaded 1G link with 500mbit access customers on the other side (e.g. docsis / gpon / ftth), then the IXP would end up being the primary buffering point between the content source and destination and this would cause problems. The remedy here is either for the ixp to move the customer to a buffered port (e.g. different switch), or for the access customer to upgrade their link. If you want to push 50G-80G streams through an IXP, I'd argue that you really shouldn't, not just because of cost but also because this is very expensive to engineer properly and you're also certainly better off with a pni. This approach works better on some networks than others. The larger the IXP, the more difficult it is to manage this, both in terms of core and edge provisioning, i.e. the greater the requirement for buffering in both situations because you have a greater variety of streaming scales per network. So although this isn't going to work as well for top-10 ixps as for mid- or smaller-scale ixps, where it works, it can provide similar quality of service at a significantly lower cost base. IOW, know your requirements and choose your tools to match. Same as with all engineering. Nick From sf at lists.esoteric.ca Mon Dec 4 20:30:32 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Mon, 4 Dec 2017 15:30:32 -0500 Subject: 100G - Whitebox In-Reply-To: <308587937.8357.1512416744126.JavaMail.mhammett@ThunderFuck> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> <599A093C.8070706@foobar.org> <599ABF99.5060507@foobar.org> <308587937.8357.1512416744126.JavaMail.mhammett@ThunderFuck> Message-ID: <4d931691-f850-2b43-b514-c58828371baf@lists.esoteric.ca> Mike, Whether it becomes a practical problem depends on the use case and by that I mean buffers can cut both ways. If buffers are too small, traffic can be dropped and even worse, other traffic could be affected depending on factors like ASIC design an HOLB. Too large, latency or order sensitive traffic can be adversely affected. We're still dealing with the same limitations of switching which were identified 30+ years ago as the technology was developed. Sure we have better chips, the options of better buffers and years ago experience to help minimize those limitations, but those still exist and likely always will with switching. Honestly at this point it comes down to understanding what the use case it and understanding the nuances that each vendor's offerings provide and determining where things line up. Then test test test. -- Stephen On 2017-12-04 2:45 PM, Mike Hammett wrote: > In terms of 1G - 10G steps, it looks like UCSC has done some of that homework already. > > > https://people.ucsc.edu/~warner/Bufs/summary > > > "Ability to buffer 6 Mbytes is sufficient for a 10 Gb/s sender and a 1 Gb/s receiver." I'd suspect 10x would be appropriate for 100G - 10G (certainly made more accurate by testing). > > > http://people.ucsc.edu/~warner/I2-techs.ppt > > > > Looking through their table ( https://people.ucsc.edu/~warner/buffer.html ), it looks like more switches than not in the not-100g realm have just enough buffers to handle one, possibly two mis-matches at a time. Some barely don't have enough and others are woefully inadequate. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Nick Hilliard" > To: "Mikael Abrahamsson" > Cc: "NANOG list" > Sent: Monday, August 21, 2017 6:10:17 AM > Subject: Re: 100G - Whitebox > > Mikael Abrahamsson wrote: >> On Sun, 20 Aug 2017, Nick Hilliard wrote: >>> Mostly you can engineer around this, but it's not as simple as saying >>> that small-buffer switches aren't suitable for an IXP. >> >> Could you please elaborate on this? >> >> How do you engineer around having basically no buffers at all, and >> especially if these very small buffers are shared between ports. > > you assess and measure, then choose the appropriate set of tools to deal > with your requirements and which is cost appropriate for your > financials, i.e. the same as in any engineering situation. > > At an IXP, it comes down to the maximum size of tcp stream you expect to > transport. This will vary depending on the stakeholders at the IXP, > which usually depends on the size of the IXP. Larger IXPs will have a > wider traffic remit and probably a much larger variance in this regard. > Smaller IXPs typically transport content to access network data, which > is usually well behaved traffic. > > Traffic drops on the core need to be kept to the minimum, particularly > during normal operation. Eliminating traffic drops is unnecessary and > unwanted because of how IP works, so in your core you need to aim for > either link overengineering or else enough buffering to ensure that > site-to-site latency does not exceed X ms and Y% packet loss. Each > option has a cost implication. > > At the IXP participant edge, there is a different set of constraints > which will depend on what's downstream of the participant, where the > traffic flows are, what size they are, etc. In general, traffic loss at > the IXP handoff will tend only to be a problem if there is a disparity > between the bandwidth left available on the egress direction and the > maximum link speed downstream of the IXP participant. > > For example, a content network has servers which inject content at 10G, > which connects through a 100G IXP port. The egress IXP port is a > mid-loaded 1G link which connects through to 10mbit WISP customers. In > this case, the ixp will end up doing negligible buffering because most > of the buffering load will be handled on the WISP's internal > infrastructure, specifically at the core-to-10mbit handoff. The IXP > port might end up dropping a packet or two during the initial tcp burst, > but that is likely to be latency specific and won't particularly harm > overall performance because of tcp slow start. > > On the other hand, if it were a mid-loaded 1G link with 500mbit access > customers on the other side (e.g. docsis / gpon / ftth), then the IXP > would end up being the primary buffering point between the content > source and destination and this would cause problems. The remedy here > is either for the ixp to move the customer to a buffered port (e.g. > different switch), or for the access customer to upgrade their link. > > If you want to push 50G-80G streams through an IXP, I'd argue that you > really shouldn't, not just because of cost but also because this is very > expensive to engineer properly and you're also certainly better off with > a pni. > > This approach works better on some networks than others. The larger the > IXP, the more difficult it is to manage this, both in terms of core and > edge provisioning, i.e. the greater the requirement for buffering in > both situations because you have a greater variety of streaming scales > per network. So although this isn't going to work as well for top-10 > ixps as for mid- or smaller-scale ixps, where it works, it can provide > similar quality of service at a significantly lower cost base. > > IOW, know your requirements and choose your tools to match. Same as > with all engineering. > > Nick > From adlawson at zoho.com Mon Dec 4 19:19:14 2017 From: adlawson at zoho.com (Adam Lawson) Date: Mon, 04 Dec 2017 11:19:14 -0800 Subject: Small full BGP table capable router with low power consumption Message-ID: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Hi, I'm looking for suggestions on 1U-2U sized router with 1G interface which can handle both IPv4 and IPv6 full BGP table and doesn't consume too much power. The router needs to be squeezed in to a rack which doesn't have a lot of space nor power. As for space, maybe I can make space for 3U or 4U but as for power, I can only do around 1.5A at 100V on average. (There is room for burst power usage.) The following are the one's I can think of: - Juniper M7i with C-FEB-E (base 1.59A) - Brocade CER2024F (1.35A) - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity - A server with Vyos, vMX or ASR1000v Does anyone have other recommendations? Thanks, Adam From mel at beckman.org Mon Dec 4 20:55:59 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 4 Dec 2017 20:55:59 +0000 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> The Edgerouter Pro 8 meets all your specs. It's 1U, has eight GigE ports, including two SFP/combo ports, can take full IPv4 and IPv6 tables, and only consumes 40 watts (about half an amp at 120V). About $300. https://www.ubnt.com/edgemax/edgerouter-pro/ -mel beckman > On Dec 4, 2017, at 12:46 PM, Adam Lawson wrote: > > Hi, > > > > I'm looking for suggestions on 1U-2U sized router with 1G interface > > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > > too much power. > > > > The router needs to be squeezed in to a rack which doesn't > > have a lot of space nor power. As for space, maybe I can make > > space for 3U or 4U but as for power, I can only do around > > 1.5A at 100V on average. (There is room for burst power usage.) > > > > The following are the one's I can think of: > > - Juniper M7i with C-FEB-E (base 1.59A) > > - Brocade CER2024F (1.35A) > > - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity > > - A server with Vyos, vMX or ASR1000v > > > > Does anyone have other recommendations? > > > > Thanks, > > Adam > > > > > > > > From johnl at iecc.com Mon Dec 4 21:24:24 2017 From: johnl at iecc.com (John Levine) Date: 4 Dec 2017 21:24:24 -0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <37613d30-ae69-9140-5d88-7596857ce99e@wadadli.me> Message-ID: <20171204212424.34987.qmail@ary.lan> In article <37613d30-ae69-9140-5d88-7596857ce99e at wadadli.me> you write: >I am considering purchasing a Raspberry Pi and hosting my own, as it >seems worth the experience. However does it require that I have my own >DNS server and a static IP address in order to connect to the mail >server from anywhere in the world? You really don't want to do that unless you have a friend at a hosting center who will let him plug your Pi into his rack and lend you a static IP. Getting static IPs at home these days is pretty much impossible unless you get very expensive business class cable service. Even if you have a static-ish IP on residential cable, nobody accepts mail directly from resi networks since it is about 99.99% botnet spam. On the other hand, it is the work of a moment to set up a $5/mo VPS running linux with a static IP at any of a long list of hosting providers like Tektonix or Digital Ocean or Linode. From your point of view, it's a linux box you can ssh into and manage the same way you'd manage linux on a small physical machine. R's, John From bill at herrin.us Mon Dec 4 21:43:22 2017 From: bill at herrin.us (William Herrin) Date: Mon, 4 Dec 2017 16:43:22 -0500 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: On Mon, Dec 4, 2017 at 2:19 PM, Adam Lawson wrote: > The router needs to be squeezed in to a rack which doesn't > have a lot of space nor power. As for space, maybe I can make > space for 3U or 4U but as for power, I can only do around > 1.5A at 100V on average. (There is room for burst power usage.) A Cisco 2911 or 3945 does this though the 3945 is a little more power hungry. A current generation x86 server running Linux and Quagga does this. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Mon Dec 4 22:03:56 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 4 Dec 2017 22:03:56 +0000 Subject: Small full BGP table capable router with low power consumption In-Reply-To: References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> Watch the memory requirements on a full Internet table in the Cisco 2900 series. More current model would be the Cisco 4300 - 4400 ISR series. They have 2/4/8/16 gigs of memory. Power consumption MAX ranges from 0.6A to 3.0A depending on model. Higher models have more throughput and more interfaces. Throughput ranges from 35 mbps to 2 gbps. I rarely see Cisco routers running near the max power rating especially if you are not using PoE or etherswitch interfaces. The 43xx series is replacing the 29xx series and the 44xx series is replacing the 39xx series. I've put in a few of them and they are pretty nice. They are either 1 or 2 U in size. We are using 4431 with throughput license to 1 GB receiving a full table from the provider and three IBGP peers with no issues and full gig throughput. It is currently drawing 65 watts of power in steady state and 250 watts on bootup (not using any PoE or network modules, just built in Ethernets). Steven Naslund Chicago IL >>-----Original Message----- >>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin >>Sent: Monday, December 04, 2017 3:43 PM >>To: Adam Lawson >>Cc: nanog >>Subject: Re: Small full BGP table capable router with low power consumption >>On Mon, Dec 4, 2017 at 2:19 PM, Adam Lawson wrote: >> The router needs to be squeezed in to a rack which doesn't have a lot >> of space nor power. As for space, maybe I can make space for 3U or 4U >> but as for power, I can only do around 1.5A at 100V on average. (There is >> room for burst power usage.) >A Cisco 2911 or 3945 does this though the 3945 is a little more power hungry. >A current generation x86 server running Linux and Quagga does this. >Regards, >Bill Herrin >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From gtaylor at tnetconsulting.net Mon Dec 4 22:06:07 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 4 Dec 2017 15:06:07 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171204212424.34987.qmail@ary.lan> References: <20171204212424.34987.qmail@ary.lan> Message-ID: On 12/04/2017 02:24 PM, John Levine wrote: > From your point of view, it's a linux box you can ssh into and manage > the same way you'd manage linux on a small physical machine. In my naive opinion, there are some subtle differences with where "the linux box you can ssh into" resides. Namely, when I ran my server at home, it took a search warrant to legally enter my house to access the server, which I would be immediately made aware of. I can't say the same with the same degree of certainty for a server located in a co-location facility. I'm obviously ignoring someone compromising the system across the network. Though even then, I can disconnect the server from the outside world and still access it from my home. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From saku at ytti.fi Mon Dec 4 22:12:27 2017 From: saku at ytti.fi (Saku Ytti) Date: Tue, 5 Dec 2017 00:12:27 +0200 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: Hey Adam, Review also: Nokia IXR-R6 (not IXR-6) Huawei NE20E-S2E On 4 December 2017 at 21:19, Adam Lawson wrote: > Hi, > > > > I'm looking for suggestions on 1U-2U sized router with 1G interface > > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > > too much power. > > > > The router needs to be squeezed in to a rack which doesn't > > have a lot of space nor power. As for space, maybe I can make > > space for 3U or 4U but as for power, I can only do around > > 1.5A at 100V on average. (There is room for burst power usage.) > > > > The following are the one's I can think of: > > - Juniper M7i with C-FEB-E (base 1.59A) > > - Brocade CER2024F (1.35A) > > - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity > > - A server with Vyos, vMX or ASR1000v > > > > Does anyone have other recommendations? > > > > Thanks, > > Adam > > > > > > > > -- ++ytti From jlarsen at richweb.com Mon Dec 4 22:13:40 2017 From: jlarsen at richweb.com (C. Jon Larsen) Date: Mon, 4 Dec 2017 17:13:40 -0500 (EST) Subject: Small full BGP table capable router with low power consumption In-Reply-To: <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> Message-ID: On Mon, 4 Dec 2017, Naslund, Steve wrote: FWIW ... OpenBSD on a lanner appliance with openbgpd will chew 1G. Especially on the latest version - 6.2. Debian on the same lanner running bird would also chew that as well. >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin >>> Sent: Monday, December 04, 2017 3:43 PM >>> To: Adam Lawson >>> Cc: nanog >>> Subject: Re: Small full BGP table capable router with low power consumption > >>> On Mon, Dec 4, 2017 at 2:19 PM, Adam Lawson wrote: >>> The router needs to be squeezed in to a rack which doesn't have a lot >>> of space nor power. As for space, maybe I can make space for 3U or 4U >>> but as for power, I can only do around 1.5A at 100V on average. (There is >>> room for burst power usage.) > >> A Cisco 2911 or 3945 does this though the 3945 is a little more power hungry. > >> A current generation x86 server running Linux and Quagga does this. > >> Regards, >> Bill Herrin > > >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: > From valdis.kletnieks at vt.edu Mon Dec 4 22:20:49 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 04 Dec 2017 17:20:49 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <20171204212424.34987.qmail@ary.lan> Message-ID: <60324.1512426049@turing-police.cc.vt.edu> On Mon, 04 Dec 2017 15:06:07 -0700, Grant Taylor via NANOG said: > Namely, when I ran my server at home, it took a search warrant to > legally enter my house to access the server, which I would be > immediately made aware of. I'll just remind everybody that if this is a serious component of your threat model, you probably need to have gotten in touch with some serious professionals to help set everything up, because it's going to have more little gotchas than we can cover here on NANOG. For starters, did you build your system in a way that avoids cold-boot attacks against the crypto keys that manage access to your hard drive? (Those 6 of you who *are* serious professionals at this can ignore that advice :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From andy at mbrez.com Mon Dec 4 22:42:04 2017 From: andy at mbrez.com (Andy Brezinsky) Date: Mon, 4 Dec 2017 16:42:04 -0600 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <20171204212424.34987.qmail@ary.lan> Message-ID: On 12/04/2017 04:06 PM, Grant Taylor via NANOG wrote: > In my naive opinion, there are some subtle differences with where "the > linux box you can ssh into" resides. > > Namely, when I ran my server at home, it took a search warrant to > legally enter my house to access the server, which I would be > immediately made aware of. I can't say the same with the same degree > of certainty for a server located in a co-location facility. > > I'm obviously ignoring someone compromising the system across the > network. Though even then, I can disconnect the server from the > outside world and still access it from my home. If you're really worried about this, separate your mail storage from the mail transport. Run an inbound and outbound smarthost on your $5 VPS to queue up mail and deliver it back to your house where your long term mail is stored. This gives you the benefit of the static IP at the VPS along with the security and cheap storage of having the mail storage in house. If you're worried about the short amount of time that messages are queued up on your VPS before making it to your house then you really shouldn't be communicating over email. From brad at shub-internet.org Mon Dec 4 22:41:55 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 4 Dec 2017 16:41:55 -0600 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <60324.1512426049@turing-police.cc.vt.edu> References: <20171204212424.34987.qmail@ary.lan> <60324.1512426049@turing-police.cc.vt.edu> Message-ID: <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> On Dec 4, 2017, at 4:20 PM, valdis.kletnieks at vt.edu wrote: > I'll just remind everybody that if this is a serious component of your threat > model, you probably need to have gotten in touch with some serious > professionals to help set everything up, because it's going to have more little > gotchas than we can cover here on NANOG. Yup. > For starters, did you build > your system in a way that avoids cold-boot attacks against the crypto > keys that manage access to your hard drive? Probably not. > (Those 6 of you who *are* serious professionals at this can ignore that advice :) Do I count? I only accused the Director of the NSA of High Treason in my letter to the editors of the Communications of the ACM (see ). So, yeah -- having the hardware here in my house so that it is more secure against unreasonable search and seizure -- that is very much in my threat model. -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP URL: From brad at shub-internet.org Mon Dec 4 22:47:52 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 4 Dec 2017 16:47:52 -0600 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <20171204212424.34987.qmail@ary.lan> Message-ID: <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> On Dec 4, 2017, at 4:42 PM, Andy Brezinsky wrote: > If you're really worried about this, separate your mail storage from the mail transport. Run an inbound and outbound smarthost on your $5 VPS to queue up mail and deliver it back to your house where your long term mail is stored. This gives you the benefit of the static IP at the VPS along with the security and cheap storage of having the mail storage in house. The concept is sound, but attempting to use your $5 VPS as your outbound mail relay is only going to end in pain and tears -- your VPS cannot have or build a good enough reputation to get reliable delivery to the big mail providers. You need to use an outbound mail relay that already has a good reputation, and that works hard to continue to maintain that reputation. As for handling your inbound mail, use something like imapsync and then effectively treat your IMAP provider as a POP3 provider instead, and download/delete the messages from their system as soon as they have been copied to your local system. The bad guys could tap into the stream of mail that flows through that system, but they wouldn't be able to get into your archive of old mail without breaking into the box sitting in your house. -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP URL: From valdis.kletnieks at vt.edu Mon Dec 4 22:51:17 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 04 Dec 2017 17:51:17 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> References: <20171204212424.34987.qmail@ary.lan> <60324.1512426049@turing-police.cc.vt.edu> <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> Message-ID: <6698.1512427877@turing-police.cc.vt.edu> On Mon, 04 Dec 2017 16:41:55 -0600, Brad Knowles said: > > (Those 6 of you who *are* serious professionals at this can ignore = > that advice :) > > Do I count? I only accused the Director of the NSA of High Treason in > my letter to the editors of the Communications of the ACM (see > ). Treason fail. What declared enemy of the US did the Director provide aid and comfort to? (Hint: a declaration of war seems to be considered important - during the Korean conflict a number of soldiers didn't get prosecuted for treason at least partly because we hadn't actually declared war on North Korea. Similarly, the Rosenbergs got the chair for espionage but not treason, because we didn't declare war on the USSR either during the Cold War). Actually, we haven't declared war on anybody since WWII...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Mon Dec 4 22:52:57 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 4 Dec 2017 15:52:57 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <20171204212424.34987.qmail@ary.lan> Message-ID: <4be87d99-198e-0f93-a00c-4db2e2223f47@spamtrap.tnetconsulting.net> I'm not personally really worried about this. - I was just calling out that it is a difference. For others that do care. ;-) On 12/04/2017 03:42 PM, Andy Brezinsky wrote: > If you're really worried about this, separate your mail storage from the > mail transport.  Run an inbound and outbound smarthost on your $5 VPS to > queue up mail and deliver it back to your house where your long term > mail is stored.  This gives you the benefit of the static IP at the VPS > along with the security and cheap storage of having the mail storage in > house. I agree that the VPS Smart Host is a good solution. However that puts you in a position that you are now administering multiple mail servers. I'd suggest that people new to mail servers stick with a single $5 ~ $10 / month VPS that does all of the roles. - Then graduate to the multiple server solution. > If you're worried about the short amount of time that messages are > queued up on your VPS before making it to your house then you really > shouldn't be communicating over email. I think it depends what part of the communications you're worried about. S/MIME and PGP tend to cover a lot of the (non-metadata) concern. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From brad at shub-internet.org Mon Dec 4 22:54:49 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 4 Dec 2017 16:54:49 -0600 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <6698.1512427877@turing-police.cc.vt.edu> References: <20171204212424.34987.qmail@ary.lan> <60324.1512426049@turing-police.cc.vt.edu> <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> <6698.1512427877@turing-police.cc.vt.edu> Message-ID: <52CB315A-A305-4B1D-AF46-8DDA49B73F76@shub-internet.org> On Dec 4, 2017, at 4:51 PM, valdis.kletnieks at vt.edu wrote: >> Do I count? I only accused the Director of the NSA of High Treason in >> my letter to the editors of the Communications of the ACM (see >> ). > > Treason fail. What declared enemy of the US did the Director provide aid and > comfort to? Technically, I accused him of causing Very Grave Harm to National Security Interests, which is treated at the same severity as High Treason. Or at least, that was the way I read the "Orange Book" TCSEC at the time, because I deliberately took the wording straight from that book. -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP URL: From gtaylor at tnetconsulting.net Mon Dec 4 23:00:11 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 4 Dec 2017 16:00:11 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> References: <20171204212424.34987.qmail@ary.lan> <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> Message-ID: <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> On 12/04/2017 03:47 PM, Brad Knowles wrote: > The concept is sound, but attempting to use your $5 VPS as your outbound > mail relay is only going to end in pain and tears -- your VPS cannot have > or build a good enough reputation to get reliable delivery to the big mail > providers. You need to use an outbound mail relay that already has a good > reputation, and that works hard to continue to maintain that reputation. My experience shows otherwise. I've been using a VPS as my primary mail server for > 2 years and have only been black listed once. Even that was a 12 hour automated listing because I sent one message to an address I had not used in 7 years, which had since been converted into a spam trap. I've also known others that use VPSs for this exact thing with considerable success. > As for handling your inbound mail, use something like imapsync and then > effectively treat your IMAP provider as a POP3 provider instead, and > download/delete the messages from their system as soon as they have been > copied to your local system. Why? Having a different provider handle inbound will require them supporting your domain(s). Why not handle inbound email directly? > The bad guys could tap into the stream of mail that flows through that > system, but they wouldn't be able to get into your archive of old mail > without breaking into the box sitting in your house. S/MIME / PGP }:-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From SNaslund at medline.com Mon Dec 4 23:22:48 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 4 Dec 2017 23:22:48 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <52CB315A-A305-4B1D-AF46-8DDA49B73F76@shub-internet.org> References: <20171204212424.34987.qmail@ary.lan> <60324.1512426049@turing-police.cc.vt.edu> <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> <6698.1512427877@turing-police.cc.vt.edu> <52CB315A-A305-4B1D-AF46-8DDA49B73F76@shub-internet.org> Message-ID: <9578293AE169674F9A048B2BC9A081B40273141D24@MUNPRDMBXA1.medline.com> There are all kinds of factual issues with the arguments in the referenced document. 1. During Desert Storm I personally sent hundreds of STU-IIIs to the sandbox. They didn't go in diplomatic pouches, they went as Air Force cargo like everything else. The State Department did not have to "smuggle" anything. They use diplomatic pouch as a way to prevent the receiving country from inspecting the shipments. This is common for all cryptographic devices, classified or not. Also commonly used for Playboy magazines and bottles of scotch going into Saudi Arabia. 2. Treason is not applicable here because there must be a declared war. Treason requires interaction with a declared enemy during a time of war. I know that term gets thrown around haphazardly lately but it is a very specific legal term. 3. Asking a government agency act as the KDF is so demonstrably brain damaged we don't even need to go into the problems with that. They have shown that: a. They are not interested in keeping your data secure, in fact they would like to keep as much of it in their databases as possible. b. Most of the organizations you listed have been breached multiple times and receive failing grades under their own IT standards for security. c. International organizations are even worse. So, if my keys are stored by the IEEE does that mean that only countries that are part of the United Nations can get access to my data. I feel much better now :) 4. Sending a device or technology out of the US does not equal an export under ITAR. In your example, if a device is going to be used by US Government employees or military personnel and kept under their control, it is not an export. As a matter of fact a US company can use export restricted software and hardware in foreign countries in most cases if it is under to control of US Nationals. i.e. US company can use high encryption licenses for Cisco devices inside of China branch offices to secure their VPN connections. My company has this in writing, we did all of the appropriate export paperwork and then was told it was unnecessary since the software remains under the control of US nationals (of course they know that all the foreign intel agencies already have it so they are not worried about James Bond sneaking in the middle of the night to reverse engineer it). 5. The DirNSA has a vested interest in the collection of intelligence and the security of US GOVERNMENT systems as his primary responsibilities. Securing US private entities is way down his list of priorities and if in conflict with his primary missions will take a back seat. Not treason my friend just focus on his mission. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brad Knowles Sent: Monday, December 04, 2017 4:55 PM To: valdis.kletnieks at vt.edu Cc: nanog at nanog.org; Grant Taylor Subject: Re: Suggestions for a more privacy conscious email provider On Dec 4, 2017, at 4:51 PM, valdis.kletnieks at vt.edu wrote: >> Do I count? I only accused the Director of the NSA of High Treason >> in my letter to the editors of the Communications of the ACM (see >> ). > > Treason fail. What declared enemy of the US did the Director provide > aid and comfort to? From rsk at gsp.org Mon Dec 4 23:34:03 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Dec 2017 18:34:03 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> Message-ID: <20171204233403.GA16717@gsp.org> On Mon, Dec 04, 2017 at 05:59:30PM +0000, Filip Hruska wrote: > AWS is probably the biggest cloud provider in the world. Of course the > majority of junk is going to be coming from their network, > simply because they are that big. This is incorrect reasoning. Because they're the biggest cloud provider in the world, they should send the least amount of junk: the larger an operation is, the easier abuse detection/prevention gets. [1] They have -- for all practical purposes -- unlimited computing resources, unlimited personnel resources, and unlimited financial resources. Shouldn't they be leading? Shouldn't they be more professional, more competent, more diligent than all of us? Shouldn't they be the exemplar for How To Do It Right? ---rsk [1] I don't expect them, or anyone else, to catch everything all the time. There are always unpleasant surprises. But there is absolutely no excuse for systemic, chronic abuse, for failure to accept abuse reports, for failure to respond to them quickly, for failure to act on them promptly, for failure to prevent repeat incidents, or for failure to apologize. From rsk at gsp.org Mon Dec 4 23:38:19 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Dec 2017 18:38:19 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> References: <2c0a97f1-ae28-0c94-2e6d-baa36793762a@wadadli.me> Message-ID: <20171204233819.GB16717@gsp.org> On Sun, Dec 03, 2017 at 09:48:02AM -0800, Michael S. Singh wrote: > Will I also need a static IP address in order to connect to the server > from anywhere in the world? Yes. And it will need to be located in an allocation that's known to be static, i.e., a single static address in the midst of a large block of dynamic addresses == trouble. It'll also need to be on a provider that that has scrupulously dealt with abuse issues; those that don't may have large swaths of address space that's already blacklisted. One way to determine this is to ask them what address they will assign *before* you sign up, then check that address against various blacklists. You'll also need matching A and PTR records: if the mail server is mail-abc.example.com, then the PTR needs to match. It's also highly advisable to make it HELO as that same canonical name. I also suggest running an instance of a nameserver on the same box. Mail servers make a lot of DNS queries, so having one right there -- with a cache that will eventually be populated according to local usage patterns -- is useful. Just make sure it's not an open resolver, i.e., make sure it only answers queries on 127.0.0.1 A Raspberry Pi can handle this. Doubly so if you customize its defenses specifically to your needs. The more abuse you reject outright via the onboard firewall and via MTA configuration, the less will make it through to more computationally expensive steps. Note that you'll need enough storage if you really do plan to use it for the LKML; I've seen roughly 50M in traffic on it since 11/28 and there are times when it spikes (in terms of the number of messages and their aggregate volume) quite a bit. ---rsk From joquendo at e-fensive.net Tue Dec 5 00:14:24 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Mon, 4 Dec 2017 18:14:24 -0600 Subject: Akamai contact Message-ID: <20171205001424.q6jpgqqnmtmcmmwm@e-fensive.net> Can one of the Akamai (non salesy) guys ping me off list please. Security related. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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 0A96 6318 EA49 4032 21C9 A7A8 81E9 3E95 414F 356E https://pgp.mit.edu/pks/lookup?op=get&search=0x81E93E95414F356E From eric-list at truenet.com Tue Dec 5 00:38:18 2017 From: eric-list at truenet.com (Eric Tykwinski) Date: Mon, 4 Dec 2017 19:38:18 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171204233403.GA16717@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> Message-ID: <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> > On Dec 4, 2017, at 6:34 PM, Rich Kulawiec wrote: > > ---rsk > > [1] I don't expect them, or anyone else, to catch everything all the > time. There are always unpleasant surprises. But there is absolutely > no excuse for systemic, chronic abuse, for failure to accept abuse > reports, for failure to respond to them quickly, for failure to > act on them promptly, for failure to prevent repeat incidents, > or for failure to apologize. Not from I’ve seen, most get big fast, and than security follows secondary. Name your ISP, your Cloud, and your Virtual Environment. Comcast and AOL used to be hell for spam, then they started blocking SMTP, or in AOL’s case sort of went out of business till the VZ buyout. From what I’ve noticed, OVH is sort of the same, got big quick and was one of the biggest spammers around, they have finally gotten their act together IMHO. Linode from what I remember hasn’t been that bad, a couple of hacked servers of course, but par for the course and kept things manageable and responsive to my requests. Main point I think is mailops comes with a learning curve, and it happens... From johnl at iecc.com Tue Dec 5 01:46:37 2017 From: johnl at iecc.com (John Levine) Date: 5 Dec 2017 01:46:37 -0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: Message-ID: <20171205014637.35806.qmail@ary.lan> In article you write: >On 12/04/2017 02:24 PM, John Levine wrote: >> From your point of view, it's a linux box you can ssh into and manage >> the same way you'd manage linux on a small physical machine. >Namely, when I ran my server at home, it took a search warrant to >legally enter my house to access the server, which I would be >immediately made aware of. Your life appears to be much more exciting than the rest of ours. I've been running mail servers in various places including my house for the past 30 years, with no attention from law enforcement at all. R's, John From lyndon at orthanc.ca Tue Dec 5 02:47:42 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 4 Dec 2017 18:47:42 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> Message-ID: <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> > On Dec 4, 2017, at 3:19 AM, Edwin Pers wrote: > > As an anecdotal aside, approx. 70% of incoming portscanners/rdp bots/ssh bots/etc that hit the firewalls at my sites are coming from AWS. > I used to send abuse emails but eventually gave up after receiving nothing beyond "well, aws ip's are dynamic/shared so we can't help you" Last week we found out that Helpscout sends email from AWS servers. Thank you, Helpscout, for forcing me to lift the AWS blocks on my incoming MTAs, that were cutting down my incoming spam scanning load by a factor of two. At least. Note that I work for an email hosting company, which makes this infinitely more annoying. A factor of two, in this case, is a non-trivial number. --lyndon From gtaylor at tnetconsulting.net Tue Dec 5 03:07:26 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 4 Dec 2017 20:07:26 -0700 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171205014637.35806.qmail@ary.lan> References: <20171205014637.35806.qmail@ary.lan> Message-ID: <0f7a39b9-efee-54d6-d449-081c7825cdec@spamtrap.tnetconsulting.net> On 12/04/2017 06:46 PM, John Levine wrote: > Your life appears to be much more exciting than the rest of ours. > > I've been running mail servers in various places including my house > for the past 30 years, with no attention from law enforcement at all. I believe my comment "it took a search warrant" was taken slightly out of context. Nothing like that ever happened. I was meaning to imply that I believe it would be more difficult to access the server at my house than at a co-lo / hosting facility. I'm speaking in the hypothetical with zero experience. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Tue Dec 5 03:21:46 2017 From: johnl at iecc.com (John Levine) Date: 5 Dec 2017 03:21:46 -0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <0f7a39b9-efee-54d6-d449-081c7825cdec@spamtrap.tnetconsulting.net> Message-ID: <20171205032146.36118.qmail@ary.lan> In article <0f7a39b9-efee-54d6-d449-081c7825cdec at spamtrap.tnetconsulting.net> you write: >I was meaning to imply that I believe it would be more difficult to >access the server at my house than at a co-lo / hosting facility. Depends on the hosting facility. My server is in a locked room that used to contain printing presses, so it's pretty sturdy. I expect the hosting provider would be sceptical if someone showed up with a subpoena. For that matter, due to the somewhat informal way the IPs are managed (I'm borrowing a block from a local ISP who doesn't currently need it), it's rather hard to figure out where the server is. See if you can tell me where the host mail.iecc.com is physically located. R's, John From brad at shub-internet.org Tue Dec 5 03:52:16 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 4 Dec 2017 21:52:16 -0600 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <9578293AE169674F9A048B2BC9A081B40273141D24@MUNPRDMBXA1.medline.com> References: <20171204212424.34987.qmail@ary.lan> <60324.1512426049@turing-police.cc.vt.edu> <454FAAEA-2417-4FC8-A3C7-58FBFFF36EC0@shub-internet.org> <6698.1512427877@turing-police.cc.vt.edu> <52CB315A-A305-4B1D-AF46-8DDA49B73F76@shub-internet.org> <9578293AE169674F9A048B2BC9A081B40273141D24@MUNPRDMBXA1.medline.com> Message-ID: On Dec 4, 2017, at 5:22 PM, Naslund, Steve wrote: > There are all kinds of factual issues with the arguments in the referenced document. > > 1. During Desert Storm I personally sent hundreds of STU-IIIs to the sandbox. They didn't go in diplomatic pouches, they went as Air Force cargo like everything else. Maybe not all of them went the way I described, but there were public stories at the time regarding ones that had been sent in diplomatic pouches, and which was confirmed by the government. I wasn't concerned about the STU-IIIs that got sent the "normal" way, and therefore I did not mention them. What really concerned me at the time was that it was totally okay to send them in a wide variety of ways before they were keyed, but they had to be sent via diplomatic pouches once they had been keyed, in order to get around our own export controls regarding munitions. Today, I know a bit more about what "keying" means than I did then, but not much more. I guess if you're using shared secrets everywhere, it becomes really important to protect those shared secrets against everyone, including other members of our own government. > 2. Treason is not applicable here because there must be a declared war. Treason requires interaction with a declared enemy during a time of war. I know that term gets thrown around haphazardly lately but it is a very specific legal term. Okay, so treason was the wrong term. I grant you that. In fact, I granted that in my previous message. Let's get over that word. > 3. Asking a government agency act as the KDF is so demonstrably brain damaged we don't even need to go into the problems with that. They have shown that: At the time, I think it was reasonable to at least mention using a government agency as a Key Escrow agent, if only to point out one possible solution. Key Escrow has had a lot more research since 1992, and we've learned a lot of lessons since then. > 4. Sending a device or technology out of the US does not equal an export under ITAR. In your example, if a device is going to be used by US Government employees or military personnel and kept under their control, it is not an export. As a matter of fact a US company can use export restricted software and hardware in foreign countries in most cases if it is under to control of US Nationals. i.e. US company can use high encryption licenses for Cisco devices inside of China branch offices to secure their VPN connections. My company has this in writing, we did all of the appropriate export paperwork and then was told it was unnecessary since the software remains under the control of US nationals (of course they know that all the foreign intel agencies already have it so they are not worried about James Bond sneaking in the middle of the night to reverse engineer it). The rules regarding the exportation of strong crypto have changed since 1992. Although it now looks like maybe they're soon going to be going back the other direction. However, for the moment, it is still a non-sequitur to apply the rules of exportation under modern law to something that was written in 1992. > 5. The DirNSA has a vested interest in the collection of intelligence and the security of US GOVERNMENT systems as his primary responsibilities. Securing US private entities is way down his list of priorities and if in conflict with his primary missions will take a back seat. Not treason my friend just focus on his mission. I believed at the time that he was causing Very Grave Harm to National Security Interests, through their actions to try to force the standardization on poor encryption algorithms and prohibit the use of strong crypto. As far as that statement goes, I believe that it is as true and applicable today as it was in 1992. -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP URL: From list at satchell.net Tue Dec 5 06:25:13 2017 From: list at satchell.net (Stephen Satchell) Date: Mon, 4 Dec 2017 22:25:13 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <20171204212424.34987.qmail@ary.lan> Message-ID: <1c5b5665-d2a8-1025-19a0-18c4a6dd1954@satchell.net> On 12/04/2017 02:06 PM, Grant Taylor via NANOG wrote: > Namely, when I ran my server at home, it took a search warrant to > legally enter my house to access the server, which I would be > immediately made aware of.  I can't say the same with the same degree of > certainty for a server located in a co-location facility. It takes a search warrant for co-located gear, but the warrants I received as a rack monkey at a Web hosting company were served on the company, not on the customer, and those warrants included gag orders -- I could not inform the customer that his equipment had its hard disk copied. (Now THERE's a story, but you will have to by me beer to hear it.) Mail tap orders? Same deal, had to do narrow captures and not speak a word of it to anyone. (IRS warrant in that case. And if you think I'm violating the gag order, that was 11 years ago.) From list at satchell.net Tue Dec 5 06:55:33 2017 From: list at satchell.net (Stephen Satchell) Date: Mon, 4 Dec 2017 22:55:33 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> Message-ID: <8872ff37-466f-7bb4-4216-184320bd561f@satchell.net> On 12/04/2017 06:47 PM, Lyndon Nerenberg wrote: > Last week we found out that Helpscout sends email from AWS servers. > > Thank you, Helpscout, for forcing me to lift the AWS blocks on my incoming MTAs, that were cutting down my incoming spam scanning load by a factor of two. At least. If I may make a suggestion: rate-limit incoming connections from AWS, with a pinhole for Helpscout. Spammers try only one if they are doing direct SMTP; legit mail servers will retry failed transmissions. I used to do this with Postfix at the edge of a Web host network. (Yes, yes, I know that compromised PHP scripts will inject mail into a real mail server, so rate-limiting only spreads out the pain.) From nanog-amuse at foofus.com Tue Dec 5 07:26:30 2017 From: nanog-amuse at foofus.com (amuse) Date: Mon, 4 Dec 2017 23:26:30 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <8872ff37-466f-7bb4-4216-184320bd561f@satchell.net> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <8872ff37-466f-7bb4-4216-184320bd561f@satchell.net> Message-ID: You can cut down significantly on SPAM by simply dropping any email with a gtld which didn't exist prior to 2001. Give it a try! On Dec 4, 2017 22:57, "Stephen Satchell" wrote: > On 12/04/2017 06:47 PM, Lyndon Nerenberg wrote: > >> Last week we found out that Helpscout sends email from AWS servers. >> >> Thank you, Helpscout, for forcing me to lift the AWS blocks on my >> incoming MTAs, that were cutting down my incoming spam scanning load by a >> factor of two. At least. >> > > If I may make a suggestion: rate-limit incoming connections from AWS, > with a pinhole for Helpscout. Spammers try only one if they are doing > direct SMTP; legit mail servers will retry failed transmissions. > > I used to do this with Postfix at the edge of a Web host network. > > (Yes, yes, I know that compromised PHP scripts will inject mail into a > real mail server, so rate-limiting only spreads out the pain.) > From rsk at gsp.org Tue Dec 5 10:59:18 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 5 Dec 2017 05:59:18 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> Message-ID: <20171205105918.GA8503@gsp.org> On Mon, Dec 04, 2017 at 07:38:18PM -0500, Eric Tykwinski wrote: > Main point I think is mailops comes with a learning curve, and it happens... "Current Peeve: The mindset that the Internet is some sort of school for novice sysadmins and that everyone *not* doing stupid dangerous things should act like patient teachers with the ones who are." --- Bill Cole ---rsk From jared at puck.Nether.net Tue Dec 5 12:08:26 2017 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 5 Dec 2017 07:08:26 -0500 Subject: Akamai contact In-Reply-To: <20171205001424.q6jpgqqnmtmcmmwm@e-fensive.net> References: <20171205001424.q6jpgqqnmtmcmmwm@e-fensive.net> Message-ID: <20171205120826.GA8248@puck.nether.net> replied offlist. ping me if you need something fyi. - jared On Mon, Dec 04, 2017 at 06:14:24PM -0600, J. Oquendo wrote: > Can one of the Akamai (non salesy) guys ping me off list > please. Security related. > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > 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 > > 0A96 6318 EA49 4032 21C9 A7A8 81E9 3E95 414F 356E > https://pgp.mit.edu/pks/lookup?op=get&search=0x81E93E95414F356E -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jjones at danrj.com Tue Dec 5 13:18:21 2017 From: jjones at danrj.com (Jerry Jones) Date: Tue, 5 Dec 2017 07:18:21 -0600 Subject: Small full BGP table capable router with low power consumption In-Reply-To: References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> Message-ID: MX150? On Dec 4, 2017, at 4:13 PM, C. Jon Larsen wrote: On Mon, 4 Dec 2017, Naslund, Steve wrote: FWIW ... OpenBSD on a lanner appliance with openbgpd will chew 1G. Especially on the latest version - 6.2. Debian on the same lanner running bird would also chew that as well. >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin >>> Sent: Monday, December 04, 2017 3:43 PM >>> To: Adam Lawson >>> Cc: nanog >>> Subject: Re: Small full BGP table capable router with low power consumption > >>> On Mon, Dec 4, 2017 at 2:19 PM, Adam Lawson wrote: >>> The router needs to be squeezed in to a rack which doesn't have a lot >>> of space nor power. As for space, maybe I can make space for 3U or 4U >>> but as for power, I can only do around 1.5A at 100V on average. (There is >>> room for burst power usage.) > >> A Cisco 2911 or 3945 does this though the 3945 is a little more power hungry. > >> A current generation x86 server running Linux and Quagga does this. > >> Regards, >> Bill Herrin > > >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: > From ray at oneunified.net Tue Dec 5 14:20:47 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 5 Dec 2017 10:20:47 -0400 Subject: Lanner Devices - NCA-5510 Message-ID: <430a01d36dd4$3f09af50$bd1d0df0$@oneunified.net> Hello, A number of people have been suggesting Lanner boxes for routing. I have used FW-7543A and FW-7573A boxes with Debian with no issues. I am currently trying the NCA-5510 model with NCS2-IGM806B (XL710) and NCS2-IXM407A (I350) cards with a standard Debian Stretch installation. I was hoping that it would be as easy as installing the operating system, turning ports up, and getting a working network. It was like that with the other models. Not with this model. There seems to be a bunch of different BIOS combinations which give different (bad) results. And for the combinations I've tried, I can't seem to get the XL710 card to work properly. Maybe I should have gone with the 82599 card instead. In addition, the I210 based management port also isn't coming up properly, always some sort 'interface reset' error. Which, with some bios settings, I get on the I350 cards as well. If someone has a similar model and/or configuration, what sort of BIOS/Kernel settings have you used to get something operationally stable? Any particular Kernel versions work best? I tried 4.9.51, and 4.14.3. It seems to take about 48 hours to get turn arounds from Taiwan engineering, which I am currently trying to escalate from a sales office, but was hoping, in the meantime, someone else might have some experiences to share? I can provide console / kernel messages to show what I am encountering for those interested. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From EPers at ansencorp.com Tue Dec 5 14:38:21 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Tue, 5 Dec 2017 14:38:21 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> Message-ID: >Last week we found out that Helpscout sends email from AWS servers. Ouch. I'm in the same boat as you are - three of our biggest suppliers have all their public-facing stuff hosted on AWS, including their email smarthosts. None of them have static addresses. >This is incorrect reasoning. Because they're the biggest cloud provider >in the world, they should send the least amount of junk: the larger >an operation is, the easier abuse detection/prevention gets. You'd think so, yes. Somehow Google and DO and most other hosting companies manage to do it. Feels like AWS truly doesn't care about it. From list at satchell.net Tue Dec 5 14:49:43 2017 From: list at satchell.net (Stephen Satchell) Date: Tue, 5 Dec 2017 06:49:43 -0800 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: <20171205105918.GA8503@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: On 12/05/2017 02:59 AM, Rich Kulawiec wrote: > On Mon, Dec 04, 2017 at 07:38:18PM -0500, Eric Tykwinski wrote: >> Main point I think is mailops comes with a learning curve, and it happens... > > "Current Peeve: The mindset that the Internet is some sort of > school for novice sysadmins and that everyone *not* doing stupid > dangerous things should act like patient teachers with the ones > who are." > > --- Bill Cole > > ---rsk > Indeed. What Ajit Pai missed in his deliberations for the Dec 14 FCC vote is that the Internet as we know it was developed under the stern eyes of the Department of Defense and the National Science Foundation. The NSF in particular ran the 'Net like bouncers do in a strip club: you break the rules, you go. No argument. The original trust model for the Internet was based on this unrelenting oversight. You didn't expect Bad Things(tm) because the consequences of doing them was so severe: banishment and exile. Also, the technical ability required to do Bad Things(tm) wasn't easily won. Accessing the 'Net was a PRIVILEGE, not a right. Abuse at your own peril. Organizations had experienced sysadmins because it was imperative to the survival of the connection to the 'Net. One gained experience by being apprenticed to some experienced sysadmin. Today: not so much. Indeed, I'm not aware of any certification that applies to system administrators. Network administrators have certs that are well-recognized and accepted. Mail admins? Server admins? The certs that are out there border on jokes or disguised sale pitches. (Not unlike a certain operating system and software product vendor who put "free" copies into schools to build their marketing base.) Ok, I'll shut up now. From list at satchell.net Tue Dec 5 14:56:58 2017 From: list at satchell.net (Stephen Satchell) Date: Tue, 5 Dec 2017 06:56:58 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> Message-ID: <84a1eda4-2e72-4899-aabf-81830fb4f5fc@satchell.net> On 12/05/2017 06:38 AM, Edwin Pers wrote: > You'd think so, yes. Somehow Google and DO and most other hosting > companies manage to do it. Feels like AWS truly doesn't care about > it. "Never attribute to malice that which is adequately explained by stupidity, ignorance, or negligence." --based on Hanon's Razor "...misunderstandings and neglect create more confusion in this world than trickery and malice. At any rate, the last two are certainly much less frequent." -- Goethe's _The Sorrows of Young Werther_ (1774) From chk at pobox.com Tue Dec 5 16:17:12 2017 From: chk at pobox.com (Harald Koch) Date: Tue, 5 Dec 2017 11:17:12 -0500 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: Thirty years ago I started my sysadmin journey on an Internet that was filled with helpful, experienced people that were willing to share their knowledge. Twenty years ago I was one of three people running CA*net, the cross-Canada research Internet with three connections to the NSFnet. I don't remember this world of banishment and exile you're discussing; the NSFnet staff I dealt with were all friendly and helpful. I plan to continue to "pay it forward", by being friendly and helpful to "novice sysadmins". The curmudgeons in this thread can, frankly, get off my lawn. -- Harald From mike at mtcc.com Tue Dec 5 16:25:13 2017 From: mike at mtcc.com (Michael Thomas) Date: Tue, 5 Dec 2017 08:25:13 -0800 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: <02827674-c6fe-04d2-c12c-6714169f02c5@mtcc.com> On 12/05/2017 08:17 AM, Harald Koch wrote: > Thirty years ago I started my sysadmin journey on an Internet that was > filled with helpful, experienced people that were willing to share their > knowledge. > > Twenty years ago I was one of three people running CA*net, the > cross-Canada research Internet with three connections to the NSFnet. I > don't remember this world of banishment and exile you're discussing; the > NSFnet staff I dealt with were all friendly and helpful. > > I plan to continue to "pay it forward", by being friendly and helpful > to "novice sysadmins". The curmudgeons in this thread can, frankly, get off > my lawn. > Exactly right. If there were some high priesthood for being able to put stuff on the net, there would be no net as we know it. This is a feature, not a bug. Mike From nanog-amuse at foofus.com Mon Dec 4 23:23:58 2017 From: nanog-amuse at foofus.com (amuse) Date: Mon, 4 Dec 2017 15:23:58 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> References: <20171204212424.34987.qmail@ary.lan> <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> Message-ID: I run my own mailserver... ​ On Mon, Dec 4, 2017 at 3:00 PM, Grant Taylor via NANOG wrote: > On 12/04/2017 03:47 PM, Brad Knowles wrote: > >> The concept is sound, but attempting to use your $5 VPS as your outbound >> mail relay is only going to end in pain and tears -- your VPS cannot have >> or build a good enough reputation to get reliable delivery to the big mail >> providers. You need to use an outbound mail relay that already has a good >> reputation, and that works hard to continue to maintain that reputation. >> > > My experience shows otherwise. > > I've been using a VPS as my primary mail server for > 2 years and have > only been black listed once. Even that was a 12 hour automated listing > because I sent one message to an address I had not used in 7 years, which > had since been converted into a spam trap. > > I've also known others that use VPSs for this exact thing with > considerable success. > > As for handling your inbound mail, use something like imapsync and then >> effectively treat your IMAP provider as a POP3 provider instead, and >> download/delete the messages from their system as soon as they have been >> copied to your local system. >> > > Why? Having a different provider handle inbound will require them > supporting your domain(s). Why not handle inbound email directly? > > The bad guys could tap into the stream of mail that flows through that >> system, but they wouldn't be able to get into your archive of old mail >> without breaking into the box sitting in your house. >> > > S/MIME / PGP }:-) > > > > > -- > Grant. . . . > unix || die > > From farhan.shoaib at gmail.com Tue Dec 5 08:17:03 2017 From: farhan.shoaib at gmail.com (Shoaib Farhan) Date: Tue, 5 Dec 2017 14:17:03 +0600 Subject: Any from amazon cloud app.conceptboard.com Message-ID: Hi, Anyone from Amazon Cloud in this list. Need help for app.conceptboard.com. Our client complaining they are getting disconnected from this site. Traceroute/mtr showing path is keep changing. traceroute to app.conceptboard.com (52.17.144.46), 30 hops max, 60 byte packets 1 noc-ut-gw.telnet.net.bd (120.50.31.17) 0.513 ms 0.619 ms 0.677 ms 2 116.212.104.25 (116.212.104.25) 0.842 ms 0.840 ms 0.943 ms 3 DHANMONDI-RTR1-2-BANANI-RTR.TELNET.COM.BD (116.212.104.173) 1.157 ms 1.212 ms 1.274 ms 4 43.224.113.185 (43.224.113.185) 0.974 ms 0.975 ms 0.977 ms 5 43.228.208.17 (43.228.208.17) 1.353 ms 1.355 ms 1.327 ms 6 43.228.208.1 (43.228.208.1) 2.229 ms 1.327 ms 4.002 ms 7 125.17.155.45 (125.17.155.45) 40.688 ms 42.783 ms 40.885 ms 8 182.79.245.18 (182.79.245.18) 170.338 ms 182.79.198.129 (182.79.198.129) 172.306 ms 203.101.100.170 (203.101.100.170) 172.314 ms 9 ams1-br-tra-r2.amazon.com (80.249.210.217) 199.384 ms 199.389 ms 197.153 ms 10 54.239.114.48 (54.239.114.48) 220.252 ms 54.239.114.96 (54.239.114.96) 219.471 ms 54.239.114.36 (54.239.114.36) 226.921 ms 11 54.239.114.65 (54.239.114.65) 222.170 ms 54.239.114.79 (54.239.114.79) 218.172 ms 54.239.114.89 (54.239.114.89) 218.971 ms 12 54.239.41.117 (54.239.41.117) 216.664 ms 54.239.41.119 (54.239.41.119) 216.329 ms 54.239.43.16 (54.239.43.16) 216.342 ms 13 54.239.41.206 (54.239.41.206) 216.650 ms 54.239.44.142 (54.239.44.142) 216.647 ms 216.635 ms 14 * * 54.239.41.204 (54.239.41.204) 215.933 ms 15 52.93.6.148 (52.93.6.148) 237.179 ms 52.93.7.186 (52.93.7.186) 231.180 ms 52.93.6.160 (52.93.6.160) 218.251 ms 16 52.93.7.3 (52.93.7.3) 216.543 ms 52.93.7.31 (52.93.7.31) 212.299 ms 52.93.7.19 (52.93.7.19) 218.105 ms 17 52.93.36.34 (52.93.36.34) 216.943 ms 52.93.7.8 (52.93.7.8) 230.334 ms 52.93.7.10 (52.93.7.10) 235.409 ms 18 52.93.7.101 (52.93.7.101) 218.487 ms 52.93.7.97 (52.93.7.97) 218.505 ms 52.93.7.117 (52.93.7.117) 217.368 ms 19 * * 178.236.0.213 (178.236.0.213) 215.187 ms 20 * * * MT: HOST: farhan.telnet.net.bd Loss% Snt Last Avg Best Wrst StDev 1.|-- noc-ut-gw.telnet.net.bd 0.0% 500 0.5 0.5 0.2 54.8 2.5 2.|-- 116.212.104.25 0.0% 500 0.9 0.8 0.7 1.6 0.0 3.|-- DHANMONDI-RTR1-2-BANANI-R 1.2% 500 0.8 2.0 0.8 187.7 12.6 4.|-- 43.224.113.185 0.0% 500 1.1 3.8 0.9 84.4 10.9 5.|-- 43.228.208.17 0.0% 500 1.2 1.9 1.0 16.7 1.6 6.|-- 43.228.208.1 0.0% 500 4.5 2.3 1.0 95.5 5.7 7.|-- 125.17.155.45 0.0% 500 41.2 42.5 39.9 109.5 6.6 8.|-- 182.79.247.217 0.2% 500 173.8 170.4 169.3 216.0 3.6 9.|-- ams1-br-tra-r2.amazon.com 2.8% 500 201.9 201.6 192.8 222.7 3.3 10.|-- 54.239.114.84 2.2% 500 222.7 224.8 211.8 336.8 9.6 11.|-- 54.239.114.91 1.8% 500 219.0 219.6 208.8 293.0 7.5 12.|-- 54.239.41.119 1.2% 500 218.3 218.1 208.9 257.0 3.9 13.|-- 54.239.44.140 2.2% 500 219.5 219.8 211.6 265.5 3.5 14.|-- ??? 100.0 500 0.0 0.0 0.0 0.0 0.0 15.|-- 52.93.6.136 1.8% 500 222.2 234.4 212.1 382.2 14.0 16.|-- 52.93.7.25 2.6% 500 212.9 218.8 208.9 248.9 4.2 17.|-- 52.93.7.18 2.8% 500 235.3 230.9 214.0 266.2 12.2 18.|-- 52.93.7.115 1.6% 500 217.8 218.0 210.0 244.2 2.4 19.|-- ??? 100.0 500 0.0 0.0 0.0 0.0 0.0 Any help would be appreciated. -- Regards, Md. Shoaib Farhan From rstory at isi.edu Tue Dec 5 02:42:08 2017 From: rstory at isi.edu (Robert Story) Date: Mon, 4 Dec 2017 21:42:08 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> References: <20171204212424.34987.qmail@ary.lan> <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> Message-ID: <20171204214208.088d50e8@titan.int.futz.org> On Mon 2017-12-04 16:00:11-0700 Grant wrote: > I've been using a VPS as my primary mail server for > 2 years and > have only been black listed once. Even that was a 12 hour automated > listing because I sent one message to an address I had not used in 7 > years, which had since been converted into a spam trap. > > I've also known others that use VPSs for this exact thing with > considerable success. I do the same thing, with pretty much the same experience. One initial blacklist hiccup that was easily resolved. I ran my mail server at home for a while, but after a few storm-related outages I switched to a cheap VPS doing store-and-foward. You can also shop around to get some storage (20-50GB) that you can use for remote backups of critical files (encrypted, of course). I find Low End Box is a good resource for finding VPS providers. You will have to pay attention if you want IPv6 support, as it's far from universal. -- Robert Story USC Information Sciences Institute -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bicknell at ufp.org Tue Dec 5 16:33:06 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 5 Dec 2017 08:33:06 -0800 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: <20171205163306.GA16046@ussenterprise.ufp.org> In a message written on Tue, Dec 05, 2017 at 06:49:43AM -0800, Stephen Satchell wrote: > The NSF in particular ran the 'Net like bouncers do in a strip club: > you break the rules, you go. No argument. I'm not sure I've ever seen a more inaccurate description of the NSF. What in the world are you talking about? > The original trust model for the Internet was based on this unrelenting > oversight. You didn't expect Bad Things(tm) because the consequences of > doing them was so severe: banishment and exile. Also, the technical > ability required to do Bad Things(tm) wasn't easily won. Accessing the > 'Net was a PRIVILEGE, not a right. Abuse at your own peril. Oh wait, you took the BS to a new level. There was no banishment and exile. This was before we knew of buffer overflows, spoofing, and so on. I remember the weekly sendmail buffer overrun bugs, the finger back bombs, the rlogin spoofing attacks. Turns out bored college students were very good at creating mischeff. There was no banishment. There were plenty of bad things. > Ok, I'll shut up now. Good plan. -- Leo Bicknell - bicknell at ufp.org 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: not available URL: From lathama at gmail.com Tue Dec 5 16:36:19 2017 From: lathama at gmail.com (Andrew Latham) Date: Tue, 5 Dec 2017 10:36:19 -0600 Subject: Lanner Devices - NCA-5510 In-Reply-To: <430a01d36dd4$3f09af50$bd1d0df0$@oneunified.net> References: <430a01d36dd4$3f09af50$bd1d0df0$@oneunified.net> Message-ID: Raymond Reading that I see the possibility that you could have a bad unit. Verifying with another unit would be great to confirm. Personally I would use something like https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A.cfm where the supply chain can get me parts faster for scale and repair. I just wish these devices would come with some magical industry standard secured DC power connector. On Tue, Dec 5, 2017 at 8:20 AM, Raymond Burkholder wrote: > Hello, > > A number of people have been suggesting Lanner boxes for routing. I have > used FW-7543A and FW-7573A boxes with Debian with no issues. > > I am currently trying the NCA-5510 model with NCS2-IGM806B (XL710) and > NCS2-IXM407A (I350) cards with a standard Debian Stretch installation. > > I was hoping that it would be as easy as installing the operating system, > turning ports up, and getting a working network. It was like that with the > other models. Not with this model. There seems to be a bunch of different > BIOS combinations which give different (bad) results. And for the > combinations I've tried, I can't seem to get the XL710 card to work > properly. Maybe I should have gone with the 82599 card instead. > > In addition, the I210 based management port also isn't coming up properly, > always some sort 'interface reset' error. Which, with some bios settings, > I > get on the I350 cards as well. > > If someone has a similar model and/or configuration, what sort of > BIOS/Kernel settings have you used to get something operationally stable? > Any particular Kernel versions work best? I tried 4.9.51, and 4.14.3. > > It seems to take about 48 hours to get turn arounds from Taiwan > engineering, > which I am currently trying to escalate from a sales office, but was > hoping, > in the meantime, someone else might have some experiences to share? > > I can provide console / kernel messages to show what I am encountering for > those interested. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- - Andrew "lathama" Latham - From eric.kuhnke at gmail.com Tue Dec 5 16:49:25 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 5 Dec 2017 08:49:25 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> References: <20171204212424.34987.qmail@ary.lan> <79883D20-6544-4FB1-93FF-AF00F508B0CA@shub-internet.org> <30a8e68b-a266-1a41-5c6e-b49ea9933535@spamtrap.tnetconsulting.net> Message-ID: In my experience with creating new mail servers that use IP addresses belonging to dedicated hosting/colocation/VPS companies. This is *after* all of the obvious setup things like having a real static IP, A records, PTR records, SPF and DKIM set up proprely, are taken care of so that a public facing smtpd can exchange mail with the world. a) The closer the company is to the lower price end of the market, the more likely the IP space is to be in a bunch of RBL or have "poor" reputation from major mail destinations like gmail and office365. People buy $5/mo VPS for testing stuff and accidentally run open relays, get a whole /24 black listed, and so forth. b) IP space that has been previously used by higher-end dedicated server customers (people who are paying $400/mo for a beefy machine vs. a $35/mo Intel Atom) is proportionally less likely to be in RBLs, is more likely to have abuse contacts at the ISP who will work with RBL operators to get it removed if necessary, and so forth. c) The "best" IP space to run a mail server from is a block that has never had any sort of dedicated server/colo/VPS customers in it whatsoever, and has not had a bunch of random people running smtp daemons in it at some point in the previous 10-15 yers. On Mon, Dec 4, 2017 at 3:00 PM, Grant Taylor via NANOG wrote: > On 12/04/2017 03:47 PM, Brad Knowles wrote: > >> The concept is sound, but attempting to use your $5 VPS as your outbound >> mail relay is only going to end in pain and tears -- your VPS cannot have >> or build a good enough reputation to get reliable delivery to the big mail >> providers. You need to use an outbound mail relay that already has a good >> reputation, and that works hard to continue to maintain that reputation. >> > > My experience shows otherwise. > > I've been using a VPS as my primary mail server for > 2 years and have > only been black listed once. Even that was a 12 hour automated listing > because I sent one message to an address I had not used in 7 years, which > had since been converted into a spam trap. > > I've also known others that use VPSs for this exact thing with > considerable success. > > As for handling your inbound mail, use something like imapsync and then >> effectively treat your IMAP provider as a POP3 provider instead, and >> download/delete the messages from their system as soon as they have been >> copied to your local system. >> > > Why? Having a different provider handle inbound will require them > supporting your domain(s). Why not handle inbound email directly? > > The bad guys could tap into the stream of mail that flows through that >> system, but they wouldn't be able to get into your archive of old mail >> without breaking into the box sitting in your house. >> > > S/MIME / PGP }:-) > > > > > -- > Grant. . . . > unix || die > > From gtaylor at tnetconsulting.net Tue Dec 5 16:54:21 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 5 Dec 2017 09:54:21 -0700 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: On 12/05/2017 09:17 AM, Harald Koch wrote: > Thirty years ago I started my sysadmin journey on an Internet that was > filled with helpful, experienced people that were willing to share their > knowledge. The vast majority of what I've experienced in the last ~20 years has been people willing to help others who are trying to help themselves. If you are trying, make an honest mistake, and are willing to correct it when others politely let you know, you will quite likely find people willing to help you. Especially if you return the favor in kind. If you are being a hooligan and not responding to problems reported to you or purposefully ~> wantonly doing things to others ... good luck. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From eric.kuhnke at gmail.com Tue Dec 5 16:59:37 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 5 Dec 2017 08:59:37 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> Message-ID: It is worth mentioning for those who have not seen a Ubiquiti "edgrouter" in person yet, or worked with one, where their operating system came from... When Vyatta was acquired by Brocade, the core Vyatta team jumped ship and were hired directly by Ubiquiti. When you SSH into one of these whether it's a $45 Edgerouter-X or a $300 unit, it is a Debian based CLI and is very obviously a fork of Vyatta. The entire system file tree and package mangement system is all Debian. On Mon, Dec 4, 2017 at 12:55 PM, Mel Beckman wrote: > The Edgerouter Pro 8 meets all your specs. It's 1U, has eight GigE ports, > including two SFP/combo ports, can take full IPv4 and IPv6 tables, and only > consumes 40 watts (about half an amp at 120V). About $300. > > https://www.ubnt.com/edgemax/edgerouter-pro/ > > -mel beckman > > > On Dec 4, 2017, at 12:46 PM, Adam Lawson wrote: > > > > Hi, > > > > > > > > I'm looking for suggestions on 1U-2U sized router with 1G interface > > > > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > > > > too much power. > > > > > > > > The router needs to be squeezed in to a rack which doesn't > > > > have a lot of space nor power. As for space, maybe I can make > > > > space for 3U or 4U but as for power, I can only do around > > > > 1.5A at 100V on average. (There is room for burst power usage.) > > > > > > > > The following are the one's I can think of: > > > > - Juniper M7i with C-FEB-E (base 1.59A) > > > > - Brocade CER2024F (1.35A) > > > > - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity > > > > - A server with Vyos, vMX or ASR1000v > > > > > > > > Does anyone have other recommendations? > > > > > > > > Thanks, > > > > Adam > > > > > > > > > > > > > > > > > From johnl at iecc.com Tue Dec 5 17:05:20 2017 From: johnl at iecc.com (John Levine) Date: 5 Dec 2017 17:05:20 -0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171205105918.GA8503@gsp.org> Message-ID: <20171205170520.37205.qmail@ary.lan> In article <20171205105918.GA8503 at gsp.org> you write: > "Current Peeve: The mindset that the Internet is some sort of > school for novice sysadmins and that everyone *not* doing stupid > dangerous things should act like patient teachers with the ones > who are." Up to a point. If you ask a reasonable question that shows you've done some homework, you'll get a reasonable answer. On the other hand ... I need to send mail to a million people. But when I send the mail, a lot of it bounces back. How can I tell networks not to censor me? I'ms using Bulk Blaster Pro! Should I use a different program? R's, John From tony at wicks.co.nz Tue Dec 5 17:50:18 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 06:50:18 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> Message-ID: <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> For me the obvious answer for the OP is the Mikrotik CCR range - https://mikrotik.com/product/CCR1036-8G-2Splus -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Wednesday, 6 December 2017 6:00 AM To: nanog at nanog.org list Subject: Re: Small full BGP table capable router with low power consumption From mike.lyon at gmail.com Tue Dec 5 18:07:19 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 5 Dec 2017 10:07:19 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> Message-ID: <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. -Mike > On Dec 5, 2017, at 09:50, wrote: > > For me the obvious answer for the OP is the Mikrotik CCR range - https://mikrotik.com/product/CCR1036-8G-2Splus > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Wednesday, 6 December 2017 6:00 AM > To: nanog at nanog.org list > Subject: Re: Small full BGP table capable router with low power consumption > From tony at wicks.co.nz Tue Dec 5 18:10:04 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 07:10:04 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> Message-ID: <005101d36df4$47882970$d6987c50$@wicks.co.nz> Is that actually still true nowadays ? Of course there is always the option of running RouterOS on an X86 for an effective solution as well. -----Original Message----- From: mike.lyon at gmail.com [mailto:mike.lyon at gmail.com] Sent: Wednesday, 6 December 2017 7:07 AM To: tony at wicks.co.nz Cc: nanog at nanog.org Subject: Re: Small full BGP table capable router with low power consumption Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. -Mike From mike.lyon at gmail.com Tue Dec 5 18:11:27 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 5 Dec 2017 10:11:27 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <005101d36df4$47882970$d6987c50$@wicks.co.nz> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> Message-ID: <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> Unfortunately, yes. Thats why two Juniper M7is just arrived on my doorstep yesterday... > On Dec 5, 2017, at 10:10, wrote: > > Is that actually still true nowadays ? Of course there is always the option of running RouterOS on an X86 for an effective solution as well. > > -----Original Message----- > From: mike.lyon at gmail.com [mailto:mike.lyon at gmail.com] > Sent: Wednesday, 6 December 2017 7:07 AM > To: tony at wicks.co.nz > Cc: nanog at nanog.org > Subject: Re: Small full BGP table capable router with low power consumption > > Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. > > -Mike > > From nanog-amuse at foofus.com Tue Dec 5 18:15:59 2017 From: nanog-amuse at foofus.com (amuse) Date: Tue, 5 Dec 2017 10:15:59 -0800 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: <20171205163306.GA16046@ussenterprise.ufp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171205163306.GA16046@ussenterprise.ufp.org> Message-ID: Back in the day, only Ph.D's used the internet, so they were the sysadmins. These days, I recommend that system administration be only allowed for card-holding responsible people who have proven their technical abilities. Then, when you get awarded your Ph.D, they can take your sysadmin card back. On Tue, Dec 5, 2017 at 8:33 AM, Leo Bicknell wrote: > In a message written on Tue, Dec 05, 2017 at 06:49:43AM -0800, Stephen > Satchell wrote: > > The NSF in particular ran the 'Net like bouncers do in a strip club: > > you break the rules, you go. No argument. > > I'm not sure I've ever seen a more inaccurate description of the NSF. > What in the world are you talking about? > > > The original trust model for the Internet was based on this unrelenting > > oversight. You didn't expect Bad Things(tm) because the consequences of > > doing them was so severe: banishment and exile. Also, the technical > > ability required to do Bad Things(tm) wasn't easily won. Accessing the > > 'Net was a PRIVILEGE, not a right. Abuse at your own peril. > > Oh wait, you took the BS to a new level. > > There was no banishment and exile. This was before we knew of buffer > overflows, spoofing, and so on. I remember the weekly sendmail buffer > overrun bugs, the finger back bombs, the rlogin spoofing attacks. > Turns out bored college students were very good at creating mischeff. > > There was no banishment. There were plenty of bad things. > > > Ok, I'll shut up now. > > Good plan. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From nanog at ics-il.net Tue Dec 5 18:28:36 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 5 Dec 2017 12:28:36 -0600 (CST) Subject: Small full BGP table capable router with low power consumption In-Reply-To: <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> Message-ID: <367319240.9132.1512498512187.JavaMail.mhammett@ThunderFuck> I understand that most BGP implementations are single-threaded. The problem is that it sucks, which version 7 fixes... whenever the unicorn makes that delivery. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "mike lyon" To: tony at wicks.co.nz Cc: nanog at nanog.org Sent: Tuesday, December 5, 2017 12:07:19 PM Subject: Re: Small full BGP table capable router with low power consumption Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. -Mike > On Dec 5, 2017, at 09:50, wrote: > > For me the obvious answer for the OP is the Mikrotik CCR range - https://mikrotik.com/product/CCR1036-8G-2Splus > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Wednesday, 6 December 2017 6:00 AM > To: nanog at nanog.org list > Subject: Re: Small full BGP table capable router with low power consumption > From nanog at ics-il.net Tue Dec 5 18:29:21 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 5 Dec 2017 12:29:21 -0600 (CST) Subject: Small full BGP table capable router with low power consumption In-Reply-To: <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> Message-ID: <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> I'm replacing an M10i with a CHR. I hope you have a newer RE so that you don't have worse BGP convergence than a CCR. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "mike lyon" To: tony at wicks.co.nz Cc: nanog at nanog.org Sent: Tuesday, December 5, 2017 12:11:27 PM Subject: Re: Small full BGP table capable router with low power consumption Unfortunately, yes. Thats why two Juniper M7is just arrived on my doorstep yesterday... > On Dec 5, 2017, at 10:10, wrote: > > Is that actually still true nowadays ? Of course there is always the option of running RouterOS on an X86 for an effective solution as well. > > -----Original Message----- > From: mike.lyon at gmail.com [mailto:mike.lyon at gmail.com] > Sent: Wednesday, 6 December 2017 7:07 AM > To: tony at wicks.co.nz > Cc: nanog at nanog.org > Subject: Re: Small full BGP table capable router with low power consumption > > Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. > > -Mike > > From mfidelman at meetinghouse.net Tue Dec 5 18:31:16 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 5 Dec 2017 11:31:16 -0700 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171205163306.GA16046@ussenterprise.ufp.org> Message-ID: <942ed936-d777-fce4-7919-aaeeae86a40f@meetinghouse.net> Umm.. back in the day, only researchers & engineers used the ARPANET, and secretaries, and administrators, and very quickly lots of military ratings, ... By the time networks were connected to form the Internet, and particularly once university LANs and CANs were connected, you had students, hackers, pretty much all types using the Internet. And among those of us who actually built pieces of the thing, I don't remember a lot of PhDs - to much interesting work to be done for people to stay in school. On 12/5/17 11:15 AM, amuse wrote: > Back in the day, only Ph.D's used the internet, so they were the sysadmins. > > These days, I recommend that system administration be only allowed for > card-holding responsible people who have proven their technical abilities. > Then, when you get awarded your Ph.D, they can take your sysadmin card back. > > On Tue, Dec 5, 2017 at 8:33 AM, Leo Bicknell wrote: > >> In a message written on Tue, Dec 05, 2017 at 06:49:43AM -0800, Stephen >> Satchell wrote: >>> The NSF in particular ran the 'Net like bouncers do in a strip club: >>> you break the rules, you go. No argument. >> I'm not sure I've ever seen a more inaccurate description of the NSF. >> What in the world are you talking about? >> >>> The original trust model for the Internet was based on this unrelenting >>> oversight. You didn't expect Bad Things(tm) because the consequences of >>> doing them was so severe: banishment and exile. Also, the technical >>> ability required to do Bad Things(tm) wasn't easily won. Accessing the >>> 'Net was a PRIVILEGE, not a right. Abuse at your own peril. >> Oh wait, you took the BS to a new level. >> >> There was no banishment and exile. This was before we knew of buffer >> overflows, spoofing, and so on. I remember the weekly sendmail buffer >> overrun bugs, the finger back bombs, the rlogin spoofing attacks. >> Turns out bored college students were very good at creating mischeff. >> >> There was no banishment. There were plenty of bad things. >> >>> Ok, I'll shut up now. >> Good plan. >> >> -- >> Leo Bicknell - bicknell at ufp.org >> PGP keys at http://www.ufp.org/~bicknell/ >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mike.lyon at gmail.com Tue Dec 5 18:35:48 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 5 Dec 2017 10:35:48 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> Message-ID: <09D36701-8E6C-4241-8C1F-2C075AC5DA16@gmail.com> What hardware you running the CHR on? > On Dec 5, 2017, at 10:29, Mike Hammett wrote: > > I'm replacing an M10i with a CHR. > > I hope you have a newer RE so that you don't have worse BGP convergence than a CCR. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "mike lyon" > To: tony at wicks.co.nz > Cc: nanog at nanog.org > Sent: Tuesday, December 5, 2017 12:11:27 PM > Subject: Re: Small full BGP table capable router with low power consumption > > Unfortunately, yes. Thats why two Juniper M7is just arrived on my doorstep yesterday... > >> On Dec 5, 2017, at 10:10, wrote: >> >> Is that actually still true nowadays ? Of course there is always the option of running RouterOS on an X86 for an effective solution as well. >> >> -----Original Message----- >> From: mike.lyon at gmail.com [mailto:mike.lyon at gmail.com] >> Sent: Wednesday, 6 December 2017 7:07 AM >> To: tony at wicks.co.nz >> Cc: nanog at nanog.org >> Subject: Re: Small full BGP table capable router with low power consumption >> >> Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. >> >> -Mike >> >> > From tony at wicks.co.nz Tue Dec 5 18:38:56 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 07:38:56 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> Message-ID: <005301d36df8$4fe2b190$efa814b0$@wicks.co.nz> Yea, as much as I love Juniper Hardware the M series is really a long way on the past at this point. I would suggest the new MX150 is the way to go for up to 20G requirements. Of course that's in a different league from the OP's criteria. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Wednesday, 6 December 2017 7:29 AM Cc: nanog at nanog.org Subject: Re: Small full BGP table capable router with low power consumption I'm replacing an M10i with a CHR. I hope you have a newer RE so that you don't have worse BGP convergence than a CCR. From nanog at ics-il.net Tue Dec 5 18:40:57 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 5 Dec 2017 12:40:57 -0600 (CST) Subject: Small full BGP table capable router with low power consumption In-Reply-To: <09D36701-8E6C-4241-8C1F-2C075AC5DA16@gmail.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> <09D36701-8E6C-4241-8C1F-2C075AC5DA16@gmail.com> Message-ID: <105385572.9158.1512499254792.JavaMail.mhammett@ThunderFuck> It's a couple year old Xeon running vSphere. Once I get some other migrations done, I'll load either vSphere or Proxmox onto the hardware running the Vyatta firewall now and run a CHR there as well for a second upstream. I'm not yet sure what the underlying hardware is for that one. My x86 ROS boxes load full tables in ~30 seconds and maintain hardly any CPU core usage when pulling in updates. I've seen CCRs take 10 minutes to receive and then change routing accordingly for BGP updates (Cogent, HE and several IX peers). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "mike lyon" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, December 5, 2017 12:35:48 PM Subject: Re: Small full BGP table capable router with low power consumption What hardware you running the CHR on? > On Dec 5, 2017, at 10:29, Mike Hammett wrote: > > I'm replacing an M10i with a CHR. > > I hope you have a newer RE so that you don't have worse BGP convergence than a CCR. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "mike lyon" > To: tony at wicks.co.nz > Cc: nanog at nanog.org > Sent: Tuesday, December 5, 2017 12:11:27 PM > Subject: Re: Small full BGP table capable router with low power consumption > > Unfortunately, yes. Thats why two Juniper M7is just arrived on my doorstep yesterday... > >> On Dec 5, 2017, at 10:10, wrote: >> >> Is that actually still true nowadays ? Of course there is always the option of running RouterOS on an X86 for an effective solution as well. >> >> -----Original Message----- >> From: mike.lyon at gmail.com [mailto:mike.lyon at gmail.com] >> Sent: Wednesday, 6 December 2017 7:07 AM >> To: tony at wicks.co.nz >> Cc: nanog at nanog.org >> Subject: Re: Small full BGP table capable router with low power consumption >> >> Bad thing about the CCRs is that their BGP process is single threaded. So even though it has a bunch of cores, it doesn’t utilize them for BGP. >> >> -Mike >> >> > From sam.oduor at gmail.com Tue Dec 5 18:40:57 2017 From: sam.oduor at gmail.com (Sam Oduor) Date: Tue, 5 Dec 2017 21:40:57 +0300 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: Subject of interest; my 15 years experience I met a blend of senior admins while learning the curves ...... 1. Those who denied you knowledge/handover due to insecurity 2. Those who fed you with knowledge but were rude and could make you feel like you undergoing some military training 3. Those who gave you manuals and told you go and read; hardcopy was a common thing - I could deliberately stay back in the office and print a whole library :-) 4. The rare breed that walked you through sysadmins ! Right now it seems the tables have turned around; I already feel I have come to the end of the road as sysadmin but on a lighter note - I have been working hard on passing knowledge down and this are the new blend of people I have met. 1. Those willing to learn are very obedient but for some reason not up to the task 2. Those who know everything you try to teach them; are kinda rude and they bring down systems - lab systems 3. Those who commit to be taught but never show up for free lessons despite offering them free lunch :-) 4. A rare young breed that teaches me mobile apps and new games online - the 90's champs ! 5. A rare breed that goes the extra mile; sacrifice time and money to learn ! I love 4 & 5 ! On Tue, Dec 5, 2017 at 7:54 PM, Grant Taylor via NANOG wrote: > On 12/05/2017 09:17 AM, Harald Koch wrote: > >> Thirty years ago I started my sysadmin journey on an Internet that was >> filled with helpful, experienced people that were willing to share their >> knowledge. >> > > The vast majority of what I've experienced in the last ~20 years has been > people willing to help others who are trying to help themselves. > > If you are trying, make an honest mistake, and are willing to correct it > when others politely let you know, you will quite likely find people > willing to help you. Especially if you return the favor in kind. > > If you are being a hooligan and not responding to problems reported to you > or purposefully ~> wantonly doing things to others ... good luck. > > > > -- > Grant. . . . > unix || die > > -- Samson Oduor From adlawson at zoho.com Tue Dec 5 18:44:03 2017 From: adlawson at zoho.com (Adam Lawson) Date: Tue, 05 Dec 2017 10:44:03 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> Hi, Thanks for all the replies. I think the options that came up are: - Mikrotiks This fits my requirements pretty nicely, however as Mike pointed out the single threaded BGP is a bit of concern. Also, just that I'm not a very big fan of the /xxx Mikrotik CLI. - EdgeRouter Pros, Juniper M7i - A server with bgpd running - Cisco 4300-4400 series Both the above would work nicely. - Cisco 2900s Can these handle full BGP tables as of today? - Juniper MXs The reason I wrote M7i instead of the MX was I far as I looked on the Juniper site, it seems to use more power than the M7i (though you get more performance). - Nokia IXR-R6 (not IXR-6) - Huawei NE20E-S2E I need to look these up. I'm guessing the Nokia has same CLIs as Alcatels. Thanks, Adam ---- On Mon, 04 Dec 2017 11:19:14 -0800 Adam Lawson wrote ---- > Hi, > > I'm looking for suggestions on 1U-2U sized router with 1G interface > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > too much power. > > The router needs to be squeezed in to a rack which doesn't > have a lot of space nor power. As for space, maybe I can make > space for 3U or 4U but as for power, I can only do around > 1.5A at 100V on average. (There is room for burst power usage.) > > The following are the one's I can think of: > - Juniper M7i with C-FEB-E (base 1.59A) > - Brocade CER2024F (1.35A) > - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity > - A server with Vyos, vMX or ASR1000v > > Does anyone have other recommendations? > > Thanks, > Adam > > > From sethm at rollernet.us Tue Dec 5 18:47:05 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 5 Dec 2017 10:47:05 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <367319240.9132.1512498512187.JavaMail.mhammett@ThunderFuck> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <367319240.9132.1512498512187.JavaMail.mhammett@ThunderFuck> Message-ID: <4644ca59-6e66-1e91-263c-f8b527aa2456@rollernet.us> On 12/5/17 10:28 AM, Mike Hammett wrote: > I understand that most BGP implementations are single-threaded. Well, yeah. That's where the "lots of slow cores" model doesn't work. ~Seth From tony at wicks.co.nz Tue Dec 5 19:00:02 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 08:00:02 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> Message-ID: <005501d36dfb$42b89bd0$c829d370$@wicks.co.nz> - Juniper MXs The reason I wrote M7i instead of the MX was I far as I looked on the Juniper site, it seems to use more power than the M7i (though you get more performance). The M150 has just been released, if its within the budget I wold suggest it will very nicely fit the requirement with its 1U form factor and 365W draw. - https://www.juniper.net/us/en/products-services/routing/mx-series/mx150/ From tony at wicks.co.nz Tue Dec 5 19:04:25 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 08:04:25 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <9acb2723-1d3f-3653-c0d9-4a7c44b54622@internet.ee> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> <005301d36df8$4fe2b190$efa814b0$@wicks.co.nz> <9acb2723-1d3f-3653-c0d9-4a7c44b54622@internet.ee> Message-ID: <005701d36dfb$df511c10$9df35430$@wicks.co.nz> No, not actually seen one in real life yet. Interesting thing of course is it runs VMX JunOS code. -----Original Message----- From: Georg Kahest [mailto:georg.kahest at internet.ee] Sent: Wednesday, 6 December 2017 8:01 AM To: tony at wicks.co.nz; nanog at nanog.org Subject: Re: Small full BGP table capable router with low power consumption Have you played around with mx150 yet? It seems very appealing on paper, but as of its so new i have my doubts.... From mfidelman at meetinghouse.net Tue Dec 5 19:23:41 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 5 Dec 2017 12:23:41 -0700 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: And then, let's not forget the BOFH! (http://www.bofharchive.com), and Mordac. On 12/5/17 11:40 AM, Sam Oduor wrote: > Subject of interest; my 15 years experience I met a blend of senior admins > while learning the curves ...... > > 1. Those who denied you knowledge/handover due to insecurity > > 2. Those who fed you with knowledge but were rude and could make you feel > like you undergoing some military training > > 3. Those who gave you manuals and told you go and read; hardcopy was a > common thing - I could deliberately stay back in the office and print a > whole library :-) > > 4. The rare breed that walked you through sysadmins ! > > > Right now it seems the tables have turned around; I already feel I have > come to the end of the road as sysadmin but on a lighter note - I have been > working hard on passing knowledge down and this are the new blend of people > I have met. > > 1. Those willing to learn are very obedient but for some reason not up to > the task > > 2. Those who know everything you try to teach them; are kinda rude and they > bring down systems - lab systems > > 3. Those who commit to be taught but never show up for free lessons despite > offering them free lunch :-) > > 4. A rare young breed that teaches me mobile apps and new games online - > the 90's champs ! > > 5. A rare breed that goes the extra mile; sacrifice time and money to learn > ! > > > I love 4 & 5 ! > > > > > > > On Tue, Dec 5, 2017 at 7:54 PM, Grant Taylor via NANOG > wrote: > >> On 12/05/2017 09:17 AM, Harald Koch wrote: >> >>> Thirty years ago I started my sysadmin journey on an Internet that was >>> filled with helpful, experienced people that were willing to share their >>> knowledge. >>> >> The vast majority of what I've experienced in the last ~20 years has been >> people willing to help others who are trying to help themselves. >> >> If you are trying, make an honest mistake, and are willing to correct it >> when others politely let you know, you will quite likely find people >> willing to help you. Especially if you return the favor in kind. >> >> If you are being a hooligan and not responding to problems reported to you >> or purposefully ~> wantonly doing things to others ... good luck. >> >> >> >> -- >> Grant. . . . >> unix || die >> >> > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bill at herrin.us Tue Dec 5 19:31:59 2017 From: bill at herrin.us (William Herrin) Date: Tue, 5 Dec 2017 14:31:59 -0500 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: On Tue, Dec 5, 2017 at 9:49 AM, Stephen Satchell wrote: > the Internet as we know it was developed under the stern eyes of the > Department of Defense and the National Science Foundation. The NSF in > particular ran the 'Net like bouncers do in a strip club: you break the > rules, you go. No argument. > > The original trust model for the Internet was based on this unrelenting > oversight. You didn't expect Bad Things(tm) because the consequences of > doing them was so severe: banishment and exile. Hi Stephen, Granted I was a late arrival in 1991, but I don't recall much in the way of oversight... or banishment. I do recall that the '88 Morris worm resulted in 400 hours of community service and a tenured professorship at MIT. I suppose the latter could be considered a severe consequence. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From me at colinbaker.net Tue Dec 5 20:34:57 2017 From: me at colinbaker.net (Colin Baker) Date: Tue, 5 Dec 2017 14:34:57 -0600 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> Message-ID: <056e149baae56522b4496bcb258c587a@colinbaker.net> On 2017-12-05 12:44, Adam Lawson wrote: > Hi, > > Thanks for all the replies. > > I think the options that came up are: > > > > - Juniper MXs > The reason I wrote M7i instead of the MX was I far as I looked on the > Juniper > site, it seems to use more power than the M7i (though you get more > performance). RE-800 are so slow that I've had numerous instances where I've made a change, banged my head on the desk for several minutes trying to figure out why it isn't working, and then realize that the control plane was still thinking about it. It will take full tables though, barely, and eventually. Imagine the RE-1800s are fine, haven't used one personally. C-FEB-E should have plenty of room for your FIB. What's the application? I'll throw a somewhat oddball option out there - you can fit full tables into RIB on many Juniper EX switches. Limited use cases for sure, but it can be handy if you can limit what's installed into FIB. -- "640K ought to be enough for anybody." -Kurt Cobain From mark at exonetric.com Tue Dec 5 21:02:47 2017 From: mark at exonetric.com (Mark Blackman) Date: Tue, 5 Dec 2017 21:02:47 +0000 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> Message-ID: <2D15D78F-27E0-43B8-82CD-167AC3FC5B51@exonetric.com> > On 4 Dec 2017, at 19:19, Adam Lawson wrote: > > Hi, > > > > I'm looking for suggestions on 1U-2U sized router with 1G interface > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > too much power. > > > > The router needs to be squeezed in to a rack which doesn't > have a lot of space nor power. As for space, maybe I can make > space for 3U or 4U but as for power, I can only do around > 1.5A at 100V on average. (There is room for burst power usage.) > > > > The following are the one's I can think of: > - Juniper M7i with C-FEB-E (base 1.59A) > - Brocade CER2024F (1.35A) > - Mikrotik CCR, UBNT EdgeRouter Pro/Infinity > - A server with Vyos, vMX or ASR1000v > > Does anyone have other recommendations? A low-power rack mount x86 box running one of (Free|Open|Net)BSD and OpenBGPd? - Mark From tony at wicks.co.nz Tue Dec 5 21:22:09 2017 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Wed, 6 Dec 2017 10:22:09 +1300 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <056e149baae56522b4496bcb258c587a@colinbaker.net> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> <056e149baae56522b4496bcb258c587a@colinbaker.net> Message-ID: <007e01d36e0f$1cc9fa40$565deec0$@wicks.co.nz> What's the application? I'll throw a somewhat oddball option out there - you can fit full tables into RIB on many Juniper EX switches. Limited use cases for sure, but it can be handy if you can limit what's installed into FIB. Fixed format EX's range max out at 128k routes, definitely not an option there unless I am really missing something. I often use EX/QFX for l3, but no way they come anywhere near a full table. From me at colinbaker.net Tue Dec 5 21:43:49 2017 From: me at colinbaker.net (Colin Baker) Date: Tue, 5 Dec 2017 15:43:49 -0600 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <007e01d36e0f$1cc9fa40$565deec0$@wicks.co.nz> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <16027fdf7e1.b02a969f4294.7105543959770862370@zoho.com> <056e149baae56522b4496bcb258c587a@colinbaker.net> <007e01d36e0f$1cc9fa40$565deec0$@wicks.co.nz> Message-ID: On 2017-12-05 15:22, tony at wicks.co.nz wrote: > > Fixed format EX's range max out at 128k routes, definitely not an > option > there unless I am really missing something. I often use EX/QFX for l3, > but > no way they come anywhere near a full table. yep :) set routing-options maximum-prefixes biggernumberthan128k again, RIB only -- "640K ought to be enough for anybody." -Kurt Cobain From pozar at lns.com Tue Dec 5 22:46:45 2017 From: pozar at lns.com (Tim Pozar) Date: Tue, 5 Dec 2017 14:46:45 -0800 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: Should have an honorary list of great sysadmins. In my years of doing this sort of work, I found a number of folks that would lend a helping hand. To that, I would like to nominate: Strata Rose Chalup ------------------ Strata Rose Chalup began as a novice sysadmin in 1983 and has been leading and managing complex IT projects ever since. She is a co-author of The Practice of System and Network Administration and has taught at USENIX Annual Tech and LISA for many years. Strata is always looking at new technologies and is currently enjoying learning the Arduino microcontroller platform. [text from her USENIX conference page] On 12/5/17 11:23 AM, Miles Fidelman wrote: > And then, let's not forget the BOFH! (http://www.bofharchive.com), and > Mordac. > > > On 12/5/17 11:40 AM, Sam Oduor wrote: >> Subject of interest; my 15 years experience I met a blend of senior >> admins >> while learning the curves ...... >> >> 1. Those who denied you knowledge/handover due to insecurity >> >> 2. Those who fed you with knowledge but were rude and could make you feel >> like you undergoing some military training >> >> 3. Those who gave you manuals and told you go and read; hardcopy was a >> common thing - I could deliberately stay back in the office and print a >> whole library :-) >> >> 4. The rare breed that walked you through sysadmins ! >> >> >> Right now it seems the tables have turned around; I already feel I have >> come to the end of the road as sysadmin but on a lighter note - I have >> been >> working hard on passing knowledge down and this are the new blend of >> people >> I have met. >> >> 1. Those willing to learn are very obedient but for some reason not up to >> the task >> >> 2. Those who know everything you try to teach them; are kinda rude and >> they >> bring down systems - lab systems >> >> 3. Those who commit to be taught but never show up for free lessons >> despite >> offering them free lunch :-) >> >> 4. A rare young  breed that teaches me mobile apps and new games online - >> the 90's champs ! >> >> 5. A rare breed that goes the extra mile; sacrifice time and money to >> learn >> ! >> >> >> I love 4 & 5 ! >> >> >> >> >> >> >> On Tue, Dec 5, 2017 at 7:54 PM, Grant Taylor via NANOG >> wrote: >> >>> On 12/05/2017 09:17 AM, Harald Koch wrote: >>> >>>> Thirty years ago I started my sysadmin journey on an Internet that was >>>> filled with helpful, experienced people that were willing to share >>>> their >>>> knowledge. >>>> >>> The vast majority of what I've experienced in the last ~20 years has >>> been >>> people willing to help others who are trying to help themselves. >>> >>> If you are trying, make an honest mistake, and are willing to correct it >>> when others politely let you know, you will quite likely find people >>> willing to help you.  Especially if you return the favor in kind. >>> >>> If you are being a hooligan and not responding to problems reported >>> to you >>> or purposefully ~> wantonly doing things to others ... good luck. >>> >>> >>> >>> -- >>> Grant. . . . >>> unix || die >>> >>> >> > From surfer at mauigateway.com Tue Dec 5 23:11:27 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 5 Dec 2017 15:11:27 -0800 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) Message-ID: <20171205151127.22D8BC91@m0117458.ppops.net> --- list at satchell.net wrote: From: Stephen Satchell Indeed, I'm not aware of any certification that applies to system administrators. Network administrators have certs that are well-recognized and accepted. Mail admins? Server admins? The certs that are out there border on jokes or disguised sale pitches. --------------------------------------- Have you seen neteng certs lately? I'm forced to maintain a lower level one to keep my job and it makes me angry every time I have to do it. The sales pitch is hidden in the words and the correct answer is almost always something that has to do with the proprietary item the vendor has. scott From bill at herrin.us Wed Dec 6 00:09:45 2017 From: bill at herrin.us (William Herrin) Date: Tue, 5 Dec 2017 19:09:45 -0500 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: <20171205151127.22D8BC91@m0117458.ppops.net> References: <20171205151127.22D8BC91@m0117458.ppops.net> Message-ID: On Tue, Dec 5, 2017 at 6:11 PM, Scott Weeks wrote: > Have you seen neteng certs lately? I'm forced to maintain a > lower level one to keep my job and it makes me angry every > time I have to do it. The sales pitch is hidden in the words > and the correct answer is almost always something that has to > do with the proprietary item the vendor has. Even the relatively good ones are bad. I have identified 60 and am on track to identify about 200 errors in the official ISC2 CISSP study guide. "However, UDP should only be used when the delivery of data is not essential" List of Layer 5 (Session) protocols: NFS SQL RPC Regarding IPv6 SLAAC: "Autoconfiguration removes the need for both DHCP and NAT." "A static packet-filtering firewall [is unable] to tell whether a packet originated from inside or outside the private network." "Examples of dedicated lines: Technology, Connection Type, Speed Digital Signal Level 0 (DS-0), Partial T1, 64 Kbps up to 1.544 Mbps Digital Signal Level 1 (DS-1), T1, 1.544 Mbps" "The web application then switches to a subject role as it queries the user's computer to retrieve a cookie" "Plenum-grade cable must be used [...] if the building has enclosed spaces that could trap gases." Stop. No. Just no. Plenum-grade cable must be used in a -plenum-. A plenum is an air-handling space like the inside of a furnace duct. The only reason we care about plenum cable in our jobs is that most offices take a shortcut and turn the entire area above the ceiling tiles in to a giant return-air duct for the air conditioner. That's why the return-air grill is simply open into the ceiling. If you burn crap in an air-handling space, the fumes aren't trapped: they almost immediately spread throughout the office. That's bad, so we use different cable than what we put under the desk where the fumes will tend to stay near where they started. Trap gases? No! Plenum is for where the gases would quickly spread! Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From surfer at mauigateway.com Wed Dec 6 02:05:41 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 5 Dec 2017 18:05:41 -0800 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) Message-ID: <20171205180541.22D8B454@m0117458.ppops.net> --- bill at herrin.us wrote: From: William Herrin Even the relatively good ones are bad. I have identified 60 and am on track to identify about 200 errors in the official ISC2 CISSP study guide. ----------------------------------------- One last one I promise... :-) I also have to maintain a Security+ cert, which is part of the CISSP. I absolutely despise the number of incorrect answers and misinformation that cert puts out. After I'm done taking that one everyone leaves me alone for the rest of the afternoon... >:-( I would not consider the Security+ a 'relatively good one'. Rather, it's one of the worst I have ever had to do! scott From nanog at ics-il.net Wed Dec 6 02:06:28 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 5 Dec 2017 20:06:28 -0600 (CST) Subject: Qrator Radar - Peerings In-Reply-To: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> Message-ID: <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> Does anyone use this site much? Has something happened to reduce their visibility? I've noticed multiple networks that had massive drops in peerings on or around March 11, 2017. AS5650 went from 66 to 12. AS53828 went from 436 to 19. PCH's AS3856 looking glass still reports adjacencies to both of those ASes. AS3856 went from 183 adjacencies to 113 that same day (and didn't bounce back). It seems rather unlikely that PCH would lose that much, given that their goal is to collect route table information. Even more odd that those two ASNs would also lose a ton of peers the same day. Thoughts? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From mike.lyon at gmail.com Wed Dec 6 03:48:16 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 5 Dec 2017 19:48:16 -0800 Subject: Any Megapath / GTT clue? Message-ID: <2D9A541A-61B0-4B94-A807-870E223CB45C@gmail.com> Getting no where with the front end support @ Megapath. /28 suddenly is no longer being routed to my client. Any help would be appreciated. Thank You, Mike From pkranz at unwiredltd.com Wed Dec 6 04:11:10 2017 From: pkranz at unwiredltd.com (Peter Kranz) Date: Tue, 5 Dec 2017 20:11:10 -0800 Subject: Equinix SV8 Facebook IPv6 router 2001:504:D::47/64 constantly bouncing sessions Message-ID: <021c01d36e48$3f6c7710$be456530$@unwiredltd.com> Are other SV8 peering exchange participants seeing problems with Facebooks 2001:504:D::47/64 router in the SV8? Been seeing this for over 48 hours now. No issues with other SV8 peers, or Facebooks other IPv6 router in the facility. Dec  5 18:52:00: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down BGP Notification sent Dec  5 18:53:40: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 18:55:07: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 18:58:42: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:00:12: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 19:09:41: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:11:08: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 19:16:21: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:17:47: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 19:18:54: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:20:24: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down BGP Notification sent Dec  5 19:40:58: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:43:14: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down BGP Notification sent Dec  5 19:47:03: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:48:51: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down BGP Notification sent Dec  5 19:50:54: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:52:21: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 19:53:44: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:55:11: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down NSF peer closed the session Dec  5 19:55:57: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Up Dec  5 19:57:27: %BGP-5-ADJCHANGE: neighbor 2001:504:D::47 Down BGP Notification sent Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From yang.yu.list at gmail.com Wed Dec 6 07:11:48 2017 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 5 Dec 2017 23:11:48 -0800 Subject: Qrator Radar - Peerings In-Reply-To: <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> References: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> Message-ID: Have you received a response from qrator? My guess is that they dropped a BGP collector session that was advertising garbage (modifying AS path to make non-connected ASNs appear connected). >most ASNs left permanently on at 2017-03-11 21:00:00 were never connected https://radar.qrator.net/as11537/peerings#startDate=2017-03-06&endDate=2017-03-15&tab=left Yang On Tue, Dec 5, 2017 at 6:06 PM, Mike Hammett wrote: > Does anyone use this site much? Has something happened to reduce their visibility? > > I've noticed multiple networks that had massive drops in peerings on or around March 11, 2017. AS5650 went from 66 to 12. AS53828 went from 436 to 19. PCH's AS3856 looking glass still reports adjacencies to both of those ASes. AS3856 went from 183 adjacencies to 113 that same day (and didn't bounce back). It seems rather unlikely that PCH would lose that much, given that their goal is to collect route table information. Even more odd that those two ASNs would also lose a ton of peers the same day. > > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > From rsk at gsp.org Wed Dec 6 10:52:34 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 6 Dec 2017 05:52:34 -0500 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: <20171206105234.GA21262@gsp.org> On Tue, Dec 05, 2017 at 09:54:21AM -0700, Grant Taylor via NANOG wrote: > The vast majority of what I've experienced in the last ~20 years has been > people willing to help others who are trying to help themselves. "Help will always be given at Hogwarts to those who ask for it." > If you are trying, make an honest mistake, and are willing to correct it > when others politely let you know, you will quite likely find people willing > to help you. Especially if you return the favor in kind. Yes. That's how we all get better at this. And when any of us learn, we all benefit, so it's in our mutual best interest to share knowledge. (I've learned more here than I can measure. And I'm grateful for it.) > If you are being a hooligan and not responding to problems reported to you > or purposefully ~> wantonly doing things to others ... good luck. And the latter is the problem: we are faced, unfortunately, with massive operations that were designed, built, and deployed without the slightest consideration for responsible behavior toward the rest of the Internet. All the rest of us are paying the price for that arrogance, incompetence and negligence: we're paying for it with DoS/DDoS defenses, with spam and phish defenses, with brute-force attack defenses, with time and money and computing resources, with complexity, with late nights and early mornings, with annoyed customers, and -- on the occasions when those defenses fail -- devastating consequences for organizations and people. These costs aren't always obvious because they're not highlighted line items in an accounting statement. But they're real, and they're huge. How huge? Well, one measure could be found in the observation that there's now an entire -- large and growing -- market segment that exists solely to mitigate the fallout from these operations. And those same massive operations are doing everything they possibly can to avoid hearing about any of this. That's why abuse@ is effectively hardwired to /dev/null. And I note with interest that nobody from AWS has had the professionalism to show up in this thread and say "Gosh, we're sorry. We screwed up. We'll try to do better. Can you help us?" Because we would. ---rsk From kmedcalf at dessus.com Wed Dec 6 12:17:28 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 06 Dec 2017 05:17:28 -0700 Subject: Novice sysadmins In-Reply-To: <20171206105234.GA21262@gsp.org> Message-ID: <6b938683db03c4498f54ab9959d3e6d0@mail.dessus.com> On Wednesday, 6 December, 2017 03:53, Rich Kulawiec wrote: >On Tue, Dec 05, 2017 at 09:54:21AM -0700, Grant Taylor via NANOG >wrote: >> If you are trying, make an honest mistake, and are willing to >> correct it when others politely let you know, you will quite >> likely find people willing to help you. Especially if you >> return the favor in kind. >Yes. That's how we all get better at this. And when any of us >learn, we all benefit, so it's in our mutual best interest to >share knowledge. >(I've learned more here than I can measure. And I'm grateful for >it.) >> If you are being a hooligan and not responding to problems >> reported to you or purposefully ~> wantonly doing things >> to others ... good luck. >And the latter is the problem: we are faced, unfortunately, >with massive operations that were designed, built, and deployed >without the slightest consideration for responsible behavior >toward the rest of the Internet. And here for all these years a thought the bargain was that you agree to carry my traffic without molestation and in return I covenant not to molest your infrastructure or create a nuisance or mess that you have to mitigate or clean up. Of late this thinking seems to have gone mostly by the wayside. It used to be that only the deliberate/wonton transgressors violated that covenant, however, it seems that molestation and nuisance creation have been spreading like an epidemic for a number of years. In fact it is quite common these days that if one brings up in discussion that to act in a certain manner would create a nuisance that others have to clean up and therefore you need to take special precautions to not create the nuisance in the first place, seems all too often be a cause for derision which, in my experience, results in not being invited to participate further. It also seems quite common that when these people then go ahead with their ill-conceived plans and obtain the result you told them would accrue, they act all surprised and astonished. The "Well, I did warn you" usually does not go over too well. From nanog at ics-il.net Wed Dec 6 12:41:58 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 6 Dec 2017 06:41:58 -0600 (CST) Subject: Qrator Radar - Peerings In-Reply-To: References: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> Message-ID: <1888817684.546.1512564117732.JavaMail.mhammett@ThunderFuck> I haven't brought it up with them, no. I didn't think it was a mass issue until last night. I wanted to check with other users before I went to them. Maybe I should have done the opposite. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Yang Yu" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, December 6, 2017 1:11:48 AM Subject: Re: Qrator Radar - Peerings Have you received a response from qrator? My guess is that they dropped a BGP collector session that was advertising garbage (modifying AS path to make non-connected ASNs appear connected). >most ASNs left permanently on at 2017-03-11 21:00:00 were never connected https://radar.qrator.net/as11537/peerings#startDate=2017-03-06&endDate=2017-03-15&tab=left Yang On Tue, Dec 5, 2017 at 6:06 PM, Mike Hammett wrote: > Does anyone use this site much? Has something happened to reduce their visibility? > > I've noticed multiple networks that had massive drops in peerings on or around March 11, 2017. AS5650 went from 66 to 12. AS53828 went from 436 to 19. PCH's AS3856 looking glass still reports adjacencies to both of those ASes. AS3856 went from 183 adjacencies to 113 that same day (and didn't bounce back). It seems rather unlikely that PCH would lose that much, given that their goal is to collect route table information. Even more odd that those two ASNs would also lose a ton of peers the same day. > > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > From ESundberg at nitelusa.com Wed Dec 6 13:25:59 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 6 Dec 2017 13:25:59 +0000 Subject: Any Megapath / GTT clue? In-Reply-To: <2D9A541A-61B0-4B94-A807-870E223CB45C@gmail.com> References: <2D9A541A-61B0-4B94-A807-870E223CB45C@gmail.com> Message-ID: Ask to work with their CRT Team, Level 3/Tier 3 team Also any time there is an issue on Megpaths network, ask them to open a NST ticket. Everything on Megapath's network is auto provisioned. With megapath keep on escalating until you get someone that understands what you are talking about. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of mike.lyon at gmail.com Sent: Tuesday, December 5, 2017 9:48 PM To: NANOG list Subject: Any Megapath / GTT clue? Getting no where with the front end support @ Megapath. /28 suddenly is no longer being routed to my client. Any help would be appreciated. Thank You, Mike From EPers at ansencorp.com Wed Dec 6 14:11:28 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 6 Dec 2017 14:11:28 +0000 Subject: WiFi - login page redirection not working In-Reply-To: <0BFF9277-D9E0-4196-A853-66AAE84CF776@delong.com> References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> <98ae50fd-dda4-febe-5120-7585847dac2a@nvcube.net> <871skeod7s.fsf@luffy.cx> <0BFF9277-D9E0-4196-A853-66AAE84CF776@delong.com> Message-ID: <7c0f394f6f284f1e8dcf80aed432a450@ansencorp.com> RHEL comes with it installed and enabled by default, so it can't be that bad /s -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Friday, December 1, 2017 12:12 PM To: Vincent Bernat Cc: nanog at nanog.org Subject: Re: WiFi - login page redirection not working > On Dec 1, 2017, at 04:16 , Vincent Bernat wrote: > > ❦ 1 décembre 2017 15:02 +0300, Nikolay Shopik : > >>> DHCP and neighbor discovery can also provide the information of the >>> login page: https://tools.ietf.org/html/rfc7710 >> >> I don't think it got support in any os. > > It's supported on Linux by Network Manager. Oh, you mean the first software anyone with clue turns off as soon as they can because of all the problems it causes for networking? Owen From job at instituut.net Wed Dec 6 14:47:42 2017 From: job at instituut.net (Job Snijders) Date: Wed, 06 Dec 2017 14:47:42 +0000 Subject: Qrator Radar - Peerings In-Reply-To: <1888817684.546.1512564117732.JavaMail.mhammett@ThunderFuck> References: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> <1888817684.546.1512564117732.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 6 Dec 2017 at 15:42, Mike Hammett wrote: > I haven't brought it up with them, no. I didn't think it was a mass issue > until last night. I wanted to check with other users before I went to them. > Maybe I should have done the opposite. Yes, you should’ve. The Qrator folks are good people. Kind regards, Job From la at qrator.net Wed Dec 6 15:12:28 2017 From: la at qrator.net (Alexander Lyamin) Date: Wed, 6 Dec 2017 18:12:28 +0300 Subject: Qrator Radar - Peerings In-Reply-To: <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> References: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> Message-ID: Yep. We're the ones to blame. There is known bug. Give us couple more days. Would normally take few hours to fix, but we have Peering Forum on hands. P.S. There is CONTACT US button on page to report bugs, way more reliable way to submit bugs and additional thanks to Job for pointing me up to this thread. On Wed, Dec 6, 2017 at 5:06 AM, Mike Hammett wrote: > Does anyone use this site much? Has something happened to reduce their > visibility? > > I've noticed multiple networks that had massive drops in peerings on or > around March 11, 2017. AS5650 went from 66 to 12. AS53828 went from 436 to > 19. PCH's AS3856 looking glass still reports adjacencies to both of those > ASes. AS3856 went from 183 adjacencies to 113 that same day (and didn't > bounce back). It seems rather unlikely that PCH would lose that much, given > that their goal is to collect route table information. Even more odd that > those two ASNs would also lose a ton of peers the same day. > > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From laurens at daemon.be Tue Dec 5 16:33:12 2017 From: laurens at daemon.be (Laurens Vets) Date: Tue, 05 Dec 2017 08:33:12 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: Message-ID: <5dadaf1eb757b8b5337e457a6e07173e@daemon.be> On 2017-12-02 10:35, Michael S. Singh wrote: > Hi all, > > I am in need of some suggestions for some privacy conscious email > providers. I am currently using Migadu email hosting from Switzerland, > basically they allow their users to have as many domains and mailboxes > without storage limits without extra cost. > > However they only allow 10 messages to be sent per day on their free > tier. https://protonmail.com/ ? From robert at gdk.org Tue Dec 5 18:16:07 2017 From: robert at gdk.org (Robert Bays) Date: Tue, 5 Dec 2017 10:16:07 -0800 Subject: Small full BGP table capable router with low power consumption In-Reply-To: References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> Message-ID: <50617B69-2635-40C4-A930-9A1C2C13D566@gdk.org> > On Dec 5, 2017, at 8:59 AM, Eric Kuhnke wrote: > > It is worth mentioning for those who have not seen a Ubiquiti "edgrouter" > in person yet, or worked with one, where their operating system came > from... When Vyatta was acquired by Brocade, the core Vyatta team jumped > ship and were hired directly by Ubiquiti. Not really. There were two developers that quit Vyatta and subsequently went to Ubiquiti. And that happened long before the Brocade acquisition. The core Vyatta team is still going strong, working on the Vyatta NOS. -robert From gewasiuk at blackhorselabs.net Tue Dec 5 18:16:58 2017 From: gewasiuk at blackhorselabs.net (Gordon Ewasiuk) Date: Tue, 5 Dec 2017 13:16:58 -0500 (EST) Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> Message-ID: On Tue, 5 Dec 2017, Edwin Pers wrote: >> Last week we found out that Helpscout sends email from AWS servers. >> >> This is incorrect reasoning. Because they're the biggest cloud provider >> in the world, they should send the least amount of junk: the larger >> an operation is, the easier abuse detection/prevention gets. > > You'd think so, yes. Somehow Google and DO and most other hosting > companies manage to do it. Feels like AWS truly doesn't care about it. AWS imposes "email sending limitations", by default, on all EC2 accounts. Anyone who wants those limitations removed has to fill out a form and make a use case to AWS Support. AWS also says they work with ISPs and "Internet anti-SPAM orgs" like Spamhaus. That sounds a bit more than "doesn't care about it", no? -Gordon (yes, I'm an AWS customer) From georg.kahest at internet.ee Tue Dec 5 19:00:55 2017 From: georg.kahest at internet.ee (Georg Kahest) Date: Tue, 5 Dec 2017 21:00:55 +0200 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <005301d36df8$4fe2b190$efa814b0$@wicks.co.nz> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <26A76D8B-D93C-43C0-AA3E-BCF8AE610811@beckman.org> <001c01d36df1$84b4e570$8e1eb050$@wicks.co.nz> <56DCB430-832E-494C-A40D-EF5B8F5BCE6D@gmail.com> <005101d36df4$47882970$d6987c50$@wicks.co.nz> <18D5E9AF-1123-496F-952A-84F12B6BC494@gmail.com> <156984900.9135.1512498559085.JavaMail.mhammett@ThunderFuck> <005301d36df8$4fe2b190$efa814b0$@wicks.co.nz> Message-ID: <9acb2723-1d3f-3653-c0d9-4a7c44b54622@internet.ee> Have you played around with mx150 yet? It seems very appealing on paper, but as of its so new i have my doubts.... On 05.12.2017 20:38, tony at wicks.co.nz wrote: > Yea, as much as I love Juniper Hardware the M series is really a long way on the past at this point. I would suggest the new MX150 is the way to go for up to 20G requirements. Of course that's in a different league from the OP's criteria. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Wednesday, 6 December 2017 7:29 AM > Cc: nanog at nanog.org > Subject: Re: Small full BGP table capable router with low power consumption > > I'm replacing an M10i with a CHR. > > I hope you have a newer RE so that you don't have worse BGP convergence than a CCR. > > > > From fhr at fhrnet.eu Wed Dec 6 16:38:13 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 6 Dec 2017 16:38:13 +0000 Subject: Novice sysadmins In-Reply-To: <20171206105234.GA21262@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> Message-ID: <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> I disagree that nobody cares about abuse. I actually received an abuse report from SES as someone thought it would be funny to flag my previous email I sent to this discussion as spam. https://i.imgur.com/RgQa2fN.png -- Filip Hruska Linux System Administrator Dne 12/6/17 v 11:52 Rich Kulawiec napsal(a): > On Tue, Dec 05, 2017 at 09:54:21AM -0700, Grant Taylor via NANOG wrote: >> The vast majority of what I've experienced in the last ~20 years has been >> people willing to help others who are trying to help themselves. > "Help will always be given at Hogwarts to those who ask for it." > >> If you are trying, make an honest mistake, and are willing to correct it >> when others politely let you know, you will quite likely find people willing >> to help you. Especially if you return the favor in kind. > Yes. That's how we all get better at this. And when any of us learn, > we all benefit, so it's in our mutual best interest to share knowledge. > (I've learned more here than I can measure. And I'm grateful for it.) > >> If you are being a hooligan and not responding to problems reported to you >> or purposefully ~> wantonly doing things to others ... good luck. > And the latter is the problem: we are faced, unfortunately, with massive > operations that were designed, built, and deployed without the slightest > consideration for responsible behavior toward the rest of the Internet. > All the rest of us are paying the price for that arrogance, incompetence > and negligence: we're paying for it with DoS/DDoS defenses, with spam > and phish defenses, with brute-force attack defenses, with time and > money and computing resources, with complexity, with late nights and > early mornings, with annoyed customers, and -- on the occasions when those > defenses fail -- devastating consequences for organizations and people. > > These costs aren't always obvious because they're not highlighted line > items in an accounting statement. But they're real, and they're huge. > > How huge? Well, one measure could be found in the observation that > there's now an entire -- large and growing -- market segment that > exists solely to mitigate the fallout from these operations. > > And those same massive operations are doing everything they possibly > can to avoid hearing about any of this. That's why abuse@ is effectively > hardwired to /dev/null. And I note with interest that nobody from AWS > has had the professionalism to show up in this thread and say "Gosh, we're > sorry. We screwed up. We'll try to do better. Can you help us?" > > Because we would. > > ---rsk > From list at satchell.net Wed Dec 6 16:44:26 2017 From: list at satchell.net (Stephen Satchell) Date: Wed, 6 Dec 2017 08:44:26 -0800 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> Message-ID: <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> http://docs.aws.amazon.com/ses/latest/DeveloperGuide/manage-sending-limits.html On 12/05/2017 10:16 AM, Gordon Ewasiuk via NANOG wrote: > AWS imposes "email sending limitations", by default, on all EC2 > accounts. Anyone who wants those limitations removed has to fill out a > form and make a use case to AWS Support. > > AWS also says they work with ISPs and "Internet anti-SPAM orgs" like > Spamhaus. > > That sounds a bit more than "doesn't care about it", no? From nate at dopedesign.com Wed Dec 6 17:16:35 2017 From: nate at dopedesign.com (Nate Metheny) Date: Wed, 6 Dec 2017 10:16:35 -0700 Subject: Novice sysadmins In-Reply-To: <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> Message-ID: The day the secret service and the FBI showed up asking me for a network audit due to suspicious traffic I realized that I need to take abuse@ seriously. "I'm only the network administrator" didn't go over well. I've always been more than willing to share knowledge and skill training with those who show interest and talent; the more qualified and interested people involved, the better, in my opinion. Making the club "exclusive" by requiring thousands of dollars of training and testing is just another method of control and elitism. On Wed, Dec 6, 2017 at 9:38 AM, Filip Hruska wrote: > I disagree that nobody cares about abuse. > > I actually received an abuse report from SES as someone thought it would > be funny to flag my previous email I sent to this discussion as spam. > https://i.imgur.com/RgQa2fN.png > > > -- > Filip Hruska > Linux System Administrator > > Dne 12/6/17 v 11:52 Rich Kulawiec napsal(a): > > On Tue, Dec 05, 2017 at 09:54:21AM -0700, Grant Taylor via NANOG wrote: >> >>> The vast majority of what I've experienced in the last ~20 years has been >>> people willing to help others who are trying to help themselves. >>> >> "Help will always be given at Hogwarts to those who ask for it." >> >> If you are trying, make an honest mistake, and are willing to correct it >>> when others politely let you know, you will quite likely find people >>> willing >>> to help you. Especially if you return the favor in kind. >>> >> Yes. That's how we all get better at this. And when any of us learn, >> we all benefit, so it's in our mutual best interest to share knowledge. >> (I've learned more here than I can measure. And I'm grateful for it.) >> >> If you are being a hooligan and not responding to problems reported to you >>> or purposefully ~> wantonly doing things to others ... good luck. >>> >> And the latter is the problem: we are faced, unfortunately, with massive >> operations that were designed, built, and deployed without the slightest >> consideration for responsible behavior toward the rest of the Internet. >> All the rest of us are paying the price for that arrogance, incompetence >> and negligence: we're paying for it with DoS/DDoS defenses, with spam >> and phish defenses, with brute-force attack defenses, with time and >> money and computing resources, with complexity, with late nights and >> early mornings, with annoyed customers, and -- on the occasions when those >> defenses fail -- devastating consequences for organizations and people. >> >> These costs aren't always obvious because they're not highlighted line >> items in an accounting statement. But they're real, and they're huge. >> >> How huge? Well, one measure could be found in the observation that >> there's now an entire -- large and growing -- market segment that >> exists solely to mitigate the fallout from these operations. >> >> And those same massive operations are doing everything they possibly >> can to avoid hearing about any of this. That's why abuse@ is effectively >> hardwired to /dev/null. And I note with interest that nobody from AWS >> has had the professionalism to show up in this thread and say "Gosh, we're >> sorry. We screwed up. We'll try to do better. Can you help us?" >> >> Because we would. >> >> ---rsk >> >> > -- Nate Metheny natemetheny at gmail.com From dvandyk at akamai.com Wed Dec 6 17:26:18 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Wed, 6 Dec 2017 17:26:18 +0000 Subject: Verizon issues | Dec 6 Message-ID: Hello fellow netengs, Is anyone else experiencing issues with Verizon network in North America? We have seen multiple outages throughout the day for traffic destined for Verizon. Have been unable to confirm anywhere else so seeing if anyone else noticed. Times are Dec 06:23 Dec 09:39 – 09:45 UTC Dec 6 14:48 – 14:53 UTC Dec6 16:55 – 17:01 UTC Thanks -- Donovan Van Dyk SOC Network Engineer Office: +1.954.620.6002 x911 Fort Lauderdale, FL USA [cid:image001.png at 01D36E8D.6A9FD4A0] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From sethm at rollernet.us Wed Dec 6 17:27:41 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 6 Dec 2017 09:27:41 -0800 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> Message-ID: <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> On 12/6/17 09:16, Nate Metheny wrote: > I've always been more than willing to share knowledge and skill training > with those who show interest and talent; the more qualified and interested > people involved, the better, in my opinion. Making the club "exclusive" by > requiring thousands of dollars of training and testing is just another > method of control and elitism. Is it elitism that professional engineers (structural, mechanical, civil, etc.) be educated with required experience as a junior engineer before they can take the PE exam? From tyler at tgconrad.com Wed Dec 6 17:29:01 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Wed, 6 Dec 2017 09:29:01 -0800 Subject: Verizon issues | Dec 6 In-Reply-To: References: Message-ID: Yeah, been seeing similar issues in Detroit area. On Wednesday, December 6, 2017, Van Dyk, Donovan via NANOG wrote: > Hello fellow netengs, > > Is anyone else experiencing issues with Verizon network in North America? > We have seen multiple outages throughout the day for traffic destined for > Verizon. > > Have been unable to confirm anywhere else so seeing if anyone else noticed. > > Times are > Dec 06:23 > Dec 09:39 – 09:45 UTC > Dec 6 14:48 – 14:53 UTC > Dec6 16:55 – 17:01 UTC > > Thanks > -- > Donovan Van Dyk > SOC Network Engineer > Office: +1.954.620.6002 x911 > Fort Lauderdale, FL USA > > [cid:image001.png at 01D36E8D.6A9FD4A0] > The information contained in this electronic mail transmission and its > attachments may be privileged and confidential and protected from > disclosure. If the reader of this message is not the intended recipient (or > an individual responsible for delivery of the message to such person), you > are strictly prohibited from copying, disseminating or distributing this > communication. If you have received this communication in error, please > notify the sender immediately and destroy all electronic, paper or other > versions. > > From gewasiuk at blackhorselabs.net Wed Dec 6 17:29:30 2017 From: gewasiuk at blackhorselabs.net (Gordon Ewasiuk) Date: Wed, 6 Dec 2017 12:29:30 -0500 (EST) Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> Message-ID: On Wed, 6 Dec 2017, Stephen Satchell wrote: > http://docs.aws.amazon.com/ses/latest/DeveloperGuide/manage-sending-limits.html > > On 12/05/2017 10:16 AM, Gordon Ewasiuk via NANOG wrote: >> AWS imposes "email sending limitations", by default, on all EC2 accounts. >> Anyone who wants those limitations removed has to fill out a form and make >> a use case to AWS Support. >> >> AWS also says they work with ISPs and "Internet anti-SPAM orgs" like >> Spamhaus. >> I can't comment about SES. Don't use it. Didn't mention it in my previous message. Though, since you brought it up, the fact that Amazon imposes any limits on their SES customers (sending quotas), has a initial sandbox that allows a miniscule 200 msgs a day, and requires customers to demonstrate the need to increase those limits suggests they are paying more than lip-service to fighting spam. They also have a published and current AUP: https://aws.amazon.com/aup/ A working abuse team: abuse AT amazonaws DOT com and an online form where you can report EC2 abusers: https://aws.amazon.com/forms/report-abuse Suggesting AWS doesn't care seems...well...inaccurate. -Gordon From EPers at ansencorp.com Wed Dec 6 17:31:54 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 6 Dec 2017 17:31:54 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> Message-ID: Email sending limits are one thing. A couple hundred ssh/rdp/sql bots hitting my firewalls constantly is another. From what I'm reading on that AWS doc page, those limits only apply to SES users. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Wednesday, December 6, 2017 11:44 AM To: nanog at nanog.org Subject: Re: Suggestions for a more privacy conscious email provider http://docs.aws.amazon.com/ses/latest/DeveloperGuide/manage-sending-limits.html On 12/05/2017 10:16 AM, Gordon Ewasiuk via NANOG wrote: > AWS imposes "email sending limitations", by default, on all EC2 > accounts. Anyone who wants those limitations removed has to fill out a > form and make a use case to AWS Support. > > AWS also says they work with ISPs and "Internet anti-SPAM orgs" like > Spamhaus. > > That sounds a bit more than "doesn't care about it", no? From mike at mtcc.com Wed Dec 6 17:35:42 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 6 Dec 2017 09:35:42 -0800 Subject: Novice sysadmins In-Reply-To: <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: On 12/06/2017 09:27 AM, Seth Mattinen wrote: > On 12/6/17 09:16, Nate Metheny wrote: >> I've always been more than willing to share knowledge and skill training >> with those who show interest and talent; the more qualified and >> interested >> people involved, the better, in my opinion. Making the club >> "exclusive" by >> requiring thousands of dollars of training and testing is just another >> method of control and elitism. > > > Is it elitism that professional engineers (structural, mechanical, > civil, etc.) be educated with required experience as a junior engineer > before they can take the PE exam? The internet has done pretty well without a guild thus far. The onus for regulation should be on the wannabe-guild builders. Mike From fhr at fhrnet.eu Wed Dec 6 17:54:45 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 6 Dec 2017 17:54:45 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> Message-ID: <010201602cf731fd-9558514d-7c5a-49f7-a424-321426278f32-000000@eu-west-1.amazonses.com> SES can't hit your firewall with bots, it's just an email service. Maybe you meant EC2? And as I said earlier, if you have correctly setup firewall and servers, port scanning or bots can't hurt you in any way. -- Filip Hruska Linux System Administrator Dne 12/6/17 v 18:31 Edwin Pers napsal(a): > Email sending limits are one thing. A couple hundred ssh/rdp/sql bots hitting my firewalls constantly is another. > > From what I'm reading on that AWS doc page, those limits only apply to SES users. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell > Sent: Wednesday, December 6, 2017 11:44 AM > To: nanog at nanog.org > Subject: Re: Suggestions for a more privacy conscious email provider > > http://docs.aws.amazon.com/ses/latest/DeveloperGuide/manage-sending-limits.html > > On 12/05/2017 10:16 AM, Gordon Ewasiuk via NANOG wrote: >> AWS imposes "email sending limitations", by default, on all EC2 >> accounts. Anyone who wants those limitations removed has to fill out a >> form and make a use case to AWS Support. >> >> AWS also says they work with ISPs and "Internet anti-SPAM orgs" like >> Spamhaus. >> >> That sounds a bit more than "doesn't care about it", no? From EPers at ansencorp.com Wed Dec 6 18:12:46 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 6 Dec 2017 18:12:46 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <010201602cf731fd-9558514d-7c5a-49f7-a424-321426278f32-000000@eu-west-1.amazonses.com> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> <010201602cf731fd-9558514d-7c5a-49f7-a424-321426278f32-000000@eu-west-1.amazonses.com> Message-ID: -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gordon Ewasiuk via NANOG Sent: Wednesday, December 6, 2017 12:30 PM To: nanog at nanog.org Subject: Re: Suggestions for a more privacy conscious email provider > >Suggesting AWS doesn't care seems...well...inaccurate. > >-Gordon This is all anecdotal so take it as you will. In 2016 I filed a total of 76 reports either via their web form or by emailing their abuse email directly. Every single one got this in reply: After submitting the initial abuse report (providing all the information they ask for in an initial report): >Hello, >Thank you for your abuse report. We were unable to identify the customer responsible for the reported activity. Due to the frequency with which AWS >public IP addresses can change ownership, we will need additional information in order to identify the responsible customer(s). Then a few days later, after replying back to their email with the same content that was in the initial abuse report: >Hello, >This is a follow up regarding the abusive content or activity report that you submitted to AWS. We have investigated this report, and have taken steps to >mitigate the reported abusive content or activity. Due to our privacy and security policies we are unable to provide details regarding the resolution of this >case or the identity of our customer. >We are committed to mediating reports of abusive content or activity to the satisfaction of both the reporters and our customers. If you believe the >reported content or activity persists, or are not satisfied with the resolution of this case, please reply directly to this message with more information. Your >response should include the most recent activity logs or web location of the content that you have available that indicates that the activity or content >persists, as well as a clear, succinct explanation of what you expect of us and our customer. > >Thank you for bringing this matter to our attention. > >Regards, >AWS Abuse Team So yes, it would //appear// that they do care. They do have an abuse team and they're very good at sending out those canned emails and making you think they've done something. But here we are in 2017 and I'm still seeing the exact same attempts from the exact same IP's that I reported in 2016. The way I see it, there's only two explanations: A bunch of people are running the same exact bots that use the same exact source ports and they all just happened to get the same set of public v4's assigned to them and they all just happened to target all of my sites at the exact same rate. or AWS didn't actually do anything about it. (Yes, none of that applies to their SES service, but there's nothing stopping someone from running postfix on an e2c instance. I won't comment on how the SES team there handles things, because I haven't had any dealings with their abuse team.) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Filip Hruska Sent: Wednesday, December 6, 2017 12:55 PM To: nanog at nanog.org Subject: Re: Suggestions for a more privacy conscious email provider > >SES can't hit your firewall with bots, it's just an email service. > >Maybe you meant EC2? And as I said earlier, if you have correctly setup >firewall and servers, port scanning or bots can't hurt you in any way. > > >-- >Filip Hruska >Linux System Administrator I don't remember mentioning SES in this thread before today. But as Rich said earlier: >And the latter is the problem: we are faced, unfortunately, with massive >operations that were designed, built, and deployed without the slightest >consideration for responsible behavior toward the rest of the Internet. >All the rest of us are paying the price for that arrogance, incompetence >and negligence: we're paying for it with DoS/DDoS defenses, with spam >and phish defenses, with brute-force attack defenses, with time and >money and computing resources, with complexity, with late nights and >early mornings, with annoyed customers, and -- on the occasions when those >defenses fail -- devastating consequences for organizations and people. > >These costs aren't always obvious because they're not highlighted line >items in an accounting statement. But they're real, and they're huge. > >How huge? Well, one measure could be found in the observation that >there's now an entire -- large and growing -- market segment that >exists solely to mitigate the fallout from these operations. > >And those same massive operations are doing everything they possibly >can to avoid hearing about any of this. That's why abuse@ is effectively >hardwired to /dev/null. And I note with interest that nobody from AWS >has had the professionalism to show up in this thread and say "Gosh, we're >sorry. We screwed up. We'll try to do better. Can you help us?" > >Because we would. I agree, the dumber bots won't cause any harm (beyond the wasted bandwidth) But every now and then there's a slightly smarter and more targeted bot run by someone who actually knows how to use nmap. New exploits are discovered every day, and as we all know the ones that are made public are in the minority. I know I'd sleep better at night knowing that one of the largest cloud providers would do something about it. I'm sure most of you would agree. I'll leave it at that. -Ed From jcurran at arin.net Wed Dec 6 18:15:08 2017 From: jcurran at arin.net (John Curran) Date: Wed, 6 Dec 2017 18:15:08 +0000 Subject: One week remaining in the 2017 ARIN Customer Satisfaction Survey! References: Message-ID: <111309B3-7F06-4679-90CE-7FB17BCAC8A4@arin.net> NANOGers - If you make use of the ARIN’s services, here is a great opportunity to provide ARIN feedback on what we’re getting right and how we can improve. The 2017 ARIN Customer Satisfaction Survey is available as detailed below, and will remain open for just another week! (There is also a prize drawing involved, for those who need just a little extra incentive..) Thanks in advance for your input! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] 2017 ARIN Customer Satisfaction Survey Now Open Date: 30 November 2017 at 12:08:42 PM EST To: > From November 30 – December 14, ARIN is conducting a survey to determine the current level of customer satisfaction with ARIN services and to inform a path forward to make future improvements. This customer satisfaction study will enhance the feedback collection we already conduct throughout the year using transaction surveys, the feedback button on the front page of the ARIN website, the ARIN Consultation and Suggestion Process, and other feedback mechanisms. As with our previous customer satisfaction survey, we are working with a marketing research firm, Rockbridge Associates, to conduct this survey and gain a better understanding of our performance in all areas of the organization. The survey should only take about 15 minutes to complete and is available (via confirmit.com) at: http://survey.us.confirmit.com/wix/p3085177322.aspx We will randomly select winners to receive a $500 Amazon Gift Card during the survey period. If you would like to participate, please provide your name and an email address on the final page of the survey. This information will only be used for the purposes of randomly selecting and contacting survey prize winners. The names of the winners will be announced. If you do not wish to be included in the random drawing for a gift card, you can complete the survey without providing your name and email address. Your feedback is important to us, and we value your time to help improve ARIN services. The survey is currently open. Let us know how we’re doing. Thank you. Richard Jimmerson Chief Information Officer American Registry for Internet Numbers (ARIN) From dvandyk at akamai.com Wed Dec 6 18:43:43 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Wed, 6 Dec 2017 18:43:43 +0000 Subject: Verizon issues | Dec 6 In-Reply-To: References: Message-ID: They might be getting DDoS as protests for FCC vote?? The intermittent outages seem to line up with DDoS characteristics. https://www.theverge.com/2017/12/6/16742184/verizon-net-neutrality-protests From: Tyler Conrad Date: Wednesday, December 6, 2017 at 12:29 PM To: "Van Dyk, Donovan" Cc: "nanog at nanog.org" Subject: Re: Verizon issues | Dec 6 Yeah, been seeing similar issues in Detroit area. On Wednesday, December 6, 2017, Van Dyk, Donovan via NANOG > wrote: Hello fellow netengs, Is anyone else experiencing issues with Verizon network in North America? We have seen multiple outages throughout the day for traffic destined for Verizon. Have been unable to confirm anywhere else so seeing if anyone else noticed. Times are Dec 06:23 Dec 09:39 – 09:45 UTC Dec 6 14:48 – 14:53 UTC Dec6 16:55 – 17:01 UTC Thanks -- Donovan Van Dyk SOC Network Engineer Office: +1.954.620.6002 x911 Fort Lauderdale, FL USA [cid:image001.png at 01D36E8D.6A9FD4A0] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From list at satchell.net Wed Dec 6 18:51:32 2017 From: list at satchell.net (Stephen Satchell) Date: Wed, 6 Dec 2017 10:51:32 -0800 Subject: Novice sysadmins In-Reply-To: <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: On 12/06/2017 09:27 AM, Seth Mattinen wrote: > On 12/6/17 09:16, Nate Metheny wrote: >> I've always been more than willing to share knowledge and skill training >> with those who show interest and talent; the more qualified and >> interested >> people involved, the better, in my opinion. Making the club >> "exclusive" by >> requiring thousands of dollars of training and testing is just another >> method of control and elitism. > > > Is it elitism that professional engineers (structural, mechanical, > civil, etc.) be educated with required experience as a junior engineer > before they can take the PE exam? What professional engineers you mentioned do can kill people. I have yet to hear of anyone dying from a sysadmin or netadmin screwing up. (Other than dropping something heavy onto someone, using a fork lift incompetently, or building an unsafe raised floor.). From bicknell at ufp.org Wed Dec 6 19:04:54 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 Dec 2017 11:04:54 -0800 Subject: Novice sysadmins In-Reply-To: References: <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: <20171206190454.GA73057@ussenterprise.ufp.org> In a message written on Wed, Dec 06, 2017 at 10:51:32AM -0800, Stephen Satchell wrote: > What professional engineers you mentioned do can kill people. I have > yet to hear of anyone dying from a sysadmin or netadmin screwing up. > (Other than dropping something heavy onto someone, using a fork lift > incompetently, or building an unsafe raised floor.). Some of the folks on this list run networks that carry 911 phone calls. A call not going through may well result in fatalities. I'm personally torn, I think the "Professional Engineer" things are 75% racket, and 25% good, but I also think the 'net continues to miss out on the 25% good and could seriously use some of it. -- Leo Bicknell - bicknell at ufp.org 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: not available URL: From chk at pobox.com Wed Dec 6 19:18:07 2017 From: chk at pobox.com (Harald Koch) Date: Wed, 6 Dec 2017 14:18:07 -0500 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: On 6 December 2017 at 13:51, Stephen Satchell wrote: > What professional engineers you mentioned do can kill people. I have yet > to hear of anyone dying from a sysadmin or netadmin screwing up. > Oh c'mon. Now you're being deliberately obtuse. I work IT for a hospital. Everything I do has the potential to affect patient safety, and we do have documented cases of patients dying from IT mishaps. Perhaps do your research before spouting off more of these unsubstantiated claims? -- Harald From cra at WPI.EDU Wed Dec 6 19:58:37 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 6 Dec 2017 14:58:37 -0500 Subject: Novice sysadmins In-Reply-To: References: <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: <20171206195837.GA14566@angus.ind.wpi.edu> On Wed, Dec 06, 2017 at 02:18:07PM -0500, Harald Koch wrote: > On 6 December 2017 at 13:51, Stephen Satchell wrote: > > > What professional engineers you mentioned do can kill people. I have yet > > to hear of anyone dying from a sysadmin or netadmin screwing up. > > > > Oh c'mon. Now you're being deliberately obtuse. > > I work IT for a hospital. Everything I do has the potential to affect > patient safety, and we do have documented cases of patients dying from IT > mishaps. > > Perhaps do your research before spouting off more of these unsubstantiated > claims? Like the famous case of the Therac-25 machine. Programmers, not sysadmins, but same idea. From bill at herrin.us Wed Dec 6 20:56:39 2017 From: bill at herrin.us (William Herrin) Date: Wed, 6 Dec 2017 15:56:39 -0500 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: On Wed, Dec 6, 2017 at 1:51 PM, Stephen Satchell wrote: > What professional engineers you mentioned do can kill people. I have yet > to hear of anyone dying from a sysadmin or netadmin screwing up. (Other > than dropping something heavy onto someone, using a fork lift > incompetently, or building an unsafe raised floor.). > I want pictures of the unsafe raised floor. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sam.oduor at gmail.com Wed Dec 6 21:04:54 2017 From: sam.oduor at gmail.com (Sam Oduor) Date: Thu, 7 Dec 2017 00:04:54 +0300 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: All industries have risks associated. In our Sysadmin context - Though I have not heard of any yet - a case scenario of telesurgery/remote surgery. In the midst of this operation - a misconfiguration by either a netadmin(bgp) or sysadmin(dns) resulting into downtime cutting off communication = catastrophic end results. On Wed, Dec 6, 2017 at 11:56 PM, William Herrin wrote: > On Wed, Dec 6, 2017 at 1:51 PM, Stephen Satchell > wrote: > > > What professional engineers you mentioned do can kill people. I have yet > > to hear of anyone dying from a sysadmin or netadmin screwing up. (Other > > than dropping something heavy onto someone, using a fork lift > > incompetently, or building an unsafe raised floor.). > > > > I want pictures of the unsafe raised floor. > > -Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -- Samson Oduor From rgolodner at infratection.com Wed Dec 6 21:05:12 2017 From: rgolodner at infratection.com (Richard) Date: Wed, 6 Dec 2017 15:05:12 -0600 Subject: Sys admin has gotten of topic... Message-ID:     Please squash this thread as it has run it's course.     Thank you, Richard From rsk at gsp.org Wed Dec 6 21:26:00 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 6 Dec 2017 16:26:00 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> Message-ID: <20171206212600.GA4650@gsp.org> On Wed, Dec 06, 2017 at 12:29:30PM -0500, Gordon Ewasiuk via NANOG wrote: > and an online form where you can report EC2 abusers: > https://aws.amazon.com/forms/report-abuse 1. Used it (and the abuse@ address). Either (a) no response and/or (b) boilerplate response. No responses indicating that reports were read and understood by a human. No responses indicating any action taken, whether reactive or proactive. No apparent change in observed attacks/abuse. 2. Y'know, if I can see attacks/abuse arriving at networks/systems that I run, then surely they can see it leaving networks/systems that they run. The same data is available to them as is available to me, and I have absolutely no trouble noticing it. Why don't they see it and do something about it even before I (or anybody else) has the chance to report it? Better yet, why not study the large-scale patterns over time and proactively address it? (In fairness, the SMTP rate-limit described inter alia is exactly the sort of thing that would be part of this, and it's good that they're doing that.) ---rsk From valdis.kletnieks at vt.edu Wed Dec 6 21:39:42 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 06 Dec 2017 16:39:42 -0500 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171206212600.GA4650@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> <20171206212600.GA4650@gsp.org> Message-ID: <162131.1512596382@turing-police.cc.vt.edu> On Wed, 06 Dec 2017 16:26:00 -0500, Rich Kulawiec said: > 2. Y'know, if I can see attacks/abuse arriving at networks/systems > that I run, then surely they can see it leaving networks/systems that > they run. A packet stream that will DoS a 20/2 cable subscriber is just a tiny fraction of a 100G pipe outbound from a large data center. (Though I'm sure the pipe to your systems is bigger than 20 megabits, I'm also sure that your inbound is probably smaller than the sum of all outbound pipes from AWS) Is anybody selling monitoring gear that can do deep packet inspection at line rate on a 100G pipe? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From Brian at ampr.org Wed Dec 6 21:43:29 2017 From: Brian at ampr.org (Brian Kantor) Date: Wed, 6 Dec 2017 13:43:29 -0800 Subject: Suggestions for a more privacy conscious email provider Message-ID: <20171206214329.GC31670@UCSD.Edu> On Wed, Dec 06, 2017 at 04:26:00PM -0500, Rich Kulawiec wrote: > On Wed, Dec 06, 2017 at 12:29:30PM -0500, Gordon Ewasiuk via NANOG wrote: > > and an online form where you can report EC2 abusers: > > https://aws.amazon.com/forms/report-abuse > > 1. Used it (and the abuse@ address). Either (a) no response and/or (b) > boilerplate response. No responses indicating that reports were read and > understood by a human. No responses indicating any action taken, whether > reactive or proactive. No apparent change in observed attacks/abuse. > > 2. Y'know, if I can see attacks/abuse arriving at networks/systems > that I run, then surely they can see it leaving networks/systems that > they run. The same data is available to them as is available to me, > and I have absolutely no trouble noticing it. Why don't they see it and > do something about it even before I (or anybody else) has the chance to > report it? Better yet, why not study the large-scale patterns over time > and proactively address it? (In fairness, the SMTP rate-limit described > inter alia is exactly the sort of thing that would be part of this, > and it's good that they're doing that.) > > ---rsk For the largest players, I can see no economic advantage in being a good network neighbor, and plenty of cost (salaries, equipment) to do so. Until that situation is reversed, even the most conscientious network engineer will have great difficulty to get management to go along with being a good guy. I liken it to dumping toxic waste. Clearly it was a better deal for a company to just dump its toxic waste instead of pay for proper dispoal, until large government fines forced a change in the practice. The solution is to somehow make bad behaviour expensive. - Brian From EPers at ansencorp.com Wed Dec 6 21:58:07 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 6 Dec 2017 21:58:07 +0000 Subject: Suggestions for a more privacy conscious email provider In-Reply-To: <20171206212600.GA4650@gsp.org> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <7787DFD1-920B-4F86-9660-44A8E37846B4@orthanc.ca> <38d90f7b-bdcb-8bb6-bf9b-90bf6db33cb2@satchell.net> <20171206212600.GA4650@gsp.org> Message-ID: <76a15364f33c4ad9b709dfef9040430e@ansencorp.com> On Wed, 06 Dec 2017 16:26:00 -0500, Rich Kulawiec said: >Better yet, why not study the large-scale patterns over time >and proactively address it? If only there was some sort of distributed analytics/search/etc platform they could use to do that.... https://www.elastic.co/ https://aws.amazon.com/elasticsearch-service/ It's not hard. Only took me by myself a few days of farting around to learn it and start getting good hard information out of a single local ES instance that was being fed nothing but firewall logs. I'm sure they would have no trouble with it On Wed, 06 Dec 2017 16:40:00 -0500, valdis.kletnieks at vt.edu said: Sent: Wednesday, December 6, 2017 4:40 PM > Is anybody selling monitoring gear that can do deep packet inspection > at line rate on a 100G pipe? Found this within a few minutes of looking: https://accoladetechnology.com/portfolio-item/anic-200Ku/ Not sure if it would meet the needs but I'm sure that there's something out there that can do it. The actual inspection of captured packets doesn't have to be line rate (unless you want to ban people on the fly). Either way, with their resources, anything is possible. I'm sure Cisco would sell you a complete "solution" as well, along with the hefty service contract that comes with buying into Big Green On Wed, 06 Dec 2017 16:43:00 -0500, Brian Kantor said: >For the largest players, I can see no economic advantage in being a good >network neighbor, and plenty of cost (salaries, equipment) to do so. Exactly. But at the same time we don't see this with google, digital ocean, etc other big players in the market. I don't see any feasible way to get them to change their behavior either. For all we know they're already doing this. But if they are they aren't doing much with the data they get out of it -ed From mfidelman at meetinghouse.net Thu Dec 7 01:39:19 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 6 Dec 2017 18:39:19 -0700 Subject: Novice sysadmins In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> Message-ID: <23180fbd-646d-b91d-9c89-4ef992255a92@meetinghouse.net> > On Wed, Dec 6, 2017 at 1:51 PM, Stephen Satchell wrote: > >> What professional engineers you mentioned do can kill people. I have yet >> to hear of anyone dying from a sysadmin or netadmin screwing up. (Other >> than dropping something heavy onto someone, using a fork lift >> incompetently, or building an unsafe raised floor.). >> >> Military networks.  Aviation.  Hospitals.  SCADA.  The list goes on. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jhellenthal at dataix.net Thu Dec 7 01:52:22 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 6 Dec 2017 19:52:22 -0600 Subject: Novice sysadmins In-Reply-To: <23180fbd-646d-b91d-9c89-4ef992255a92@meetinghouse.net> References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> <20171206105234.GA21262@gsp.org> <010201602cb12036-acef694e-11ef-44e3-b614-4e0257dd988d-000000@eu-west-1.amazonses.com> <920cf5eb-dce5-9e2a-52cb-da0077646c8a@rollernet.us> <23180fbd-646d-b91d-9c89-4ef992255a92@meetinghouse.net> Message-ID: <5876AFAA-9F0D-4B2B-AD67-4B8D5E414169@dataix.net> People die all the time in our profession. Loss of job due to major failure… self inflicted suicide or even homicide by disgruntled employee due to others negligent actions and laziness. It only amplifies and is less reported these days that in the dot.com boom era. But the higher the classification the more likely its to happen whether its someone else or the person that made the “huge mistake”. But this thread is really out of line and can go on forever. I would encourage others to not reply as I will not as well. > On Dec 6, 2017, at 19:39, Miles Fidelman wrote: > > >> On Wed, Dec 6, 2017 at 1:51 PM, Stephen Satchell wrote: >> >>> What professional engineers you mentioned do can kill people. I have yet >>> to hear of anyone dying from a sysadmin or netadmin screwing up. (Other >>> than dropping something heavy onto someone, using a fork lift >>> incompetently, or building an unsafe raised floor.). >>> >>> > Military networks. Aviation. Hospitals. SCADA. The list goes on. > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > From edugas at unknowndevice.ca Thu Dec 7 02:08:07 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Wed, 6 Dec 2017 21:08:07 -0500 Subject: Poor speed to AWS Message-ID: Anyone from AWS can contact me off-list? We peer with AS16509 in Montreal and Toronto and get really good speed to US-EAST-1, US-EAST-2 and of course CA-CENTRAL-1 but anything else outside the east coast (US-WEST-1 and US-WEST-2 more precisely) is about ten times slower even on multi-threaded HTTP(S) or SCP/SFTP transfers. Goes through two of our transit providers, Telia and Zayo. Thanks Eric From bzs at theworld.com Thu Dec 7 04:14:15 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 6 Dec 2017 23:14:15 -0500 Subject: Novice sysadmins (was: Suggestions for a more privacy conscious email provider) In-Reply-To: References: <010201601d59cf1d-59870cde-066e-419e-bc11-166ebc18a5c0-000000@eu-west-1.amazonses.com> <20171204072725.GA2793@gsp.org> <3df90de88a0c47cc8e3d579ecd395c02@ansencorp.com> <0102016022aed169-93a80a93-fc1a-404c-a098-af4b19893a66-000000@eu-west-1.amazonses.com> <20171204233403.GA16717@gsp.org> <1FA71D02-036C-4D60-81E9-08A9B59A68DC@truenet.com> <20171205105918.GA8503@gsp.org> Message-ID: <23080.49175.659571.617726@gargle.gargle.HOWL> I realize there has been some call to end this thread but if I may add a little history... On December 5, 2017 at 06:49 list at satchell.net (Stephen Satchell) wrote: > Indeed. What Ajit Pai missed in his deliberations for the Dec 14 FCC > vote is that the Internet as we know it was developed under the stern > eyes of the Department of Defense and the National Science Foundation. > The NSF in particular ran the 'Net like bouncers do in a strip club: > you break the rules, you go. No argument. I'm not sure I remember it quite like that, maybe I haven't been in enough strip clubs. But it wasn't a big problem. Under DARPA you needed a (generally military) sponsor and research activity to connect to the ARPAnet so any threat to that relationship was taken very seriously. NSFNET was largely a network of university and research institutions basically without the sponsor requirement (or put another way with NSF as your rubber-stamp sponsor) so if there were any problem it would be referred to the institution. Prior to NSFNET I was involved in putting a 10mb microwave between Boston Univ and Harvard which completed a high speed loop between Harvard/MIT/BU. So several of us at the the three universities involved in administering the net put together a mailing list to discuss progress and generally stay in touch. One of the major topics became: If one of MY students (&c) misbehaves on MY network then I know what to do. What do I do if one of YOUR students (&c) misbehaves on MY network? Is there even process in place? A few years later, 1989, I began putting the public on the internet for the first time. I was called into a videoconference at BBN with Jon Postel and a couple of DARPA people, I forget who exactly but I remember uniforms. They wanted to know: What happens if one of MY customers misbehaves? That is, same concern again. I said honestly I don't really know. I can cancel their account but there's little stopping them from creating a new account. Ultimately what I was doing was approved by NSF as an investigation of exactly this though no one ever followed up. It's been the same issue for over 30 years. (end of my comments, rest left for context.) > > The original trust model for the Internet was based on this unrelenting > oversight. You didn't expect Bad Things(tm) because the consequences of > doing them was so severe: banishment and exile. Also, the technical > ability required to do Bad Things(tm) wasn't easily won. Accessing the > 'Net was a PRIVILEGE, not a right. Abuse at your own peril. > > Organizations had experienced sysadmins because it was imperative to the > survival of the connection to the 'Net. One gained experience by being > apprenticed to some experienced sysadmin. Today: not so much. > > Indeed, I'm not aware of any certification that applies to system > administrators. Network administrators have certs that are > well-recognized and accepted. Mail admins? Server admins? The certs > that are out there border on jokes or disguised sale pitches. (Not > unlike a certain operating system and software product vendor who put > "free" copies into schools to build their marketing base.) > > Ok, I'll shut up now. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From edugas at unknowndevice.ca Thu Dec 7 14:38:34 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 7 Dec 2017 09:38:34 -0500 Subject: Poor speed to AWS In-Reply-To: <89A4FD4E-E73C-4AA3-B62F-BC57356C7129@flem.io> References: <89A4FD4E-E73C-4AA3-B62F-BC57356C7129@flem.io> Message-ID: Someone got in touch. I'm in contact with peering@ and amzn-noc-contact@ Thanks for the off-list replies! On Dec 7 2017, at 4:45 am, Luke wrote: > Hey Eric, have you tried contacting their NOC? > > amzn-noc-contact at amazon.com (mailto:amzn-noc-contact at amazon.com) > https://peeringdb.com/net/1418 > > > On 7 Dec 2017, at 13:08, Eric Dugas wrote: > > Anyone from AWS can contact me off-list? We peer with AS16509 in Montreal and Toronto and get really good speed to US-EAST-1, US-EAST-2 and of course CA-CENTRAL-1 but anything else outside the east coast (US-WEST-1 and US-WEST-2 more precisely) is about ten times slower even on multi-threaded HTTP(S) or SCP/SFTP transfers. Goes through two of our transit providers, Telia and Zayo. > > > > Thanks > > Eric > From sean at donelan.com Fri Dec 8 17:21:43 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 8 Dec 2017 12:21:43 -0500 (EST) Subject: FCC Seeks Comment on 2017 Hurricane Season Response Efforts Message-ID: PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT ON RESPONSE EFFORTS UNDERTAKEN DURING 2017 HURRICANE SEASON PS Docket No. 17-344 Comments Due: January 22, 2018 Reply Comments Due: February 21, 2018 https://www.fcc.gov/document/fcc-seeks-comment-2017-hurricane-season-response-efforts A. Questions Regarding Impacts to Communications Infrastructure B. Questions Regarding the FCC’s Response C. Questions Regarding Communications Service User Experience D. Questions Regarding Communications Service Provider Experience From cscora at apnic.net Fri Dec 8 18:02:50 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Dec 2017 04:02:50 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171208180250.8617CC517@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Dec, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 674032 Prefixes after maximum aggregation (per Origin AS): 262246 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 326110 Total ASes present in the Internet Routing Table: 59288 Prefixes per ASN: 11.37 Origin-only ASes present in the Internet Routing Table: 51190 Origin ASes announcing only one prefix: 22549 Transit ASes present in the Internet Routing Table: 8098 Transit-only ASes present in the Internet Routing Table: 243 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 30 Max AS path prepend of ASN ( 23679) 26 Prefixes from unregistered ASNs in the Routing Table: 89 Number of instances of unregistered ASNs: 89 Number of 32-bit ASNs allocated by the RIRs: 20830 Number of 32-bit ASNs visible in the Routing Table: 16674 Prefixes from 32-bit ASNs in the Routing Table: 68623 Number of bogon 32-bit ASNs visible in the Routing Table: 10 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 350 Number of addresses announced to Internet: 2861476514 Equivalent to 170 /8s, 142 /16s and 170 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 223308 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 185027 Total APNIC prefixes after maximum aggregation: 53147 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 184153 Unique aggregates announced from the APNIC address blocks: 76925 APNIC Region origin ASes present in the Internet Routing Table: 8526 APNIC Prefixes per ASN: 21.60 APNIC Region origin ASes announcing only one prefix: 2392 APNIC Region transit ASes present in the Internet Routing Table: 1230 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3394 Number of APNIC addresses announced to Internet: 767380514 Equivalent to 45 /8s, 189 /16s and 76 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 201752 Total ARIN prefixes after maximum aggregation: 97101 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203119 Unique aggregates announced from the ARIN address blocks: 95080 ARIN Region origin ASes present in the Internet Routing Table: 18043 ARIN Prefixes per ASN: 11.26 ARIN Region origin ASes announcing only one prefix: 6673 ARIN Region transit ASes present in the Internet Routing Table: 1782 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2276 Number of ARIN addresses announced to Internet: 1112345120 Equivalent to 66 /8s, 77 /16s and 10 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 181863 Total RIPE prefixes after maximum aggregation: 88725 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 177773 Unique aggregates announced from the RIPE address blocks: 107176 RIPE Region origin ASes present in the Internet Routing Table: 24709 RIPE Prefixes per ASN: 7.19 RIPE Region origin ASes announcing only one prefix: 11307 RIPE Region transit ASes present in the Internet Routing Table: 3509 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6465 Number of RIPE addresses announced to Internet: 713494912 Equivalent to 42 /8s, 135 /16s and 17 /24s 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, 64396-64495 196608-207259 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: 87455 Total LACNIC prefixes after maximum aggregation: 19290 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 88717 Unique aggregates announced from the LACNIC address blocks: 39465 LACNIC Region origin ASes present in the Internet Routing Table: 6636 LACNIC Prefixes per ASN: 13.37 LACNIC Region origin ASes announcing only one prefix: 1817 LACNIC Region transit ASes present in the Internet Routing Table: 1234 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4162 Number of LACNIC addresses announced to Internet: 172656352 Equivalent to 10 /8s, 74 /16s and 134 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17844 Total AfriNIC prefixes after maximum aggregation: 3918 AfriNIC Deaggregation factor: 4.55 Prefixes being announced from the AfriNIC address blocks: 19920 Unique aggregates announced from the AfriNIC address blocks: 7176 AfriNIC Region origin ASes present in the Internet Routing Table: 1102 AfriNIC Prefixes per ASN: 18.08 AfriNIC Region origin ASes announcing only one prefix: 359 AfriNIC Region transit ASes present in the Internet Routing Table: 220 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 377 Number of AfriNIC addresses announced to Internet: 95038976 Equivalent to 5 /8s, 170 /16s and 46 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5257 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4083 410 407 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2797 11128 758 KIXS-AS-KR Korea Telecom, KR 17974 2780 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2766 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2481 1529 158 VNPT-AS-VN VNPT Corp, VN 7552 2359 1158 55 VIETEL-AS-AP Viettel Group, VN 9394 2169 4931 27 CTTNET China TieTong Telecommunications 4755 2081 421 211 TATACOMM-AS TATA Communications formerl 9808 2073 8699 32 CMNET-GD Guangdong Mobile Communication 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 6327 3366 1323 86 SHAW - Shaw Communications Inc., CA 22773 3303 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2170 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2060 2296 461 CHARTER-NET-HKY-NC - Charter Communicat 6389 1975 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 16509 1950 4077 588 AMAZON-02 - Amazon.com, Inc., US 209 1931 5062 645 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1861 331 247 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1694 234 570 CABLEONE - CABLE ONE, INC., US 701 1547 10589 625 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3519 186 23 ALJAWWALSTC-AS, SA 20940 2863 853 2066 AKAMAI-ASN1, US 8551 2493 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2065 1795 696 ROSTELECOM-AS, RU 34984 2051 330 439 TELLCOM-AS, TR 12479 1963 1069 124 UNI2-AS, ES 9121 1898 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 8402 1233 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1227 355 21 UKRTELNET, UA 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 8151 3651 3468 596 Uninet S.A. de C.V., MX 10620 3568 540 266 Telmex Colombia S.A., CO 11830 2646 370 66 Instituto Costarricense de Electricidad 6503 1628 437 53 Axtel, S.A.B. de C.V., MX 7303 1497 1022 194 Telecom Argentina S.A., AR 6147 1220 377 27 Telefonica del Peru S.A.A., PE 3816 1034 512 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 997 2256 200 CLARO S.A., BR 11172 918 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1075 398 48 LINKdotNET-AS, EG 37611 772 91 8 Afrihost, ZA 36903 737 370 135 MT-MPLS, MA 36992 677 1383 31 ETISALAT-MISR, EG 8452 524 1730 17 TE-AS TE-AS, EG 24835 516 850 15 RAYA-AS, EG 29571 436 36 10 CITelecom-AS, CI 37492 433 367 77 ORANGE-, TN 15399 350 35 7 WANANCHI-, KE 37342 343 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5257 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4083 410 407 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 3651 3468 596 Uninet S.A. de C.V., MX 10620 3568 540 266 Telmex Colombia S.A., CO 39891 3519 186 23 ALJAWWALSTC-AS, SA 6327 3366 1323 86 SHAW - Shaw Communications Inc., CA 22773 3303 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2863 853 2066 AKAMAI-ASN1, US 4766 2797 11128 758 KIXS-AS-KR Korea Telecom, KR 17974 2780 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4083 3676 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3519 3496 ALJAWWALSTC-AS, SA 10620 3568 3302 Telmex Colombia S.A., CO 6327 3366 3280 SHAW - Shaw Communications Inc., CA 22773 3303 3157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3651 3055 Uninet S.A. de C.V., MX 17974 2780 2704 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2646 2580 Instituto Costarricense de Electricidad y Telec 8551 2493 2451 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 45899 2481 2323 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64710 PRIVATE 39.134.26.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.28.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.30.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.31.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.20.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.22.0/24 56042 CMNET-SHANXI-AP China Mobile c 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 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.64.0.0/15 4804 MPX-AS Microplex PTY LTD, AU Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:285 /13:550 /14:1064 /15:1862 /16:13342 /17:7740 /18:13630 /19:25246 /20:38966 /21:44009 /22:81970 /23:66887 /24:376085 /25:827 /26:606 /27:655 /28:36 /29:21 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3158 3366 SHAW - Shaw Communications Inc., CA 39891 2946 3519 ALJAWWALSTC-AS, SA 22773 2547 3303 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2064 2170 MEGAPATH5-US - MegaPath Corporation, US 11830 1992 2646 Instituto Costarricense de Electricidad y Telec 8551 1957 2493 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1628 1861 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1560 3568 Telmex Colombia S.A., CO 11492 1502 1694 CABLEONE - CABLE ONE, INC., US 9121 1370 1898 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1567 2:818 4:18 5:2612 6:38 8:1087 9:1 12:1851 13:181 14:1742 15:29 16:3 17:183 18:76 20:53 21:1 23:2473 24:1929 25:2 27:2349 31:1968 32:87 35:22 36:452 37:2446 38:1443 39:156 40:101 41:3039 42:524 43:1952 44:88 45:3386 46:2857 47:191 49:1369 50:1043 51:35 52:912 54:354 55:5 56:7 57:42 58:1568 59:992 60:373 61:1999 62:1786 63:1832 64:4611 65:2240 66:4495 67:2296 68:1189 69:3178 70:1133 71:588 72:2090 74:2687 75:391 76:423 77:1545 78:1573 79:1891 80:1434 81:1418 82:1062 83:757 84:996 85:1925 86:484 87:1216 88:893 89:2307 90:174 91:6254 92:1036 93:2356 94:2424 95:2710 96:669 97:352 98:958 99:107 100:153 101:1480 102:9 103:16395 104:3200 105:211 106:517 107:1784 108:820 109:2926 110:1508 111:1729 112:1271 113:1374 114:1072 115:1602 116:1711 117:1632 118:2176 119:1649 120:734 121:1065 122:2403 123:1914 124:1474 125:1821 128:960 129:576 130:442 131:1563 132:605 133:194 134:975 135:229 136:446 137:456 138:1994 139:550 140:381 141:678 142:762 143:922 144:795 145:193 146:1146 147:706 148:1553 149:630 150:718 151:1003 152:738 153:303 154:971 155:738 156:736 157:755 158:597 159:1621 160:834 161:731 162:2543 163:530 164:939 165:1472 166:384 167:1343 168:3131 169:791 170:3624 171:402 172:1022 173:1895 174:838 175:771 176:1891 177:4014 178:2494 179:1177 180:2232 181:2114 182:2394 183:811 184:889 185:11722 186:3387 187:2353 188:2607 189:1935 190:8198 191:1348 192:9718 193:5853 194:4754 195:3967 196:2287 197:1468 198:5550 199:5877 200:7225 201:4862 202:10424 203:10004 204:4552 205:2871 206:3060 207:3087 208:3981 209:3880 210:3978 211:2072 212:2892 213:2586 214:869 215:65 216:5726 217:2098 218:892 219:624 220:1696 221:944 222:731 223:1206 End of report From michael at wi-fiber.io Wed Dec 6 21:38:20 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Wed, 6 Dec 2017 14:38:20 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others Message-ID: I am a local WISP. And my customers have trouble reaching Hulu, Disney now, and previously netflix and amazon prime(both resolved). I have emailed, mailed, and called both HULU and Disney now to get my 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) from their services. They have replied saying it takes 3-5 days to resolve the issue, that was several weeks ago. Can i get contact from those two services that can help my customers reach their services, thank you. Thank you for the help. -Michael From aa at qrator.net Wed Dec 6 21:54:49 2017 From: aa at qrator.net (Alexander Azimov) Date: Thu, 7 Dec 2017 00:54:49 +0300 Subject: Qrator Radar - Peerings In-Reply-To: References: <1781394974.133.1512525453468.JavaMail.mhammett@ThunderFuck> <494787106.163.1512525987081.JavaMail.mhammett@ThunderFuck> <1888817684.546.1512564117732.JavaMail.mhammett@ThunderFuck> Message-ID: Job, thank you for the intro. :) Dear Mike, the radar project is operating its own BGP collector system which improves when we have more sessions and loses data, when BGP sessions are going down. While it's overall amount is constantly growing (it reached 400 a month ago), there are sessions that disconnect from our RR. Visibility of peering relations is most vulnerable in this case because they are not globally visible. So, when one ISP shutdowns session there may be a decrease in numbers of peers for this ISP and its providers. At the moment we are not contacting users when BGP session goes down, maybe we should reconsider these politics. 6 дек. 2017 г. 5:47 PM пользователь "Job Snijders" написал: On Wed, 6 Dec 2017 at 15:42, Mike Hammett wrote: > I haven't brought it up with them, no. I didn't think it was a mass issue > until last night. I wanted to check with other users before I went to them. > Maybe I should have done the opposite. Yes, you should’ve. The Qrator folks are good people. Kind regards, Job From luke at flem.io Thu Dec 7 09:45:25 2017 From: luke at flem.io (Luke) Date: Thu, 7 Dec 2017 20:45:25 +1100 Subject: Poor speed to AWS In-Reply-To: References: Message-ID: <89A4FD4E-E73C-4AA3-B62F-BC57356C7129@flem.io> Hey Eric, have you tried contacting their NOC? amzn-noc-contact at amazon.com https://peeringdb.com/net/1418 > On 7 Dec 2017, at 13:08, Eric Dugas wrote: > > Anyone from AWS can contact me off-list? We peer with AS16509 in Montreal and Toronto and get really good speed to US-EAST-1, US-EAST-2 and of course CA-CENTRAL-1 but anything else outside the east coast (US-WEST-1 and US-WEST-2 more precisely) is about ten times slower even on multi-threaded HTTP(S) or SCP/SFTP transfers. Goes through two of our transit providers, Telia and Zayo. > > Thanks > Eric From Ryan.Hamel at quadranet.com Fri Dec 8 03:13:57 2017 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 8 Dec 2017 03:13:57 +0000 Subject: Static Routing 172.16.0.0/32 Message-ID: Greetings, A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to have a single known IP address be static routed to a regions closest server. While I understand the IP address does work (pings and what not), I don't feel this should be the proper IP address used, but something more feasible like a usable IP in a dedicated range (172.31.0.0/24 for example). I would to hear everyone's thoughts on this, as this the first IP address in an RFC1918 range. Thanks, -- Ryan Hamel ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud From hf0002+nanog at uah.edu Fri Dec 8 19:57:08 2017 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Fri, 08 Dec 2017 19:57:08 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: I think I'd rate this one as "gross but technically not breaking any rules I suppose." (I couldn't find any at first glance, anyway.) On Fri, Dec 8, 2017 at 1:55 PM Ryan Hamel wrote: > Greetings, > > A colleague of mine has static routed 172.16.0.0/32 to a usable IP > address, to have a single known IP address be static routed to a regions > closest server. While I understand the IP address does work (pings and what > not), I don't feel this should be the proper IP address used, but something > more feasible like a usable IP in a dedicated range (172.31.0.0/24 for > example). > > I would to hear everyone's thoughts on this, as this the first IP address > in an RFC1918 range. > > Thanks, > > -- > Ryan Hamel > ryan.hamel at quadranet.com | +1 (888) 578-2372 <(888)%20578-2372> > QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From job at instituut.net Fri Dec 8 20:02:24 2017 From: job at instituut.net (Job Snijders) Date: Fri, 08 Dec 2017 20:02:24 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: Nothing wrong with using xxx.0 or xxx::0 in the context of a host route (/32 or /128). From valdis.kletnieks at vt.edu Fri Dec 8 20:09:49 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 08 Dec 2017 15:09:49 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: <45974.1512763789@turing-police.cc.vt.edu> On Fri, 08 Dec 2017 03:13:57 +0000, Ryan Hamel said: > Greetings, > A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, > to have a single known IP address be static routed to a regions closest server. > While I understand the IP address does work (pings and what not), I don't feel > this should be the proper IP address used, but something more feasible like a > usable IP in a dedicated range (172.31.0.0/24 for example). Probably depends on what your colleague is trying to do. Nothing in the rules says the .0 address on a subnet is reserved (though you're in for a surprise if there's any gear still on the net with a 4.2BSD stack). > I would to hear everyone's thoughts on this, as this the first IP address in > an RFC1918 range. At some point, some chucklehead is going to look at that .0.0 and mentally think /16, and things will go pear-shaped pretty quickly.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Dec 8 20:09:57 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 8 Dec 2017 15:09:57 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: On Fri, Dec 8, 2017 at 3:02 PM, Job Snijders wrote: > Nothing wrong with using xxx.0 or xxx::0 in the context of a host route > (/32 or /128). > note that in times past (perhaps even now marked historical) there were platforms which got unhappy with network/broadcast addresses being used as host addresses... At least some windows platforms balked at .0 or .255 host addresses (even if that address was 'off-net' from them). maybe this is all history though :) From job at instituut.net Fri Dec 8 20:13:54 2017 From: job at instituut.net (Job Snijders) Date: Fri, 08 Dec 2017 20:13:54 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2017 at 23:09, Christopher Morrow wrote: > On Fri, Dec 8, 2017 at 3:02 PM, Job Snijders wrote: > Nothing wrong with using xxx.0 or xxx::0 in the context of a host route >> (/32 or /128). >> > > note that in times past (perhaps even now marked historical) there were > platforms which got unhappy with network/broadcast addresses being used as > host addresses... > > At least some windows platforms balked at .0 or .255 host addresses (even > if that address was 'off-net' from them). > > maybe this is all history though :) > It is 2017... if you encounter such platforms you take them out back and “set them free”. :-) We can, and must, expect CIDR compliance these days. Kind regards, Job From bill at herrin.us Fri Dec 8 21:28:29 2017 From: bill at herrin.us (William Herrin) Date: Fri, 8 Dec 2017 16:28:29 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel wrote: > A colleague of mine has static routed 172.16.0.0/32 to a usable IP > address, to have a single known IP address be static routed to a regions > closest server. While I understand the IP address does work (pings and what > not), I don't feel this should be the proper IP address used, but something > more feasible like a usable IP in a dedicated range (172.31.0.0/24 for > example). > Hi Ryan, Some clarifications: 1. You say, "static routed to a regions closest server." What do you mean by that? A static-routed anycast address? 2. In what reachability context? Is this a private network? An ISP network where the reachability should be the ISP and its customers? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Fri Dec 8 21:44:45 2017 From: bill at herrin.us (William Herrin) Date: Fri, 8 Dec 2017 16:44:45 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel wrote: > 1. A single known ip address that redirects to the closest internal repo server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static route. Hi Ryan, Maybe if would help if you write the extended version because that's about as clear as mud. First you asked about routing. Now you imply HTTP. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Fri Dec 8 22:25:58 2017 From: bill at herrin.us (William Herrin) Date: Fri, 8 Dec 2017 17:25:58 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> References: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> Message-ID: On Fri, Dec 8, 2017 at 4:50 PM, Ryan Hamel wrote: > > I'm not implying HTTP, I'm implying a static route at each sites private layer 3 router (it'll move to BGP in the future). The repository server listens on the IP as well. > > My original question was the fact of using 172.16.0.0/32 as a usable IP address (not even caring about anycast). > Internal private network that is reachable by clients. Hi Ryan, Clients meaning employee computers or clients meaning other networks who subscribe to your service and connect with a VPN? The the former, save yourself grief and use a different /32. For the latter, it's semi-clever. It neatly avoids the problem of customers using the same RFC1918 addresses as you. Even if they're using a subnet like 172.16.0.0/24, a /32 route can usually override that one address without ill effect. It's only semi-clever because the .0 address is a corner case in the code and corner cases are where bugs are most likely to happen. And if you're sending clients from that address to another host with a regular 172.16 address anyway... Regards, Bill Herrin > > > -------- Original message -------- > From: William Herrin > Date: 12/8/17 1:45 PM (GMT-08:00) > To: Ryan Hamel > Cc: nanog at nanog.org > Subject: Re: Static Routing 172.16.0.0/32 > > On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel > wrote: > > 1. A single known ip address that redirects to the closest internal repo > server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by > static route. > > Hi Ryan, > > Maybe if would help if you write the extended version because that's about > as clear as mud. First you asked about routing. Now you imply HTTP. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From math at sizone.org Fri Dec 8 22:44:11 2017 From: math at sizone.org (Ken Chase) Date: Fri, 8 Dec 2017 17:44:11 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> Message-ID: <20171208224411.GE13723@sizone.org> why not use 192.0.2.0/24 addrs? lots of other ranges you could probably use safely. https://en.wikipedia.org/wiki/Reserved_IP_addresses Using .0 you're asking to exercise bugs and undefined implimentation choices of various tcp stacks and resolvers out there on myriad devices. Clever collision avoidance, but relies on a prayer. (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it used to lock the OS up.... fun times. Someone had pointed some popular domain at us by accident, and having no entry and no negative caching of the day meant we were being hammerred on our 10mbps uplink, had to set something to get cached, so we did... several hours later a microsoft engineer called us and pleaded with us to use a different IP. :) /kc On Fri, Dec 08, 2017 at 05:25:58PM -0500, William Herrin said: >On Fri, Dec 8, 2017 at 4:50 PM, Ryan Hamel wrote: >> >> I'm not implying HTTP, I'm implying a static route at each sites private >layer 3 router (it'll move to BGP in the future). The repository server >listens on the IP as well. >> >> My original question was the fact of using 172.16.0.0/32 as a usable IP >address (not even caring about anycast). > >> Internal private network that is reachable by clients. > >Hi Ryan, > >Clients meaning employee computers or clients meaning other networks who >subscribe to your service and connect with a VPN? > >The the former, save yourself grief and use a different /32. > >For the latter, it's semi-clever. It neatly avoids the problem of customers >using the same RFC1918 addresses as you. Even if they're using a subnet >like 172.16.0.0/24, a /32 route can usually override that one address >without ill effect. > >It's only semi-clever because the .0 address is a corner case in the code >and corner cases are where bugs are most likely to happen. And if you're >sending clients from that address to another host with a regular 172.16 >address anyway... > >Regards, >Bill Herrin > > > > >> >> >> -------- Original message -------- >> From: William Herrin >> Date: 12/8/17 1:45 PM (GMT-08:00) >> To: Ryan Hamel >> Cc: nanog at nanog.org >> Subject: Re: Static Routing 172.16.0.0/32 >> >> On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel >> wrote: >> > 1. A single known ip address that redirects to the closest internal repo >> server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by >> static route. >> >> Hi Ryan, >> >> Maybe if would help if you write the extended version because that's about >> as clear as mud. First you asked about routing. Now you imply HTTP. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: -- Ken Chase - math at sizone.org Guelph Canada From job at instituut.net Fri Dec 8 22:47:09 2017 From: job at instituut.net (Job Snijders) Date: Fri, 8 Dec 2017 22:47:09 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: <20171208224411.GE13723@sizone.org> References: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> <20171208224411.GE13723@sizone.org> Message-ID: On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase wrote: > why not use 192.0.2.0/24 addrs? > > lots of other ranges you could probably use safely. > > https://en.wikipedia.org/wiki/Reserved_IP_addresses > > Using .0 you're asking to exercise bugs and undefined implimentation choices > of various tcp stacks and resolvers out there on myriad devices. Clever collision > avoidance, but relies on a prayer. Please stop spreading Fear, Uncertainty and Doubt about valid CIDR addresses. :-) > (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it > used to lock the OS up.... fun times. Someone had pointed some popular domain > at us by accident, and having no entry and no negative caching of the day > meant we were being hammerred on our 10mbps uplink, had to set something to > get cached, so we did... several hours later a microsoft engineer called us > and pleaded with us to use a different IP. :) Microsoft ended support for Windows 95 on December 31th 2001.... Kind regards, Job From Ryan.Hamel at quadranet.com Fri Dec 8 21:37:50 2017 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 8 Dec 2017 21:37:50 +0000 Subject: Static Routing 172.16.0.0/32 Message-ID: 1. A single known ip address that redirects to the closest internal repo server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static route. 2. Internal private network that is reachable by clients. -------- Original message -------- From: William Herrin Date: 12/8/17 1:34 PM (GMT-08:00) To: Ryan Hamel Cc: nanog at nanog.org Subject: Re: Static Routing 172.16.0.0/32 On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel > wrote: A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to have a single known IP address be static routed to a regions closest server. While I understand the IP address does work (pings and what not), I don't feel this should be the proper IP address used, but something more feasible like a usable IP in a dedicated range (172.31.0.0/24 for example). Hi Ryan, Some clarifications: 1. You say, "static routed to a regions closest server." What do you mean by that? A static-routed anycast address? 2. In what reachability context? Is this a private network? An ISP network where the reachability should be the ISP and its customers? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Ryan.Hamel at quadranet.com Fri Dec 8 21:50:51 2017 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 8 Dec 2017 21:50:51 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: , Message-ID: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> I'm not implying HTTP, I'm implying a static route at each sites private layer 3 router (it'll move to BGP in the future). The repository server listens on the IP as well. My original question was the fact of using 172.16.0.0/32 as a usable IP address (not even caring about anycast). -------- Original message -------- From: William Herrin Date: 12/8/17 1:45 PM (GMT-08:00) To: Ryan Hamel Cc: nanog at nanog.org Subject: Re: Static Routing 172.16.0.0/32 On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel > wrote: > 1. A single known ip address that redirects to the closest internal repo server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static route. Hi Ryan, Maybe if would help if you write the extended version because that's about as clear as mud. First you asked about routing. Now you imply HTTP. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Ryan.Hamel at quadranet.com Fri Dec 8 21:55:34 2017 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 8 Dec 2017 21:55:34 +0000 Subject: Static Routing 172.16.0.0/32 Message-ID: <7181cefc2c8a4dad8f255e3f3fbd7177@LAX-MBX01.quadranet.local> > At some point, some chucklehead is going to look at that .0.0 and mentally think /16, and things will go pear-shaped pretty quickly.... Same for a /12, which is RFC1918. -------- Original message -------- From: valdis.kletnieks at vt.edu Date: 12/8/17 1:46 PM (GMT-08:00) To: Ryan Hamel Cc: nanog at nanog.org Subject: Re: Static Routing 172.16.0.0/32 On Fri, 08 Dec 2017 03:13:57 +0000, Ryan Hamel said: > Greetings, > A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, > to have a single known IP address be static routed to a regions closest server. > While I understand the IP address does work (pings and what not), I don't feel > this should be the proper IP address used, but something more feasible like a > usable IP in a dedicated range (172.31.0.0/24 for example). Probably depends on what your colleague is trying to do. Nothing in the rules says the .0 address on a subnet is reserved (though you're in for a surprise if there's any gear still on the net with a 4.2BSD stack). > I would to hear everyone's thoughts on this, as this the first IP address in > an RFC1918 range. > At some point, some chucklehead is going to look at that .0.0 and mentally think /16, and things will go pear-shaped pretty quickly.... From jason.w.kuehl at gmail.com Fri Dec 8 20:00:40 2017 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Fri, 8 Dec 2017 15:00:40 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: +1 for gross comment. On Fri, Dec 8, 2017 at 2:57 PM, Hunter Fuller wrote: > I think I'd rate this one as "gross but technically not breaking any rules > I suppose." (I couldn't find any at first glance, anyway.) > > On Fri, Dec 8, 2017 at 1:55 PM Ryan Hamel > wrote: > > > Greetings, > > > > A colleague of mine has static routed 172.16.0.0/32 to a usable IP > > address, to have a single known IP address be static routed to a regions > > closest server. While I understand the IP address does work (pings and > what > > not), I don't feel this should be the proper IP address used, but > something > > more feasible like a usable IP in a dedicated range (172.31.0.0/24 for > > example). > > > > I would to hear everyone's thoughts on this, as this the first IP address > > in an RFC1918 range. > > > > Thanks, > > > > -- > > Ryan Hamel > > ryan.hamel at quadranet.com | +1 (888) 578-2372 <(888)%20578-2372> > > QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud > > > > -- > > -- > Hunter Fuller > Network Engineer > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Systems and Infrastructure > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com From math at sizone.org Fri Dec 8 23:03:13 2017 From: math at sizone.org (Ken Chase) Date: Fri, 8 Dec 2017 18:03:13 -0500 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> <20171208224411.GE13723@sizone.org> Message-ID: <20171208230313.GF13723@sizone.org> Right - usage of network and broadcast addresses will suddenly make all the ToiletPaperLink devices upgrade themselves to a new firmware that the devs released posthaste to handle them properly... I like your upgrade-by-force ideas! (no, I do. Screw bad implimentations, let them be binned!) (Tell me about your v6 adoption plans now.) The Win95 thing was just a personal example of how these things can express themselves... was a good laugh at the time. The incidence and hilarity of similar events has not materially changed in the intervening decades, we'll all note. Have fun with your .0's people! Let us know how your support dept likes em. /kc On Fri, Dec 08, 2017 at 10:47:09PM +0000, Job Snijders said: >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase wrote: >> why not use 192.0.2.0/24 addrs? >> >> lots of other ranges you could probably use safely. >> >> https://en.wikipedia.org/wiki/Reserved_IP_addresses >> >> Using .0 you're asking to exercise bugs and undefined implimentation choices >> of various tcp stacks and resolvers out there on myriad devices. Clever collision >> avoidance, but relies on a prayer. > >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR >addresses. :-) > >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it >> used to lock the OS up.... fun times. Someone had pointed some popular domain >> at us by accident, and having no entry and no negative caching of the day >> meant we were being hammerred on our 10mbps uplink, had to set something to >> get cached, so we did... several hours later a microsoft engineer called us >> and pleaded with us to use a different IP. :) > >Microsoft ended support for Windows 95 on December 31th 2001.... > >Kind regards, > >Job -- Ken Chase - Guelph Canada From Kate.Gerry at quadranet.com Fri Dec 8 23:38:08 2017 From: Kate.Gerry at quadranet.com (Kate Gerry) Date: Fri, 8 Dec 2017 23:38:08 +0000 Subject: Static Routing 172.16.0.0/32 In-Reply-To: <20171208230313.GF13723@sizone.org> References: <67b257b67d9344eda541c123596a8245@LAX-MBX01.quadranet.local> <20171208224411.GE13723@sizone.org> <20171208230313.GF13723@sizone.org> Message-ID: In this example only semi-new devices with current OSes are accessing 172.16.0.0, concerns over old devices or a BSD4.2 machine hitting it is highly unlikely. To clarify Ryan's statement, the device in question is our software repository where we store OS software updates, for only recent versions of software, so it should not be an issue. Since we have multiple locations, and multiple software stores, we use 172.16.0.0 as the AnyCast address. I am glad that we have been able to stir up such a discussion, Ryan and I had the same conversation here so I am glad that he brought it to the group. -- Kate Gerry Network & Facilities Director  +1 (888) 578-2372 x206 / kate at quadranet.com  QuadraNet, Inc. / Dedicated Servers, Colocation, Cloud, QuadraNet Vest DDoS Protection Datacenters in Los Angeles, Dallas, Miami, Atlanta, Chicago & New Jersey -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: Friday, December 8, 2017 3:03 PM To: Job Snijders Cc: nanog at nanog.org Subject: Re: Static Routing 172.16.0.0/32 Right - usage of network and broadcast addresses will suddenly make all the ToiletPaperLink devices upgrade themselves to a new firmware that the devs released posthaste to handle them properly... I like your upgrade-by-force ideas! (no, I do. Screw bad implimentations, let them be binned!) (Tell me about your v6 adoption plans now.) The Win95 thing was just a personal example of how these things can express themselves... was a good laugh at the time. The incidence and hilarity of similar events has not materially changed in the intervening decades, we'll all note. Have fun with your .0's people! Let us know how your support dept likes em. /kc On Fri, Dec 08, 2017 at 10:47:09PM +0000, Job Snijders said: >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase wrote: >> why not use 192.0.2.0/24 addrs? >> >> lots of other ranges you could probably use safely. >> >> https://en.wikipedia.org/wiki/Reserved_IP_addresses >> >> Using .0 you're asking to exercise bugs and undefined implimentation choices >> of various tcp stacks and resolvers out there on myriad devices. Clever collision >> avoidance, but relies on a prayer. > >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR >addresses. :-) > >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it >> used to lock the OS up.... fun times. Someone had pointed some popular domain >> at us by accident, and having no entry and no negative caching of the day >> meant we were being hammerred on our 10mbps uplink, had to set something to >> get cached, so we did... several hours later a microsoft engineer called us >> and pleaded with us to use a different IP. :) > >Microsoft ended support for Windows 95 on December 31th 2001.... > >Kind regards, > >Job -- Ken Chase - Guelph Canada From kmedcalf at dessus.com Sat Dec 9 01:23:31 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 08 Dec 2017 18:23:31 -0700 Subject: Static Routing 172.16.0.0/32 In-Reply-To: Message-ID: And thank god for that. Since Microsoft stopped diddle-farting with Windows 98 is was never infested with the UDP "Execute Payload with NT AUTHORITY\SYSTEM" flag that appeared in all later versions of Windows TCP/IP stack. As Windows 98 worked on the day after Microsoft stopped diddling with it, so it will work on that day + N, for every value of N. The most wonderful thing that can happen to a Microsoft product is that they stop diddling with it for at that point it stops being a moving target that works differently from one minute to the next. Additionally, features cannot be removed from the product as usually happens with each downgrade (I think Microsoft calls them upgrades) of the products. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Job >Snijders >Sent: Friday, 8 December, 2017 15:47 >To: Ken Chase >Cc: nanog at nanog.org >Subject: Re: Static Routing 172.16.0.0/32 > >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase wrote: >> why not use 192.0.2.0/24 addrs? >> >> lots of other ranges you could probably use safely. >> >> https://en.wikipedia.org/wiki/Reserved_IP_addresses >> >> Using .0 you're asking to exercise bugs and undefined >implimentation choices >> of various tcp stacks and resolvers out there on myriad devices. >Clever collision >> avoidance, but relies on a prayer. > >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR >addresses. :-) > >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows >95 - it >> used to lock the OS up.... fun times. Someone had pointed some >popular domain >> at us by accident, and having no entry and no negative caching of >the day >> meant we were being hammerred on our 10mbps uplink, had to set >something to >> get cached, so we did... several hours later a microsoft engineer >called us >> and pleaded with us to use a different IP. :) > >Microsoft ended support for Windows 95 on December 31th 2001.... > >Kind regards, > >Job From rgolodner at infratection.com Sun Dec 10 18:36:26 2017 From: rgolodner at infratection.com (Richard) Date: Sun, 10 Dec 2017 12:36:26 -0600 Subject: quake3-master-getservers: Message-ID: <4dc72101-09a3-0e6a-2c05-03c2210677a2@infratection.com>     NANOG group, at a client site who was complaining of having their Active Directory passwords changed every week. Found a PPTP which had been put in place by a ex employee. Fixed that.     I have no idea what a master-get servers is.     If anyone can ping me-off-list to educate me a bit more, please do.     Sincerely, Richard From swmike at swm.pp.se Sun Dec 10 19:16:21 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Dec 2017 20:16:21 +0100 (CET) Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2017, Ryan Hamel wrote: > Greetings, > > A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to have a single known IP address be static routed to a regions closest server. While I understand the IP address does work (pings and what not), I don't feel this should be the proper IP address used, but something more feasible like a usable IP in a dedicated range (172.31.0.0/24 for example). > > I would to hear everyone's thoughts on this, as this the first IP > address in an RFC1918 range. Last time I tried using the first address of a classful address block (which 172.16.0.0/32 would be) in Cisco IOS (classic), that didn't work properly. This was in IOS 12.0.x. You can't set up BGP peers to something in the network address in classful network space, for instance. So 172.16.0.0/32 or 172.16.255.255/32 wouldn't work (because it's first and last address of class B space), but 172.16.1.0 worked just fine (because in class B space, 172.16.1.0 isn't special). So while this has been allowed per standardssince mid 90:ties, it's not obvious that it'll work in all operating systems that might still be in use. -- Mikael Abrahamsson email: swmike at swm.pp.se From morrowc.lists at gmail.com Sun Dec 10 19:31:38 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Dec 2017 11:31:38 -0800 Subject: quake3-master-getservers: In-Reply-To: <4dc72101-09a3-0e6a-2c05-03c2210677a2@infratection.com> References: <4dc72101-09a3-0e6a-2c05-03c2210677a2@infratection.com> Message-ID: On Sun, Dec 10, 2017 at 10:36 AM, Richard wrote: > NANOG group, at a client site who was complaining of having their > Active Directory passwords changed every week. Found a PPTP which had been > put in place by a ex employee. Fixed that. > I think at the point you found a back door ... err, delete and re-install from known good media. From fgont at si6networks.com Mon Dec 11 12:23:11 2017 From: fgont at si6networks.com (Fernando Gont) Date: Mon, 11 Dec 2017 09:23:11 -0300 Subject: UPnP/IPv6 support in home routers? Message-ID: Folks, Anyone can comment on the UPnP support for IPv6 in home routers? Those that I have checked have UPnP support for IPv4, but not for IPv6 -- even when the home router does otherwise support IPv6. Looking at UPnP itself, it seems to allow opening holes at the IGD, but on a fully-specified (local ip, local port, remote ip, remote port) basis, which kind of sucks -- as one would want to be able to whitelist all ports for a given IP address, or at least (local ip, local port). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From valdis.kletnieks at vt.edu Mon Dec 11 13:44:55 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 11 Dec 2017 08:44:55 -0500 Subject: UPnP/IPv6 support in home routers? In-Reply-To: References: Message-ID: <87899.1512999895@turing-police.cc.vt.edu> On Mon, 11 Dec 2017 09:23:11 -0300, Fernando Gont said: > Anyone can comment on the UPnP support for IPv6 in home routers? > > Those that I have checked have UPnP support for IPv4, but not for IPv6 > -- even when the home router does otherwise support IPv6. Well, there's a bit of a problem there. Near as I can tell, to get IPv6 support you need to use IGDv2. Unfortunately, if you want your Xbox or Playstation to be able to work, you need to be using IGDv1. Guess what almost everybody chooses to do? (Been there, done that - had to rebuild miniupnpd for OpenWRT/Lede because it built with v2 by default) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From EPers at ansencorp.com Mon Dec 11 23:34:07 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Mon, 11 Dec 2017 23:34:07 +0000 Subject: quake3-master-getservers: In-Reply-To: <4dc72101-09a3-0e6a-2c05-03c2210677a2@infratection.com> References: <4dc72101-09a3-0e6a-2c05-03c2210677a2@infratection.com> Message-ID: https://nmap.org/nsedoc/scripts/quake3-master-getservers.html I'd nuke the entire environment from orbit, no telling what other nasty surprises they left for you -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Richard Sent: Sunday, December 10, 2017 1:36 PM To: nanog at nanog.org Subject: quake3-master-getservers:     NANOG group, at a client site who was complaining of having their Active Directory passwords changed every week. Found a PPTP which had been put in place by a ex employee. Fixed that.     I have no idea what a master-get servers is.     If anyone can ping me-off-list to educate me a bit more, please do.     Sincerely, Richard From ahebert at pubnix.net Tue Dec 12 00:34:41 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 11 Dec 2017 19:34:41 -0500 Subject: Packets Broker (aka: WAN Accelerator (aka: Congestion Algorithms (aka: You call yourself a network engineer?) ) Message-ID: <56775e90-546d-3c9f-714d-1d14a3204823@pubnix.net>     Hi, We're used to fix Long Fat Network issues ourself...     But I'm stuck in a case where we need to transparently proxy TCP connections to apply congestion algorithms (cubic, htcp, etc) since some of our newer customers are ... well ... refusing to acknowledge that reality.     Any good lead for a 1U platform averaging ~10Gbps of throughput, that isn't some PC hack in a box?     ( off-lists would be nice, unless you think that could be useful to others )     Thanks for your time. -- ----- 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 From selphie.keller at gmail.com Tue Dec 12 00:39:03 2017 From: selphie.keller at gmail.com (Selphie Keller) Date: Mon, 11 Dec 2017 17:39:03 -0700 Subject: Packets Broker (aka: WAN Accelerator (aka: Congestion Algorithms (aka: You call yourself a network engineer?) ) In-Reply-To: <56775e90-546d-3c9f-714d-1d14a3204823@pubnix.net> References: <56775e90-546d-3c9f-714d-1d14a3204823@pubnix.net> Message-ID: I have some good success with kcptun - https://github.com/xtaci/kcptun it's designed to handle problematic links. On 11 December 2017 at 17:34, Alain Hebert wrote: > Hi, > > We're used to fix Long Fat Network issues ourself... > > But I'm stuck in a case where we need to transparently proxy TCP > connections to apply congestion algorithms (cubic, htcp, etc) since some of > our newer customers are ... well ... refusing to acknowledge that reality. > > Any good lead for a 1U platform averaging ~10Gbps of throughput, that > isn't some PC hack in a box? > > ( off-lists would be nice, unless you think that could be useful to > others ) > > Thanks for your time. > > -- > ----- > 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 > > From kmedcalf at dessus.com Tue Dec 12 03:09:19 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 11 Dec 2017 20:09:19 -0700 Subject: UPnP/IPv6 support in home routers? In-Reply-To: Message-ID: <38bc46b94d696448b803f60956c700e9@mail.dessus.com> UPnP is the spawn of Beelzebub. Implementation by Bugs Bunny's maroons for use by other maroons is ok, I suppose, as long as those of us who are not maroons can turn the evil off. However, if those maroons start whining about all the crap that happened to them because they enabled UPnP they better to be able to take the "I told you so you stupid maroon" in stride as a perfectly adequate and entirely correct statement of fact. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Fernando >Gont >Sent: Monday, 11 December, 2017 05:23 >To: NANOG >Subject: UPnP/IPv6 support in home routers? > >Folks, > >Anyone can comment on the UPnP support for IPv6 in home routers? > >Those that I have checked have UPnP support for IPv4, but not for >IPv6 >-- even when the home router does otherwise support IPv6. > >Looking at UPnP itself, it seems to allow opening holes at the IGD, >but >on a fully-specified (local ip, local port, remote ip, remote port) >basis, which kind of sucks -- as one would want to be able to >whitelist >all ports for a given IP address, or at least (local ip, local port). > >Thanks! > >Best regards, >-- >Fernando Gont >SI6 Networks >e-mail: fgont at si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From amekkaoui at mektel.ca Tue Dec 12 14:47:17 2017 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Tue, 12 Dec 2017 09:47:17 -0500 Subject: Switch/Router Message-ID: <006a01d37358$1bfc6b40$53f541c0$@ca> Hi I am looking for a router preferably (or switch) with the following specs: 1- Carrier grade 2- Dual power supply 3- 1RU 4- Gig and 10Gig interfaces. 5- Does support protocols like BGP, etc. Any recommendation please? Your help will be appreciated. Thank you KARIM M. MEKTEL INC. Tél. : 1(855) 563-5835 poste 404 www.mektel.ca From amekkaoui at mektel.ca Tue Dec 12 14:52:50 2017 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Tue, 12 Dec 2017 09:52:50 -0500 Subject: Switch/Router In-Reply-To: <006a01d37358$1bfc6b40$53f541c0$@ca> References: <006a01d37358$1bfc6b40$53f541c0$@ca> Message-ID: <007201d37358$e27808b0$a7681a10$@ca> Also has to support features for monitoring and security like traffic per IP, attacks mitigation, etc. KARIM M. MEKTEL INC. Tél. : 1(855) 563-5835 poste 404 www.mektel.ca -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI Sent: December 12, 2017 9:47 AM To: nanog at nanog.org Subject: Switch/Router Hi I am looking for a router preferably (or switch) with the following specs: 1- Carrier grade 2- Dual power supply 3- 1RU 4- Gig and 10Gig interfaces. 5- Does support protocols like BGP, etc. Any recommendation please? Your help will be appreciated. Thank you KARIM M. MEKTEL INC. Tél. : 1(855) 563-5835 poste 404 www.mektel.ca From cra at WPI.EDU Tue Dec 12 15:37:02 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 12 Dec 2017 10:37:02 -0500 Subject: Switch/Router In-Reply-To: <006a01d37358$1bfc6b40$53f541c0$@ca> References: <006a01d37358$1bfc6b40$53f541c0$@ca> Message-ID: <20171212153702.GY14566@angus.ind.wpi.edu> Juniper MX150, except only single PS. But they are cheap enough you could buy two. Upside: most of the MX feature set is available because it is vMX (software) inside. QFX5110 is more expensive but has more ports and dual PS. Downside: Broadcom chipset limitations. On Tue, Dec 12, 2017 at 09:47:17AM -0500, K MEKKAOUI wrote: > Hi > > > > I am looking for a router preferably (or switch) with the following specs: > > 1- Carrier grade > > 2- Dual power supply > > 3- 1RU > > 4- Gig and 10Gig interfaces. > > 5- Does support protocols like BGP, etc. > > > > Any recommendation please? Your help will be appreciated. From lista-gter at tbonet.net.br Tue Dec 12 15:42:15 2017 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Tue, 12 Dec 2017 13:42:15 -0200 Subject: Switch/Router In-Reply-To: <007201d37358$e27808b0$a7681a10$@ca> References: <006a01d37358$1bfc6b40$53f541c0$@ca> <007201d37358$e27808b0$a7681a10$@ca> Message-ID: <204e2a6c-903f-3cd0-1bd4-54d423cc7433@tbonet.net.br> Hi Karim! I think that Huawei S5720-EI can serve your needs. Best Regards, João Butzke Em 12/12/2017 12:52, K MEKKAOUI escreveu: > Also has to support features for monitoring and security like traffic per > IP, attacks mitigation, etc. > > KARIM M. > MEKTEL INC. > Tél. : 1(855) 563-5835 poste 404 > www.mektel.ca > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI > Sent: December 12, 2017 9:47 AM > To: nanog at nanog.org > Subject: Switch/Router > > Hi > > > > I am looking for a router preferably (or switch) with the following specs: > > 1- Carrier grade > > 2- Dual power supply > > 3- 1RU > > 4- Gig and 10Gig interfaces. > > 5- Does support protocols like BGP, etc. > > > > Any recommendation please? Your help will be appreciated. > > > > Thank you > > > > KARIM M. > > MEKTEL INC. > > Tél. : 1(855) 563-5835 poste 404 > > www.mektel.ca > > > > From ESundberg at nitelusa.com Tue Dec 12 16:46:08 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 12 Dec 2017 16:46:08 +0000 Subject: Switch/Router In-Reply-To: <204e2a6c-903f-3cd0-1bd4-54d423cc7433@tbonet.net.br> References: <006a01d37358$1bfc6b40$53f541c0$@ca> <007201d37358$e27808b0$a7681a10$@ca> <204e2a6c-903f-3cd0-1bd4-54d423cc7433@tbonet.net.br> Message-ID: Cisco ASR9001 - https://www.cisco.com/c/en/us/products/collateral/routers/asr-9001-router/data_sheet_c78-685687.html They are also coming out with a Cisco ASR9901 shortly, I would talk to cisco rep about this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of João Butzke Sent: Tuesday, December 12, 2017 9:42 AM To: nanog at nanog.org Subject: Re: Switch/Router Hi Karim! I think that Huawei S5720-EI can serve your needs. Best Regards, João Butzke Em 12/12/2017 12:52, K MEKKAOUI escreveu: > Also has to support features for monitoring and security like traffic > per IP, attacks mitigation, etc. > > KARIM M. > MEKTEL INC. > Tél. : 1(855) 563-5835 poste 404 > www.mektel.ca > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI > Sent: December 12, 2017 9:47 AM > To: nanog at nanog.org > Subject: Switch/Router > > Hi > > > > I am looking for a router preferably (or switch) with the following specs: > > 1- Carrier grade > > 2- Dual power supply > > 3- 1RU > > 4- Gig and 10Gig interfaces. > > 5- Does support protocols like BGP, etc. > > > > Any recommendation please? Your help will be appreciated. > > > > Thank you > > > > KARIM M. > > MEKTEL INC. > > Tél. : 1(855) 563-5835 poste 404 > > www.mektel.ca > > > > From pbmarcos at inf.ufrgs.br Mon Dec 11 12:26:54 2017 From: pbmarcos at inf.ufrgs.br (Pedro de Botelho Marcos) Date: Mon, 11 Dec 2017 15:26:54 +0300 Subject: Survey about interconnection agreements Message-ID: Dear community, We are a group of researchers conducting a survey about the future of the interconnection agreements. Our goal is to understand the current process and reasons for establishing inter-domain interconnection agreements and how this ecosystem can be improved in the future. Can you please help us by answering a set few objective questions reflecting your views? This survey will take you less than 10 minutes, and you can earn a prize by doing it! Survey URL: https://goo.gl/bJxJzZ This survey is in the context of our proposal to create truly dynamic interconnection agreements. Please watch this short (3 minutes) introductory video. https://youtu.be/DVbjR7JQTvo We are offering a redeemable prize worth 25.00 USD (twenty-five United States Dollars) for the first 200 (two hundred) respondents that meet the following eligibility criteria: - You must be a peering coordinator or a network operator working with inter-domain interconnection aspects - Your organization must operate an autonomous system (AS) - You must be able to provide personal information that allows us to verify if you are eligible You can also participate in the survey without disclosing your identity. In this case, you are not eligible for the prize. Research records will be kept confidential. All data will be anonymous and collected and published in a manner that would not allow identification of your identity. A summary of the aggregate results will be made available to the community and used as a part of a scientific article. If you have any question, do not hesitate to contact us. Also, if you want to know more about our project, please visit our website: https://dynam-ix.github.io Thank you very much, -- Pedro Marcos Federal University of Rio Grande do Sul From Jacques.Latour at cira.ca Tue Dec 12 19:52:32 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Tue, 12 Dec 2017 19:52:32 +0000 Subject: Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico Message-ID: <4c8349da62f24de7b552f0410fd1a837@cira.ca> Hi All! The next ICANN DNSSEC Workshop will be on Wednesday, March 14, in San Juan, Puerto Rico. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan at isoc.org by **03 January 2017** Thanks, Jack Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN61meeting held from 10-15 March 2018 in San Juan, Puerto Rico. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Annual General Meeting in Abu Dhabi, UAE, https://schedule.icann.org/event/CbKE/dnssec-workshop-part-ii[schedule.icann.org], and https://schedule.icann.org/event/CbKF/dnssec-workshop-part-iii[schedule.icann.org]. At ICANN61 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include: * Innovative uses of APIs to do something new and different using DNSSEC/DANE. * Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email. * DNSSEC automation and deployment using CDS, CDNSKey, and CSYNC. * DNSSEC signing solutions and innovation. * Tools for automating the generation of DNSSEC/DANE records. * Services for monitoring or managing DNSSEC signing or validation. * Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG. Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC Activities For this panel we are seeking participation from those who have been involved in DNSSEC deployment and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Impact of Root Key Rollover We would like to bring together a panel of people who can talk about the impacts to ISPs, equipment providers and end users, and also what could be done to mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that could be affected by distribution of new root keys. If you have a specific concern about the Root Key Rollover we would like to hear from you. 3. Implementing next generation DNSSEC signing at Registries and DNS Operators Now that DNSSEC technology has matured many Registries, and DNS Operators have upgraded their legacy DNSSEC signing services with innovative solutions. * Real world use cases of HSMs and key management. * Signing at the edge. We would be interested in seeing presentations or demonstrations on those topics. 4. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 5. Innovation around DANE and DNSSEC application automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. 6. DNSSEC and DANE in the enterprise and in the enterprise tool set Enterprises and enterprise software can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises and enterprise software providers that have implemented DNSSEC on validation and/or signing processes and can address questions such as: * What enterprise software support or plan do you have to support DNSSEC? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to implement DNSSEC? * What enterprise tools and systems are available to assist enterprises in the deployment of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates? 7. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * Can you describe your experiences with negative Trust Anchors and operational realities? * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * Can you provide results and/or impacts of the impact of root key rollover? * What rollover technique do you use, i.e., RFC 5011 or other? In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan at isoc.org by **03 January 2017** We hope that you can join us. Thank you, Kathy Schnitt On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR Jacques Latour, CTO Canadian Internet Registration Authority (CIRA) cira.ca Tel.: (613) 237-5335 x294 From ahad at swiftelnetworks.com Wed Dec 13 00:30:07 2017 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Wed, 13 Dec 2017 11:30:07 +1100 Subject: Switch/Router In-Reply-To: References: <006a01d37358$1bfc6b40$53f541c0$@ca> <007201d37358$e27808b0$a7681a10$@ca> <204e2a6c-903f-3cd0-1bd4-54d423cc7433@tbonet.net.br> Message-ID: Hi Karim, If 1 x RU is a must have, then you might want to look at Cisco ASR1001-X, it comes with 6 x GigE and 2 x 10GE. It does have throughput limitation, check out the datasheet to ensure it meets your bandwidth requirements. Alternatively, the ASR9001 as suggested by Erik is a good entry level, multipurpose / carrier grade router which comes in 2RU form factor. Cheers Ahad On Wed, Dec 13, 2017 at 3:46 AM, Erik Sundberg wrote: > Cisco ASR9001 - https://www.cisco.com/c/en/us/products/collateral/routers/ > asr-9001-router/data_sheet_c78-685687.html > > They are also coming out with a Cisco ASR9901 shortly, I would talk to > cisco rep about this. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of João Butzke > Sent: Tuesday, December 12, 2017 9:42 AM > To: nanog at nanog.org > Subject: Re: Switch/Router > > Hi Karim! > > I think that Huawei S5720-EI can serve your needs. > > Best Regards, > João Butzke > > Em 12/12/2017 12:52, K MEKKAOUI escreveu: > > Also has to support features for monitoring and security like traffic > > per IP, attacks mitigation, etc. > > > > KARIM M. > > MEKTEL INC. > > Tél. : 1(855) 563-5835 poste 404 > > www.mektel.ca > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI > > Sent: December 12, 2017 9:47 AM > > To: nanog at nanog.org > > Subject: Switch/Router > > > > Hi > > > > > > > > I am looking for a router preferably (or switch) with the following > specs: > > > > 1- Carrier grade > > > > 2- Dual power supply > > > > 3- 1RU > > > > 4- Gig and 10Gig interfaces. > > > > 5- Does support protocols like BGP, etc. > > > > > > > > Any recommendation please? Your help will be appreciated. > > > > > > > > Thank you > > > > > > > > KARIM M. > > > > MEKTEL INC. > > > > Tél. : 1(855) 563-5835 poste 404 > > > > www.mektel.ca > > > > > > > > > From denys at visp.net.lb Wed Dec 13 01:06:24 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 13 Dec 2017 03:06:24 +0200 Subject: Broadcom chipset limitations Was: Switch/Router In-Reply-To: <20171212153702.GY14566@angus.ind.wpi.edu> References: <006a01d37358$1bfc6b40$53f541c0$@ca> <20171212153702.GY14566@angus.ind.wpi.edu> Message-ID: <5bf0044ceb605cb36a3b4e704d174665@visp.net.lb> What are those limitations? I started to be afraid from those, because just hit recently nasty hash collision issue with EX4550, with declared 32k mac's it badly choked on 28k macs, and even magic "mac-lookup-length" didn't helped. I'm considering EX4600, but afraid from it and that possibly other juniper models have hash collision issues too. (As said on KB32325, affected models EX3200, EX3300, EX4200, EX4500, EX4550, and EX6210 have 8192 hash table FDB entries, but it might be outdated) And till now vendor didn't make troubleshooting of this problem easier, when you upgrade from 12.x to 15.x, you get dead RE hitting load average 30+, and you can't even ssh to switch. On 2017-12-12 17:37, Chuck Anderson wrote: > Juniper MX150, except only single PS. But they are cheap enough you > could buy two. Upside: most of the MX feature set is available > because it is vMX (software) inside. > > QFX5110 is more expensive but has more ports and dual PS. Downside: > Broadcom chipset limitations. > > On Tue, Dec 12, 2017 at 09:47:17AM -0500, K MEKKAOUI wrote: >> Hi >> >> >> >> I am looking for a router preferably (or switch) with the following >> specs: >> >> 1- Carrier grade >> >> 2- Dual power supply >> >> 3- 1RU >> >> 4- Gig and 10Gig interfaces. >> >> 5- Does support protocols like BGP, etc. >> >> >> >> Any recommendation please? Your help will be appreciated. From baldur.norddahl at gmail.com Wed Dec 13 01:11:51 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 13 Dec 2017 02:11:51 +0100 Subject: Switch/Router In-Reply-To: <006a01d37358$1bfc6b40$53f541c0$@ca> References: <006a01d37358$1bfc6b40$53f541c0$@ca> Message-ID: The ZTE 5928 has 24x 1G and 4x 10G. It has dual PSU with options for both AC and DC power. It will do BGP, MPLS etc with about 30.000 routes. Price is approximately 2k USD. If you need more 10G ports there is the ZTE 5960 with 24x 10G plus 2x 40G at approximately twice the price. Also take a peek at the switches at fs.com. Den 12. dec. 2017 15.48 skrev "K MEKKAOUI" : Hi I am looking for a router preferably (or switch) with the following specs: 1- Carrier grade 2- Dual power supply 3- 1RU 4- Gig and 10Gig interfaces. 5- Does support protocols like BGP, etc. Any recommendation please? Your help will be appreciated. Thank you KARIM M. MEKTEL INC. Tél. : 1(855) 563-5835 poste 404 www.mektel.ca From jason+nanog at lixfeld.ca Wed Dec 13 14:46:00 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 13 Dec 2017 09:46:00 -0500 Subject: Any Telus (AS852) BGP customers in the house? Message-ID: Hello! As a fellow AS852 BGP customer, I’m looking to chat with other AS852 BGP customers on the topic of modifications to the prefix filters attached to your BGP session(s). Specifically, understanding the procedure Telus wants you to follow to request any changes, how long it takes the requested changes to be implemented, and whether or not there are any costs associated with those changes. Off-list is probably appropriate. Thanks in advance! From jason at unlimitednet.us Wed Dec 13 14:51:24 2017 From: jason at unlimitednet.us (Jason Canady) Date: Wed, 13 Dec 2017 09:51:24 -0500 Subject: Target.com NOC Contact Message-ID: Hello, Would anyone here have a contact for Target.com NOC? Thank you! - Jason From ryangard at gmail.com Wed Dec 13 18:20:51 2017 From: ryangard at gmail.com (Ryan Gard) Date: Wed, 13 Dec 2017 13:20:51 -0500 Subject: Ticketmaster? In-Reply-To: References: Message-ID: No NAT employed in any way, shape or form currently. On Sun, Dec 3, 2017 at 10:34 PM, Doug Barton wrote: > On 12/02/2017 02:39 PM, Ryan Gard wrote: > >> *Oh, you must be sharing your IP with everyone else in your area* >> > > CGNAT by any chance? > > -- Ryan Gard From brent at brentrjones.com Wed Dec 13 19:31:46 2017 From: brent at brentrjones.com (Brent Jones) Date: Wed, 13 Dec 2017 11:31:46 -0800 Subject: Ticketmaster? In-Reply-To: References: Message-ID: Ticketmaster would block old $employer SP networks too, no NAT, across many /21's Never did get it resolved, I think they just try and protect their own bot networks, end-users be damned. On Sat, Dec 2, 2017 at 2:39 PM, Ryan Gard wrote: > Can somebody from ticketmaster contact me off list? > > These arbitrary blocks are getting ridiculous, and we continue to field a > large number of customer complaints from this. Also not impressed with > front end customer support continuing to lay blame at the service > provider's feet and spread misinformation to end users so they walk away > washing their hands for a situation created by ticketmaster (*Oh, you must > be sharing your IP with everyone else in your area*) > > Secondly, if anybody's had luck actually waking somebody up with some sort > of sway or pull at ticketmaster, shoot me a line off list if you could. I'd > be eternally grateful. Thanks! > -- > Ryan Gard > -- Brent Jones brent at brentrjones.com From job at ntt.net Thu Dec 14 05:45:57 2017 From: job at ntt.net (Job Snijders) Date: Thu, 14 Dec 2017 05:45:57 +0000 Subject: What to do about BGP Hijacks Message-ID: Some carriers view measures to improve routing security as a hinderance rather than as a safeguard to enable business. The BGP protocol itself has no inherent safety mechanisms, so the network operator has to ensure adequate layers of protection are implemented on the boundary between their own network and the Internet. Normalcy bias may play a role, I see carriers target short term gain by heavily relying on the assumption that there will never be any misconfigurations or malicious attacks. Of course yesterday’s incident shows otherwise. For many networks the topic of routing security becomes a priority, only after they've suffered the consequences of an incident. In the long term, the best way to protect against this type of BGP hijacking is to require your connectivity suppliers to implement relevant security measures. Also require full incident reports after BGP hijacks through your provider or IXP have been observed. The moment it becomes socially unacceptable to operate an Internet network without adequate protections in place, there is economic incentive to view routing security efforts as a competitive advantage rather than a nuisance. Consider voting with your wallet, this applies to both IP transit carriers and IXP route server operators. Ask your suppliers what they are doing to prevent BGP hijacks. Ars Technica has a great write-up on the latest BGP hijacking incident: https://arstechnica.com/information-technology/2017/12/suspicious-event-routes-traffic-for-big-name-sites-through-russia/ This MANRS article is on point as well: https://www.manrs.org/2017/12/another-bgp-routing-incident-highlights-an-internet-without-checkpoints/ Kind regards, Job From fgont at si6networks.com Mon Dec 11 15:10:39 2017 From: fgont at si6networks.com (Fernando Gont) Date: Mon, 11 Dec 2017 12:10:39 -0300 Subject: UPnP/IPv6 support in home routers? In-Reply-To: <87899.1512999895@turing-police.cc.vt.edu> References: <87899.1512999895@turing-police.cc.vt.edu> Message-ID: Hello, Valdis, On 12/11/2017 10:44 AM, valdis.kletnieks at vt.edu wrote: > On Mon, 11 Dec 2017 09:23:11 -0300, Fernando Gont said: > >> Anyone can comment on the UPnP support for IPv6 in home routers? >> >> Those that I have checked have UPnP support for IPv4, but not for IPv6 >> -- even when the home router does otherwise support IPv6. > > Well, there's a bit of a problem there. > > Near as I can tell, to get IPv6 support you need to use IGDv2. > > Unfortunately, if you want your Xbox or Playstation to be able > to work, you need to be using IGDv1. Could you elaborate on why IGDv1 is needed? (why things break with IGDv2) > Guess what almost everybody chooses to do? > > (Been there, done that - had to rebuild miniupnpd for OpenWRT/Lede > because it built with v2 by default) I see your point. Now, how are apps that currently rely on punching holes into the NAT or filtering device to work in a v6-only scenario? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From janusz at speedchecker.xyz Thu Dec 14 15:07:51 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 14 Dec 2017 16:07:51 +0100 Subject: Free access to measurement network Message-ID: Hello, Feel free to shoot me down if you think I am posting against the rules of this mailing list but I think it may be helpful for some guys here. We have over 1000 routers deployed across US/Canada in over 700 locations and 130+ networks. Those routers can run network tests such as traceroutes,pings,http tests and can be automated using API. I am happy to give out access to anyone on the list - free of charge (inc. for commercial purposes). We are just interested in seeing what can be built on top of it and have capacity now. Please send me an email off-list if you are interested or want more information Thanks Janusz Jezowicz Speedchecker Ltd From janusz at speedchecker.xyz Thu Dec 14 15:31:29 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 14 Dec 2017 16:31:29 +0100 Subject: Free access to measurement network In-Reply-To: <0CBCF86A-B659-41B4-A814-14A9C996BF62@gmail.com> References: <0CBCF86A-B659-41B4-A814-14A9C996BF62@gmail.com> Message-ID: Thanks James. Sending email off-list Janusz On 14 December 2017 at 16:27, james jones wrote: > I would love access to this. > > Sent from my iPhone > > > On Dec 14, 2017, at 10:07 AM, Janusz Jezowicz > wrote: > > > > Hello, > > > > Feel free to shoot me down if you think I am posting against the rules of > > this mailing list but I think it may be helpful for some guys here. > > > > We have over 1000 routers deployed across US/Canada in over 700 locations > > and 130+ networks. Those routers can run network tests such as > > traceroutes,pings,http tests and can be automated using API. > > > > I am happy to give out access to anyone on the list - free of charge > (inc. > > for commercial purposes). We are just interested in seeing what can be > > built on top of it and have capacity now. > > > > Please send me an email off-list if you are interested or want more > > information > > > > Thanks > > > > Janusz Jezowicz > > Speedchecker Ltd > From ryangard at gmail.com Thu Dec 14 15:37:23 2017 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 14 Dec 2017 10:37:23 -0500 Subject: Amazon Contact Message-ID: Hello, Hoping to chase down a contact off-list for someone who deals with Amazon Instant Video Streaming. Running into an issue with a few blocks being mismarked this morning. Thanks! -- Ryan Gard From morrowc.lists at gmail.com Thu Dec 14 15:52:42 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 14 Dec 2017 10:52:42 -0500 Subject: Free access to measurement network In-Reply-To: References: <0CBCF86A-B659-41B4-A814-14A9C996BF62@gmail.com> Message-ID: this sounds like ripe-atlas... only less nodes? Seems interesting, you should publish an API ... oh you do: http://probeapi.speedchecker.xyz/ you might consider donating your data to the measurement-lab.org people ... eh? I wonder if/how the QOE tests could inform things like the FTC's efforts at measuring across ATT/partner boundaries during their period post-directtv-merger? On Thu, Dec 14, 2017 at 10:31 AM, Janusz Jezowicz wrote: > Thanks James. Sending email off-list > > Janusz > > > On 14 December 2017 at 16:27, james jones wrote: > > > I would love access to this. > > > > Sent from my iPhone > > > > > On Dec 14, 2017, at 10:07 AM, Janusz Jezowicz > > > wrote: > > > > > > Hello, > > > > > > Feel free to shoot me down if you think I am posting against the rules > of > > > this mailing list but I think it may be helpful for some guys here. > > > > > > We have over 1000 routers deployed across US/Canada in over 700 > locations > > > and 130+ networks. Those routers can run network tests such as > > > traceroutes,pings,http tests and can be automated using API. > > > > > > I am happy to give out access to anyone on the list - free of charge > > (inc. > > > for commercial purposes). We are just interested in seeing what can be > > > built on top of it and have capacity now. > > > > > > Please send me an email off-list if you are interested or want more > > > information > > > > > > Thanks > > > > > > Janusz Jezowicz > > > Speedchecker Ltd > > > From amitchell at isipp.com Thu Dec 14 16:58:23 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Thu, 14 Dec 2017 09:58:23 -0700 Subject: Amazon Contact In-Reply-To: References: Message-ID: <3E6166B4-BDF3-4AB9-8123-F246DBD05F33@isipp.com> > Hoping to chase down a contact off-list for someone who deals with Amazon > Instant Video Streaming. Running into an issue with a few blocks being > mismarked this morning. Ryan, please ping me offlist, we may be able to assist. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From janusz at speedchecker.xyz Thu Dec 14 19:14:54 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 14 Dec 2017 20:14:54 +0100 Subject: Free access to measurement network In-Reply-To: References: <0CBCF86A-B659-41B4-A814-14A9C996BF62@gmail.com> Message-ID: Thanks for your feedback. Yes, its similar to RIPE Atlas. Our goal is to have more nodes over time. We only just started and have over 2000 nodes worldwide, since DD-WRT users contributing routers we don't need to pay/ship hardware and should have better coverage over time. Of course the routers are not as powerful as RIPE probes and not extensible so there are limitations to what we can do. Regarding contributing data, the data is private to whoever has been running the measurements so it would be tricky unless we get consent from everyone. Regarding ATT QOE, happy to chat more off-list if you have ideas how we could help Regards, Janusz On 14 December 2017 at 16:52, Christopher Morrow wrote: > this sounds like ripe-atlas... only less nodes? > Seems interesting, you should publish an API ... oh you do: > http://probeapi.speedchecker.xyz/ > > you might consider donating your data to the measurement-lab.org people > ... eh? > I wonder if/how the QOE tests could inform things like the FTC's efforts > at measuring across ATT/partner boundaries during their period > post-directtv-merger? > > On Thu, Dec 14, 2017 at 10:31 AM, Janusz Jezowicz > wrote: > >> Thanks James. Sending email off-list >> >> Janusz >> >> >> On 14 December 2017 at 16:27, james jones wrote: >> >> > I would love access to this. >> > >> > Sent from my iPhone >> > >> > > On Dec 14, 2017, at 10:07 AM, Janusz Jezowicz < >> janusz at speedchecker.xyz> >> > wrote: >> > > >> > > Hello, >> > > >> > > Feel free to shoot me down if you think I am posting against the >> rules of >> > > this mailing list but I think it may be helpful for some guys here. >> > > >> > > We have over 1000 routers deployed across US/Canada in over 700 >> locations >> > > and 130+ networks. Those routers can run network tests such as >> > > traceroutes,pings,http tests and can be automated using API. >> > > >> > > I am happy to give out access to anyone on the list - free of charge >> > (inc. >> > > for commercial purposes). We are just interested in seeing what can be >> > > built on top of it and have capacity now. >> > > >> > > Please send me an email off-list if you are interested or want more >> > > information >> > > >> > > Thanks >> > > >> > > Janusz Jezowicz >> > > Speedchecker Ltd >> > >> > > From james.voip at gmail.com Thu Dec 14 15:27:06 2017 From: james.voip at gmail.com (james jones) Date: Thu, 14 Dec 2017 10:27:06 -0500 Subject: Free access to measurement network In-Reply-To: References: Message-ID: <0CBCF86A-B659-41B4-A814-14A9C996BF62@gmail.com> I would love access to this. Sent from my iPhone > On Dec 14, 2017, at 10:07 AM, Janusz Jezowicz wrote: > > Hello, > > Feel free to shoot me down if you think I am posting against the rules of > this mailing list but I think it may be helpful for some guys here. > > We have over 1000 routers deployed across US/Canada in over 700 locations > and 130+ networks. Those routers can run network tests such as > traceroutes,pings,http tests and can be automated using API. > > I am happy to give out access to anyone on the list - free of charge (inc. > for commercial purposes). We are just interested in seeing what can be > built on top of it and have capacity now. > > Please send me an email off-list if you are interested or want more > information > > Thanks > > Janusz Jezowicz > Speedchecker Ltd From nanog at authcom.com Tue Dec 12 16:57:51 2017 From: nanog at authcom.com (TimJ) Date: Tue, 12 Dec 2017 12:57:51 -0400 Subject: IPv4 /24 Broker or no broker Message-ID: <2789ee496ab5eec97bd3027d330b92bd@glinx.com> Just looking for info. I know there are a lot of brokers, but is that a good (easy and quick) way to sell a /24 ? We're renumbering and plan to free up a /24. My boss is asking how much we could roughly expect to get for it, and the fastest/easiest way to 'sell' the block. It's a single /24, in the ARIN region (not part of a larger allocation). Suggestions? Tim From pascalmasha at gmail.com Wed Dec 13 10:25:59 2017 From: pascalmasha at gmail.com (Pascal Masha) Date: Wed, 13 Dec 2017 10:25:59 +0000 Subject: Switch/Router In-Reply-To: References: <006a01d37358$1bfc6b40$53f541c0$@ca> Message-ID: Hi, Perhaps you could also checkout the HP A5800-24G-SFP, it's an SFP type switch pretty good, the only downside, however, is that it has a weird limitation on the number of received BGP routes - but with some tweaking you can hack it. They can also do a cluster setup through an IRF port, has a expansion slot for an extra 6x10gig module. This link https://www.cnet.com/products/hp-a5800-48g-switch-switch-48-ports-managed-series/specs/ shows another related model, the only difference is that it has electrical gig ports. Regards, Paschal Masha. On Wed, Dec 13, 2017 at 1:11 AM, Baldur Norddahl wrote: > The ZTE 5928 has 24x 1G and 4x 10G. It has dual PSU with options for both > AC and DC power. It will do BGP, MPLS etc with about 30.000 routes. Price > is approximately 2k USD. > > If you need more 10G ports there is the ZTE 5960 with 24x 10G plus 2x 40G > at approximately twice the price. > > Also take a peek at the switches at fs.com. > > > Den 12. dec. 2017 15.48 skrev "K MEKKAOUI" : > > Hi > > > > I am looking for a router preferably (or switch) with the following specs: > > 1- Carrier grade > > 2- Dual power supply > > 3- 1RU > > 4- Gig and 10Gig interfaces. > > 5- Does support protocols like BGP, etc. > > > > Any recommendation please? Your help will be appreciated. > > > > Thank you > > > > KARIM M. > > MEKTEL INC. > > Tél. : 1(855) 563-5835 poste 404 > > www.mektel.ca From romel.jacinto at gmail.com Wed Dec 13 19:00:23 2017 From: romel.jacinto at gmail.com (Romel Jacinto) Date: Wed, 13 Dec 2017 11:00:23 -0800 Subject: Earthlink contact? PTR record issue Message-ID: Does anyone have a contact at Earthlink? Earthlink is blocking an email server because of a PTR record issue. However all our testing shows that reverse DNS is setup correctly. Thank you. -- Romel Jacinto From tanaka at netcombb.co.jp Wed Dec 13 00:46:02 2017 From: tanaka at netcombb.co.jp (Jun Tanaka) Date: Wed, 13 Dec 2017 09:46:02 +0900 Subject: Switch/Router In-Reply-To: <006a01d37358$1bfc6b40$53f541c0$@ca> References: <006a01d37358$1bfc6b40$53f541c0$@ca> Message-ID: <20171213094601.503E.99F48BED@netcombb.co.jp> Hi Karim, How about Extream's (formerly Brocade,Foundry) CER2000-RT ? --- Jun Tanaka - NetComBB/S.N.I [amekkaoui at mektel.ca - Tue, 12 Dec 2017 09:47:17 -0500]: > Hi > > > > I am looking for a router preferably (or switch) with the following specs: > > 1- Carrier grade > > 2- Dual power supply > > 3- 1RU > > 4- Gig and 10Gig interfaces. > > 5- Does support protocols like BGP, etc. > > > > Any recommendation please? Your help will be appreciated. > > > > Thank you > > > > KARIM M. > > MEKTEL INC. > > Tel. : 1(855) 563-5835 poste 404 > > www.mektel.ca > > From samcarman at samualcarman.com Wed Dec 13 15:20:43 2017 From: samcarman at samualcarman.com (samual carman) Date: Wed, 13 Dec 2017 07:20:43 -0800 Subject: Charter CPE engineer Message-ID: <47F5ED4D-8DC2-4B7B-99C4-BEFA40DB3C9F@samualcarman.com> Are there any charter CPE engineering team members on here? Preferably someone who deals with modems and firmware for the modems There an issue I have been noticing on multiple modems(same model) and my attempt to reach local engineering team members have not been met with success Sam Mettai Inc Sent from my iPhone From aaron1 at gvtc.com Thu Dec 14 23:15:01 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 14 Dec 2017 17:15:01 -0600 Subject: IPv4 /24 Broker or no broker In-Reply-To: <2789ee496ab5eec97bd3027d330b92bd@glinx.com> References: <2789ee496ab5eec97bd3027d330b92bd@glinx.com> Message-ID: <000001d37531$5e59ff40$1b0dfdc0$@gvtc.com> Looks like /24 is going for ~$4k .... $16 per ip Dang, perhaps it will go up like bitcoin, lol, we wish. Actually, I was seeing ip's for $10 each about 8 months ago... so it is going up in value if that auction site is a good measure of real value. https://www.ipv4auctions.com/ -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of TimJ Sent: Tuesday, December 12, 2017 10:58 AM To: nanog at nanog.org Subject: IPv4 /24 Broker or no broker Just looking for info. I know there are a lot of brokers, but is that a good (easy and quick) way to sell a /24 ? We're renumbering and plan to free up a /24. My boss is asking how much we could roughly expect to get for it, and the fastest/easiest way to 'sell' the block. It's a single /24, in the ARIN region (not part of a larger allocation). Suggestions? Tim From valdis.kletnieks at vt.edu Fri Dec 15 01:51:59 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 14 Dec 2017 20:51:59 -0500 Subject: UPnP/IPv6 support in home routers? In-Reply-To: References: <87899.1512999895@turing-police.cc.vt.edu> Message-ID: <36920.1513302719@turing-police.cc.vt.edu> On Mon, 11 Dec 2017 12:10:39 -0300, Fernando Gont said: > On 12/11/2017 10:44 AM, valdis.kletnieks at vt.edu wrote: > > Unfortunately, if you want your Xbox or Playstation to be able > > to work, you need to be using IGDv1. > > Could you elaborate on why IGDv1 is needed? (why things break with IGDv2) Because my Playstation 3 and Playstation 4 both speak IDGv1, and when they talk to an IGDv2-capable miniupnpd on Openwrt/Lede, it Just Doesn't Work, and will continue to do so until Sony ships a software update to make it work with both v1 and v2. It's possible that miniupnp simply botched backward combatability - I didn't debug further. Googling for 'miniupnp idgv2' seems to indicate that nobody else has debugged/fixed the issue either. https://forum.lede-project.org/t/miniupnp-with-igd2-not-compatible-with-consoles/2016 (More recent Lede builds changed back to IDGv1 by default for this exact reason). Interesting fact: My PS/4 will dhcpv6 and assign itself an address and answers ping6 even from outside my home network (so it has a default route), but doesn't seem to do anything else with IPv6 (for instance, the assigned address isn't listed under 'view connection status', nor does nmap find any open ports, though it hits 2 open http ports on IPv4). > I see your point. Now, how are apps that currently rely on punching > holes into the NAT or filtering device to work in a v6-only scenario? I wonder if doing IDGv2 on IPv6 and IDGv1 on IPV4 is a viable solution.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at radu-adrian.feurdean.net Fri Dec 15 11:29:37 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 15 Dec 2017 12:29:37 +0100 Subject: Static Routing 172.16.0.0/32 In-Reply-To: References: Message-ID: <1513337377.2838732.1206042200.51BEF9C1@webmail.messagingengine.com> On Fri, Dec 8, 2017, at 21:02, Job Snijders wrote: > Nothing wrong with using xxx.0 or xxx::0 in the context of a host route > (/32 or /128). https://labs-pre.ripe.net/Members/stephane_bortzmeyer/all-ip-addresses-are-equal-dot-zero-addresses-are-less-equal For a host route, no problem. For the host itself - a slightly different story. From dovid at telecurve.com Fri Dec 15 12:47:42 2017 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 15 Dec 2017 07:47:42 -0500 Subject: Free access to measurement network In-Reply-To: References: Message-ID: What kind of internet are these devices on? With Net Neutrality gone here in the US it would be a good way to measure certain services such as SIP to see which ISP's if any are tampering with packets. On Thu, Dec 14, 2017 at 10:07 AM, Janusz Jezowicz wrote: > Hello, > > Feel free to shoot me down if you think I am posting against the rules of > this mailing list but I think it may be helpful for some guys here. > > We have over 1000 routers deployed across US/Canada in over 700 locations > and 130+ networks. Those routers can run network tests such as > traceroutes,pings,http tests and can be automated using API. > > I am happy to give out access to anyone on the list - free of charge (inc. > for commercial purposes). We are just interested in seeing what can be > built on top of it and have capacity now. > > Please send me an email off-list if you are interested or want more > information > > Thanks > > Janusz Jezowicz > Speedchecker Ltd > From janusz at speedchecker.xyz Fri Dec 15 13:23:39 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Fri, 15 Dec 2017 14:23:39 +0100 Subject: Free access to measurement network In-Reply-To: References: Message-ID: Since these are mostly end-user routers they are on regular ISPs (like Comcast, Verizon etc). I believe this could be quite suitable for monitoring net neutrality. Feel free to ping me off-list if you would like to explore it more. Regards, Janusz On 15 December 2017 at 13:47, Dovid Bender wrote: > What kind of internet are these devices on? With Net Neutrality gone here > in the US it would be a good way to measure certain services such as SIP to > see which ISP's if any are tampering with packets. > > > > On Thu, Dec 14, 2017 at 10:07 AM, Janusz Jezowicz > wrote: > >> Hello, >> >> Feel free to shoot me down if you think I am posting against the rules of >> this mailing list but I think it may be helpful for some guys here. >> >> We have over 1000 routers deployed across US/Canada in over 700 locations >> and 130+ networks. Those routers can run network tests such as >> traceroutes,pings,http tests and can be automated using API. >> >> I am happy to give out access to anyone on the list - free of charge (inc. >> for commercial purposes). We are just interested in seeing what can be >> built on top of it and have capacity now. >> >> Please send me an email off-list if you are interested or want more >> information >> >> Thanks >> >> Janusz Jezowicz >> Speedchecker Ltd >> > > From mel at beckman.org Fri Dec 15 14:21:53 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 15 Dec 2017 14:21:53 +0000 Subject: Free access to measurement network In-Reply-To: References: , Message-ID: <09FA83C2-C801-467C-8FB7-B88F9B4C2FD3@beckman.org> Are these your customer-owned routers? -mel beckman > On Dec 15, 2017, at 5:24 AM, Janusz Jezowicz wrote: > > Since these are mostly end-user routers they are on regular ISPs (like > Comcast, Verizon etc). I believe this could be quite suitable for > monitoring net neutrality. Feel free to ping me off-list if you would like > to explore it more. > > Regards, > > Janusz > >> On 15 December 2017 at 13:47, Dovid Bender wrote: >> >> What kind of internet are these devices on? With Net Neutrality gone here >> in the US it would be a good way to measure certain services such as SIP to >> see which ISP's if any are tampering with packets. >> >> >> >> On Thu, Dec 14, 2017 at 10:07 AM, Janusz Jezowicz >> wrote: >> >>> Hello, >>> >>> Feel free to shoot me down if you think I am posting against the rules of >>> this mailing list but I think it may be helpful for some guys here. >>> >>> We have over 1000 routers deployed across US/Canada in over 700 locations >>> and 130+ networks. Those routers can run network tests such as >>> traceroutes,pings,http tests and can be automated using API. >>> >>> I am happy to give out access to anyone on the list - free of charge (inc. >>> for commercial purposes). We are just interested in seeing what can be >>> built on top of it and have capacity now. >>> >>> Please send me an email off-list if you are interested or want more >>> information >>> >>> Thanks >>> >>> Janusz Jezowicz >>> Speedchecker Ltd >> >> From valdis.kletnieks at vt.edu Fri Dec 15 17:40:34 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 15 Dec 2017 12:40:34 -0500 Subject: Free access to measurement network In-Reply-To: References: Message-ID: <127166.1513359634@turing-police.cc.vt.edu> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: > What kind of internet are these devices on? With Net Neutrality gone here > in the US it would be a good way to measure certain services such as SIP to > see which ISP's if any are tampering with packets. Given previous history, the answer will probably be "most of them". "The results are not inspiring. More than 129 million people are limited to a single provider for broadband Internet access using the FCC definition of 25 Mbps download and 3 Mbps upload. Out of those 129 million Americans, about 52 million must obtain Internet access from a company that has violated network neutrality protections in the past and continues to undermine the policy today. In locations where subscribers have the benefit of limited competition, the situation isn't much better. Among the 146 million Americans with the ability to choose between two providers, 48 million Americans must choose between two companies that have a record of violating network neutrality." https://muninetworks.org/content/177-million-americans-harmed-net-neutrality -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From cscora at apnic.net Fri Dec 15 18:03:03 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Dec 2017 04:03:03 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171215180303.4A1A7C509@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Dec, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 676159 Prefixes after maximum aggregation (per Origin AS): 262688 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 326764 Total ASes present in the Internet Routing Table: 59345 Prefixes per ASN: 11.39 Origin-only ASes present in the Internet Routing Table: 51252 Origin ASes announcing only one prefix: 22555 Transit ASes present in the Internet Routing Table: 8093 Transit-only ASes present in the Internet Routing Table: 247 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 30 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 91 Number of instances of unregistered ASNs: 91 Number of 32-bit ASNs allocated by the RIRs: 20920 Number of 32-bit ASNs visible in the Routing Table: 16742 Prefixes from 32-bit ASNs in the Routing Table: 68962 Number of bogon 32-bit ASNs visible in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 337 Number of addresses announced to Internet: 2862933666 Equivalent to 170 /8s, 164 /16s and 230 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 223719 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 186197 Total APNIC prefixes after maximum aggregation: 53271 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 185348 Unique aggregates announced from the APNIC address blocks: 77122 APNIC Region origin ASes present in the Internet Routing Table: 8531 APNIC Prefixes per ASN: 21.73 APNIC Region origin ASes announcing only one prefix: 2393 APNIC Region transit ASes present in the Internet Routing Table: 1241 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3407 Number of APNIC addresses announced to Internet: 768617250 Equivalent to 45 /8s, 208 /16s and 43 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202148 Total ARIN prefixes after maximum aggregation: 97202 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203461 Unique aggregates announced from the ARIN address blocks: 95201 ARIN Region origin ASes present in the Internet Routing Table: 18038 ARIN Prefixes per ASN: 11.28 ARIN Region origin ASes announcing only one prefix: 6676 ARIN Region transit ASes present in the Internet Routing Table: 1779 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2278 Number of ARIN addresses announced to Internet: 1112144416 Equivalent to 66 /8s, 73 /16s and 250 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 182309 Total RIPE prefixes after maximum aggregation: 88877 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 178242 Unique aggregates announced from the RIPE address blocks: 107405 RIPE Region origin ASes present in the Internet Routing Table: 24734 RIPE Prefixes per ASN: 7.21 RIPE Region origin ASes announcing only one prefix: 11311 RIPE Region transit ASes present in the Internet Routing Table: 3509 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6493 Number of RIPE addresses announced to Internet: 713990528 Equivalent to 42 /8s, 142 /16s and 161 /24s 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, 64396-64495 196608-207259 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: 87494 Total LACNIC prefixes after maximum aggregation: 19347 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 88757 Unique aggregates announced from the LACNIC address blocks: 39572 LACNIC Region origin ASes present in the Internet Routing Table: 6657 LACNIC Prefixes per ASN: 13.33 LACNIC Region origin ASes announcing only one prefix: 1810 LACNIC Region transit ASes present in the Internet Routing Table: 1231 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4183 Number of LACNIC addresses announced to Internet: 172655072 Equivalent to 10 /8s, 74 /16s and 129 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17918 Total AfriNIC prefixes after maximum aggregation: 3921 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 20014 Unique aggregates announced from the AfriNIC address blocks: 7188 AfriNIC Region origin ASes present in the Internet Routing Table: 1110 AfriNIC Prefixes per ASN: 18.03 AfriNIC Region origin ASes announcing only one prefix: 364 AfriNIC Region transit ASes present in the Internet Routing Table: 221 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 381 Number of AfriNIC addresses announced to Internet: 95105280 Equivalent to 5 /8s, 171 /16s and 49 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5422 4194 86 ERX-CERNET-BKB China Education and Rese 7545 4050 409 403 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2802 11129 760 KIXS-AS-KR Korea Telecom, KR 17974 2780 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2767 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2522 1530 155 VNPT-AS-VN VNPT Corp, VN 7552 2340 1158 56 VIETEL-AS-AP Viettel Group, VN 9394 2169 4931 27 CTTNET China TieTong Telecommunications 9808 2101 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2085 421 212 TATACOMM-AS TATA Communications formerl 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 6327 3347 1323 86 SHAW - Shaw Communications Inc., CA 22773 3304 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2169 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2060 2299 467 CHARTER-NET-HKY-NC - Charter Communicat 6389 1960 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 16509 1954 4077 581 AMAZON-02 - Amazon.com, Inc., US 209 1935 5062 645 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1863 331 249 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1706 235 576 CABLEONE - CABLE ONE, INC., US 7018 1689 20578 1063 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3519 186 23 ALJAWWALSTC-AS, SA 20940 2855 848 2060 AKAMAI-ASN1, US 8551 2482 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2065 331 445 TELLCOM-AS, TR 12389 2060 1801 679 ROSTELECOM-AS, RU 12479 1962 1068 127 UNI2-AS, ES 9121 1880 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1215 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 3647 3467 599 Uninet S.A. de C.V., MX 10620 3586 542 245 Telmex Colombia S.A., CO 11830 2628 370 66 Instituto Costarricense de Electricidad 6503 1617 437 53 Axtel, S.A.B. de C.V., MX 7303 1498 1022 194 Telecom Argentina S.A., AR 6147 1219 377 27 Telefonica del Peru S.A.A., PE 28573 1017 2259 190 CLARO S.A., BR 3816 1014 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 918 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1199 398 48 LINKdotNET-AS, EG 37611 777 91 8 Afrihost, ZA 36903 737 370 135 MT-MPLS, MA 36992 678 1383 31 ETISALAT-MISR, EG 8452 533 1730 18 TE-AS TE-AS, EG 24835 517 850 15 RAYA-AS, EG 29571 443 36 13 CITelecom-AS, CI 37492 435 367 77 ORANGE-, TN 15399 349 35 7 WANANCHI-, KE 37342 343 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5422 4194 86 ERX-CERNET-BKB China Education and Rese 7545 4050 409 403 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 3647 3467 599 Uninet S.A. de C.V., MX 10620 3586 542 245 Telmex Colombia S.A., CO 39891 3519 186 23 ALJAWWALSTC-AS, SA 6327 3347 1323 86 SHAW - Shaw Communications Inc., CA 22773 3304 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2855 848 2060 AKAMAI-ASN1, US 4766 2802 11129 760 KIXS-AS-KR Korea Telecom, KR 17974 2780 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4050 3647 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3519 3496 ALJAWWALSTC-AS, SA 10620 3586 3341 Telmex Colombia S.A., CO 6327 3347 3261 SHAW - Shaw Communications Inc., CA 22773 3304 3158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3647 3048 Uninet S.A. de C.V., MX 17974 2780 2703 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2628 2562 Instituto Costarricense de Electricidad y Telec 8551 2482 2440 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 45899 2522 2367 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64710 PRIVATE 39.134.26.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.28.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.30.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.31.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.20.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.22.0/24 56042 CMNET-SHANXI-AP China Mobile c 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:286 /13:561 /14:1088 /15:1895 /16:13387 /17:7796 /18:13669 /19:25275 /20:39006 /21:44020 /22:82375 /23:67242 /24:377177 /25:827 /26:602 /27:645 /28:36 /29:21 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3139 3347 SHAW - Shaw Communications Inc., CA 39891 2946 3519 ALJAWWALSTC-AS, SA 22773 2549 3304 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2063 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 1974 2628 Instituto Costarricense de Electricidad y Telec 8551 1946 2482 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1630 1863 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1574 3586 Telmex Colombia S.A., CO 11492 1506 1706 CABLEONE - CABLE ONE, INC., US 34984 1382 2065 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1571 2:824 4:18 5:2625 6:39 8:1090 9:1 12:1856 13:183 14:1750 15:29 16:3 17:185 18:76 20:54 21:12 23:2475 24:1928 25:2 27:2355 31:1970 32:87 35:22 36:452 37:2467 38:1451 39:164 40:101 41:3041 42:526 43:1948 44:88 45:3406 46:2869 47:191 49:1376 50:1042 51:47 52:915 54:354 55:5 56:7 57:43 58:1577 59:1005 60:366 61:1997 62:1765 63:1831 64:4624 65:2243 66:4490 67:2304 68:1189 69:3165 70:1133 71:586 72:2096 74:2686 75:391 76:422 77:1549 78:1570 79:1910 80:1453 81:1421 82:1066 83:754 84:1007 85:1938 86:484 87:1207 88:901 89:2317 90:174 91:6257 92:1025 93:2355 94:2431 95:2713 96:669 97:354 98:963 99:107 100:153 101:1526 102:9 103:16432 104:3201 105:211 106:516 107:1787 108:820 109:2898 110:1508 111:1729 112:1284 113:1376 114:1089 115:1607 116:1702 117:1638 118:2194 119:1651 120:909 121:1052 122:2404 123:1869 124:1482 125:1827 128:961 129:579 130:442 131:1642 132:593 133:193 134:989 135:229 136:443 137:454 138:1980 139:556 140:388 141:680 142:769 143:929 144:790 145:192 146:1148 147:682 148:1490 149:633 150:716 151:1002 152:747 153:303 154:972 155:744 156:741 157:738 158:602 159:1640 160:851 161:732 162:2542 163:530 164:954 165:1481 166:395 167:1345 168:3119 169:795 170:3632 171:402 172:1017 173:1900 174:841 175:771 176:1892 177:3999 178:2496 179:1154 180:2241 181:2129 182:2420 183:1026 184:889 185:11802 186:3447 187:2323 188:2618 189:1938 190:8209 191:1364 192:9721 193:5857 194:4752 195:3980 196:2296 197:1423 198:5547 199:5881 200:7175 201:4892 202:10425 203:9960 204:4557 205:2863 206:3059 207:3089 208:3987 209:3935 210:3982 211:2146 212:2892 213:2598 214:863 215:65 216:5725 217:2102 218:918 219:631 220:1693 221:977 222:737 223:1211 End of report From nanog at ics-il.net Sat Dec 16 02:57:15 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Dec 2017 20:57:15 -0600 (CST) Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: Message-ID: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> Bump for Hulu. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Michael Crapse" To: nanog at nanog.org Sent: Wednesday, December 6, 2017 3:38:20 PM Subject: Geolocation: IPv4 Subnet blocked by HULU, and others I am a local WISP. And my customers have trouble reaching Hulu, Disney now, and previously netflix and amazon prime(both resolved). I have emailed, mailed, and called both HULU and Disney now to get my 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) from their services. They have replied saying it takes 3-5 days to resolve the issue, that was several weeks ago. Can i get contact from those two services that can help my customers reach their services, thank you. Thank you for the help. -Michael From maxtul at netassist.ua Sat Dec 16 10:43:54 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Sat, 16 Dec 2017 12:43:54 +0200 Subject: Free access to measurement network In-Reply-To: <127166.1513359634@turing-police.cc.vt.edu> References: <127166.1513359634@turing-police.cc.vt.edu> Message-ID: <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone here >> in the US it would be a good way to measure certain services such as SIP to >> see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are limited to a > single provider for broadband Internet access using the FCC definition of 25 > Mbps download and 3 Mbps upload. Out of those 129 million Americans, about 52 > million must obtain Internet access from a company that has violated network > neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited competition, the > situation isn't much better. Among the 146 million Americans with the ability > to choose between two providers, 48 million Americans must choose between two > companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neutrality > From nanog at ics-il.net Sat Dec 16 15:22:47 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 Dec 2017 09:22:47 -0600 (CST) Subject: Free access to measurement network In-Reply-To: <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> Message-ID: <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Saturday, December 16, 2017 4:43:54 AM Subject: Re: Free access to measurement network So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone here >> in the US it would be a good way to measure certain services such as SIP to >> see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are limited to a > single provider for broadband Internet access using the FCC definition of 25 > Mbps download and 3 Mbps upload. Out of those 129 million Americans, about 52 > million must obtain Internet access from a company that has violated network > neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited competition, the > situation isn't much better. Among the 146 million Americans with the ability > to choose between two providers, 48 million Americans must choose between two > companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neutrality > From drc at virtualized.org Sat Dec 16 15:58:19 2017 From: drc at virtualized.org (David Conrad) Date: Sat, 16 Dec 2017 16:58:19 +0100 Subject: Free access to measurement network In-Reply-To: <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> Message-ID: <9946e89e-7989-436d-82b1-cd44519a36ca@Spark> Mike, On Dec 16, 2017, 4:23 PM +0100, Mike Hammett , wrote: > It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don’t. The report Valdis quoted said "More than 129 million people are limited to a single provider for broadband Internet access using the FCC definition of 25 Mbps download and 3 Mbps upload.” This suggests that consumers don’t have the option of supporting alternatives with their wallets. Regards, -drc From maxsec at gmail.com Sat Dec 16 16:02:01 2017 From: maxsec at gmail.com (Martin Hepworth) Date: Sat, 16 Dec 2017 16:02:01 +0000 Subject: Free access to measurement network In-Reply-To: References: Message-ID: You been in contact with the guys at Samknows.com ? On Thu, 14 Dec 2017 at 15:09, Janusz Jezowicz wrote: > Hello, > > Feel free to shoot me down if you think I am posting against the rules of > this mailing list but I think it may be helpful for some guys here. > > We have over 1000 routers deployed across US/Canada in over 700 locations > and 130+ networks. Those routers can run network tests such as > traceroutes,pings,http tests and can be automated using API. > > I am happy to give out access to anyone on the list - free of charge (inc. > for commercial purposes). We are just interested in seeing what can be > built on top of it and have capacity now. > > Please send me an email off-list if you are interested or want more > information > > Thanks > > Janusz Jezowicz > Speedchecker Ltd > -- -- Martin Hepworth, CISSP Oxford, UK From nanog at ics-il.net Sat Dec 16 17:17:33 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 Dec 2017 11:17:33 -0600 (CST) Subject: Free access to measurement network In-Reply-To: <9946e89e-7989-436d-82b1-cd44519a36ca@Spark> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <9946e89e-7989-436d-82b1-cd44519a36ca@Spark> Message-ID: <998403447.3029.1513444649298.JavaMail.mhammett@ThunderFuck> I know what the report says and I'll stand by my statement. The consumers have voted for that with their wallets. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "David Conrad" To: nanog at nanog.org Sent: Saturday, December 16, 2017 9:58:19 AM Subject: Re: Free access to measurement network Mike, On Dec 16, 2017, 4:23 PM +0100, Mike Hammett , wrote: > It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don’t. The report Valdis quoted said "More than 129 million people are limited to a single provider for broadband Internet access using the FCC definition of 25 Mbps download and 3 Mbps upload.” This suggests that consumers don’t have the option of supporting alternatives with their wallets. Regards, -drc From ler762 at gmail.com Sat Dec 16 20:16:38 2017 From: ler762 at gmail.com (Lee) Date: Sat, 16 Dec 2017 15:16:38 -0500 Subject: Free access to measurement network In-Reply-To: <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> Message-ID: On 12/16/17, Mike Hammett wrote: > It's a consumer thing. If consumers wanted more options, they would be > supporting those options with their wallets. They don't. As far as I know, my options for >50Mb/s are comcast and verizon. https://www.broadbandmap.gov/ sez Please note: National Broadband Map data is from June 30, 2014 and is no longer being updated. How do I find out what my other options are? Thanks, Lee > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Saturday, December 16, 2017 4:43:54 AM > Subject: Re: Free access to measurement network > > So for my point of view, better solution is to push some law that ease > access to the buildings for ISPs. > > 15.12.17 19:40, valdis.kletnieks at vt.edu пише: >> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >>> What kind of internet are these devices on? With Net Neutrality gone here >>> >>> in the US it would be a good way to measure certain services such as SIP >>> to >>> see which ISP's if any are tampering with packets. >> >> Given previous history, the answer will probably be "most of them". >> >> "The results are not inspiring. More than 129 million people are limited >> to a >> single provider for broadband Internet access using the FCC definition of >> 25 >> Mbps download and 3 Mbps upload. Out of those 129 million Americans, about >> 52 >> million must obtain Internet access from a company that has violated >> network >> neutrality protections in the past and continues to undermine the policy >> today. >> >> In locations where subscribers have the benefit of limited competition, >> the >> situation isn't much better. Among the 146 million Americans with the >> ability >> to choose between two providers, 48 million Americans must choose between >> two >> companies that have a record of violating network neutrality." >> >> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality >> >> > > From nanog at ics-il.net Sat Dec 16 20:43:09 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 Dec 2017 14:43:09 -0600 (CST) Subject: Free access to measurement network In-Reply-To: References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> Message-ID: <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> That project was paid for by ARRA funds and ran out. The FCC picked up the ball by expanding the scope of its 477 program. That data is available directly on their site or via some sites like broadbandnow.com There are also many service providers available that aren't filing because either A) they don't know about it or B) government stuff. My point was that consumers voted out thousands of independents by taking service from incumbents instead of independents. Thousands have closed up shop. Where independents are available, it's still tough getting customers if the incumbents have a service that mostly works (over say 5 to 10 megs), even if the independent offers service comparable to the incumbent's advertisements. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Lee" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, December 16, 2017 2:16:38 PM Subject: Re: Free access to measurement network On 12/16/17, Mike Hammett wrote: > It's a consumer thing. If consumers wanted more options, they would be > supporting those options with their wallets. They don't. As far as I know, my options for >50Mb/s are comcast and verizon. https://www.broadbandmap.gov/ sez Please note: National Broadband Map data is from June 30, 2014 and is no longer being updated. How do I find out what my other options are? Thanks, Lee > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Saturday, December 16, 2017 4:43:54 AM > Subject: Re: Free access to measurement network > > So for my point of view, better solution is to push some law that ease > access to the buildings for ISPs. > > 15.12.17 19:40, valdis.kletnieks at vt.edu пише: >> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >>> What kind of internet are these devices on? With Net Neutrality gone here >>> >>> in the US it would be a good way to measure certain services such as SIP >>> to >>> see which ISP's if any are tampering with packets. >> >> Given previous history, the answer will probably be "most of them". >> >> "The results are not inspiring. More than 129 million people are limited >> to a >> single provider for broadband Internet access using the FCC definition of >> 25 >> Mbps download and 3 Mbps upload. Out of those 129 million Americans, about >> 52 >> million must obtain Internet access from a company that has violated >> network >> neutrality protections in the past and continues to undermine the policy >> today. >> >> In locations where subscribers have the benefit of limited competition, >> the >> situation isn't much better. Among the 146 million Americans with the >> ability >> to choose between two providers, 48 million Americans must choose between >> two >> companies that have a record of violating network neutrality." >> >> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality >> >> > > From josmon at rigozsaurus.com Sat Dec 16 23:19:22 2017 From: josmon at rigozsaurus.com (John Osmon) Date: Sat, 16 Dec 2017 16:19:22 -0700 Subject: Free access to measurement network In-Reply-To: <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> Message-ID: <20171216231922.GA7648@jeeves.rigozsaurus.com> > My point was that consumers voted out thousands of independents by > taking service from incumbents instead of independents. Thousands have > closed up shop. Where independents are available, it's still tough > getting customers if the incumbents have a service that mostly works > (over say 5 to 10 megs), even if the independent offers service > comparable to the incumbent's advertisements. In my neck of the woods, most independents only sold layer 3 services. and depended upon others for layer 2 services. The independents had a booming business with those conditions and consumers had an array of choices for ISPs. Then, the layer 2 operators started offering combined layer 2/3 services at a price point below the layer 2 only price needed to get to the independents. Unsurprisingly, the consumers flocked to the cheaper services. I've always felt if a company used a public right of way to reach a consumer, they should be prohibited from being a layer 3 provider. Or, at a minimum, they need to sell layer 2 services to themselves at the same price they charge others. I've known lots of people that would be happy to compete with the big boys under those circumstances. From ler762 at gmail.com Sun Dec 17 19:46:19 2017 From: ler762 at gmail.com (Lee) Date: Sun, 17 Dec 2017 14:46:19 -0500 Subject: Free access to measurement network In-Reply-To: <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> Message-ID: On 12/16/17, Mike Hammett wrote: > That project was paid for by ARRA funds and ran out. > > The FCC picked up the ball by expanding the scope of its 477 program. That > data is available directly on their site or via some sites like > broadbandnow.com I didn't know about that - thanks. But it just confirms what I thought; my choices are comcast & verizon. There is another possibility, but $350/mo for 10Mb/s with a 24 month contract is too steep. > There are also many service providers available that aren't filing because > either A) they don't know about it or B) government stuff. > > My point was that consumers voted out thousands of independents by taking > service from incumbents instead of independents. Thousands have closed up > shop. Where independents are available, it's still tough getting customers > if the incumbents have a service that mostly works (over say 5 to 10 megs), > even if the independent offers service comparable to the incumbent's > advertisements. As a consumer, how much extra are you willing to pay for good service? Because I'm guessing that's about all a small independent can offer that's better than the local (mono|duo)poly. So while I think I get your point, I see it more as consumers voting with their wallets rather than voting out independents. Regards, Lee > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Lee" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Saturday, December 16, 2017 2:16:38 PM > Subject: Re: Free access to measurement network > > On 12/16/17, Mike Hammett wrote: >> It's a consumer thing. If consumers wanted more options, they would be >> supporting those options with their wallets. They don't. > > As far as I know, my options for >50Mb/s are comcast and verizon. > > https://www.broadbandmap.gov/ sez > Please note: National Broadband Map data is from June 30, 2014 and is > no longer being updated. > > How do I find out what my other options are? > > Thanks, > Lee > >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Saturday, December 16, 2017 4:43:54 AM >> Subject: Re: Free access to measurement network >> >> So for my point of view, better solution is to push some law that ease >> access to the buildings for ISPs. >> >> 15.12.17 19:40, valdis.kletnieks at vt.edu пише: >>> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >>>> What kind of internet are these devices on? With Net Neutrality gone >>>> here >>>> >>>> in the US it would be a good way to measure certain services such as SIP >>>> >>>> to >>>> see which ISP's if any are tampering with packets. >>> >>> Given previous history, the answer will probably be "most of them". >>> >>> "The results are not inspiring. More than 129 million people are limited >>> >>> to a >>> single provider for broadband Internet access using the FCC definition of >>> >>> 25 >>> Mbps download and 3 Mbps upload. Out of those 129 million Americans, >>> about >>> 52 >>> million must obtain Internet access from a company that has violated >>> network >>> neutrality protections in the past and continues to undermine the policy >>> >>> today. >>> >>> In locations where subscribers have the benefit of limited competition, >>> the >>> situation isn't much better. Among the 146 million Americans with the >>> ability >>> to choose between two providers, 48 million Americans must choose between >>> >>> two >>> companies that have a record of violating network neutrality." >>> >>> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality >>> >>> >>> >> >> > > From nanog at ics-il.net Sun Dec 17 19:50:09 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 17 Dec 2017 13:50:09 -0600 (CST) Subject: Free access to measurement network In-Reply-To: References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <1972630908.3367.1513456988082.JavaMail.mhammett@ThunderFuck> Message-ID: <1479845477.4038.1513540208065.JavaMail.mhammett@ThunderFuck> Try looking to see what independents might be around the area you're looking at. See if any of them are willing to expand. Many of us are chomping at the bit to expand (with competitive products), but are having a hard time nailing people down. Independents are more likely to have good customer service, not want to violate net neutrality principals, etc. Basically, are more likely to be the company you actually want. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Lee" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Sunday, December 17, 2017 1:46:19 PM Subject: Re: Free access to measurement network On 12/16/17, Mike Hammett wrote: > That project was paid for by ARRA funds and ran out. > > The FCC picked up the ball by expanding the scope of its 477 program. That > data is available directly on their site or via some sites like > broadbandnow.com I didn't know about that - thanks. But it just confirms what I thought; my choices are comcast & verizon. There is another possibility, but $350/mo for 10Mb/s with a 24 month contract is too steep. > There are also many service providers available that aren't filing because > either A) they don't know about it or B) government stuff. > > My point was that consumers voted out thousands of independents by taking > service from incumbents instead of independents. Thousands have closed up > shop. Where independents are available, it's still tough getting customers > if the incumbents have a service that mostly works (over say 5 to 10 megs), > even if the independent offers service comparable to the incumbent's > advertisements. As a consumer, how much extra are you willing to pay for good service? Because I'm guessing that's about all a small independent can offer that's better than the local (mono|duo)poly. So while I think I get your point, I see it more as consumers voting with their wallets rather than voting out independents. Regards, Lee > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Lee" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Saturday, December 16, 2017 2:16:38 PM > Subject: Re: Free access to measurement network > > On 12/16/17, Mike Hammett wrote: >> It's a consumer thing. If consumers wanted more options, they would be >> supporting those options with their wallets. They don't. > > As far as I know, my options for >50Mb/s are comcast and verizon. > > https://www.broadbandmap.gov/ sez > Please note: National Broadband Map data is from June 30, 2014 and is > no longer being updated. > > How do I find out what my other options are? > > Thanks, > Lee > >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Saturday, December 16, 2017 4:43:54 AM >> Subject: Re: Free access to measurement network >> >> So for my point of view, better solution is to push some law that ease >> access to the buildings for ISPs. >> >> 15.12.17 19:40, valdis.kletnieks at vt.edu пише: >>> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >>>> What kind of internet are these devices on? With Net Neutrality gone >>>> here >>>> >>>> in the US it would be a good way to measure certain services such as SIP >>>> >>>> to >>>> see which ISP's if any are tampering with packets. >>> >>> Given previous history, the answer will probably be "most of them". >>> >>> "The results are not inspiring. More than 129 million people are limited >>> >>> to a >>> single provider for broadband Internet access using the FCC definition of >>> >>> 25 >>> Mbps download and 3 Mbps upload. Out of those 129 million Americans, >>> about >>> 52 >>> million must obtain Internet access from a company that has violated >>> network >>> neutrality protections in the past and continues to undermine the policy >>> >>> today. >>> >>> In locations where subscribers have the benefit of limited competition, >>> the >>> situation isn't much better. Among the 146 million Americans with the >>> ability >>> to choose between two providers, 48 million Americans must choose between >>> >>> two >>> companies that have a record of violating network neutrality." >>> >>> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality >>> >>> >>> >> >> > > From rwebb at ropeguru.com Sun Dec 17 22:30:17 2017 From: rwebb at ropeguru.com (Robert Webb) Date: Sun, 17 Dec 2017 22:30:17 +0000 Subject: Companies using public IP space owned by others for internal routing Message-ID: Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. Robert From mattlists at rivervalleyinternet.net Sun Dec 17 22:33:09 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sun, 17 Dec 2017 17:33:09 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space. > On Dec 17, 2017, at 17:30, Robert Webb wrote: > > Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. > > Robert From rgolodner at infratection.com Sun Dec 17 22:42:48 2017 From: rgolodner at infratection.com (Richard) Date: Sun, 17 Dec 2017 16:42:48 -0600 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On 12/17/2017 04:30 PM, Robert Webb wrote: > Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. > > Robert > >     It is more common than you would think. Why use public IP's when you can have many rfc1918 options. Always amazes me after the initial confusion.     Richard From joelja at bogus.com Sun Dec 17 22:49:03 2017 From: joelja at bogus.com (joel jaeggli) Date: Sun, 17 Dec 2017 14:49:03 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On 12/17/17 14:30, Robert Webb wrote: > Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. every time I seen a traceroute with 11/8 22/8 26/8 in it I am duly impressed. > Robert > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From tyler at tgconrad.com Sun Dec 17 22:57:08 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Sun, 17 Dec 2017 14:57:08 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: I worked alongside a company that used addresses assigned to the Syrian govt for their "guest" network. They were a pretty large org, presumably this was done to reduce risk - firewall rules, accidentally leaking guest prefixes to their internal nets, or just straight-up simplicity. They were in a pretty heavily regulated industry with restrictions on what companies they could do business with, so there probably wasn't a huge risk of reachability issues. On Sunday, December 17, 2017, joel jaeggli wrote: > On 12/17/17 14:30, Robert Webb wrote: > > Will anyone comment on the practice of large enterprises using non > RFC1918 IP space that other entities are assigned by ARIN for internal > routing? > > > > Just curious as to how wide spread this might be. I just heard of this > happening with a large ISP and never really thought about it until now. > every time I seen a traceroute with 11/8 22/8 26/8 in it I am duly > impressed. > > Robert > > > > > From egon at egon.cc Sun Dec 17 22:57:28 2017 From: egon at egon.cc (James Downs) Date: Sun, 17 Dec 2017 14:57:28 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> > On Dec 17, 2017, at 14:33, Matt Hoppes wrote: > > Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space. Unless there isn't.. I've worked at more than one company that had used up all the private space. Then you have the cases where some M&A causes overlapping IP space. In addition, you'd also be surprised how many people just assign the entire 10/8 space into a flat IP space. -j From cb.list6 at gmail.com Sun Dec 17 23:15:46 2017 From: cb.list6 at gmail.com (Ca By) Date: Sun, 17 Dec 2017 23:15:46 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On Sun, Dec 17, 2017 at 5:31 PM Robert Webb wrote: > Will anyone comment on the practice of large enterprises using non RFC1918 > IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this > happening with a large ISP and never really thought about it until now. > > Robert To answer your question, it is not uncommon. It is bad, but you do what you have to do when rfc1918 is tied up > From chk at pobox.com Sun Dec 17 23:23:23 2017 From: chk at pobox.com (Harald Koch) Date: Sun, 17 Dec 2017 18:23:23 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On 17 December 2017 at 17:57, James Downs wrote: > Unless there isn't.. I've worked at more than one company that had used up > all the private space. Then you have the cases where some M&A causes > overlapping IP space. > Or places like Ontario, where the government runs a registry service for net 10/8 because we're all interconnecting our private networks over VPNs and there were too many NATs. -- Harald From lists at quux.de Sun Dec 17 23:25:29 2017 From: lists at quux.de (Jens Link) Date: Mon, 18 Dec 2017 00:25:29 +0100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: (Matt Hoppes's message of "Sun, 17 Dec 2017 17:33:09 -0500") References: Message-ID: <87mv2hndhy.fsf@pc8.berlin.quux.de> Matt Hoppes writes: > Had a previous employee or I discovered it on the network segment after > we had some weird routing issues and had to get that cleaned up. I don't > know why anyone would do that when there is tons of private IP space. Excuse 1: "We'll never connect to the internet!" Excuse 2: "It's only temporary!" Excuse 3: Typo (At some customers customer I found 192.!168 address which where apparently a typo but in use for years so nobody wanted to change it.) I also know one company who is using (has used?) 2001:8db::/48. I suggested to get v6 PI an properly implement IPv6 but never heard from them again. Excuse 4: "We used the addresses from out training material." - I heard this story some time ago: A large German government agency wanted to implement IP(v4) and the people attended a course about this new TCP/IP stuff at $Vendor. The training material was prepared by a student who was using his university's /16 as an example. BTW: Is the Cisco WLC 1.1.1.1 as default address for DHCP? Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From hvgeekwtrvl at gmail.com Mon Dec 18 01:10:14 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Sun, 17 Dec 2017 17:10:14 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <87mv2hndhy.fsf@pc8.berlin.quux.de> References: <87mv2hndhy.fsf@pc8.berlin.quux.de> Message-ID: I had a vendor at $dayjob prior to my arrival who assigned all their customers ip space based on the customer number. when i got there all the internal network was assigned space from an company in the middle east. $dayjob didn't have the in-house knowledge to know what was going on and as they never worried about the middle east it didn't affect their business. On Sun, Dec 17, 2017 at 3:25 PM, Jens Link wrote: > Matt Hoppes writes: > > > Had a previous employee or I discovered it on the network segment after > > we had some weird routing issues and had to get that cleaned up. I don't > > know why anyone would do that when there is tons of private IP space. > > Excuse 1: "We'll never connect to the internet!" > > Excuse 2: "It's only temporary!" > > Excuse 3: Typo (At some customers customer I found 192.!168 address which > where apparently a typo but in use for years so nobody wanted > to change it.) I also know one company who is using (has > used?) 2001:8db::/48. I suggested to get v6 PI an properly > implement IPv6 but never heard from them again. > > Excuse 4: "We used the addresses from out training material." - I heard > this story some time ago: A large German government agency > wanted to implement IP(v4) and the people attended a course > about this new TCP/IP stuff at $Vendor. The training material > was prepared by a student who was using his university's /16 as > an example. > > BTW: Is the Cisco WLC 1.1.1.1 as default address for DHCP? > > Jens > -- > ------------------------------------------------------------ > ---------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 > | > | http://blog.quux.de | jabber: jenslink at quux.de | > --------------- | > ------------------------------------------------------------ > ---------------- > From richard at pedantictheory.com Mon Dec 18 01:24:40 2017 From: richard at pedantictheory.com (Richard Porter) Date: Sun, 17 Dec 2017 18:24:40 -0700 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> Robert, I’ve heard of two cases recently, large companies (non carrier/ISP). One company looking to solve challenge with IPv6 and 6to4 and DNS. Also curious how wide-spread this is? Maybe just the kick in the butt for catching the elusive IPv6 unicorn? ~Richard > On Dec 17, 2017, at 3:30 PM, Robert Webb wrote: > > Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. > > Robert From hmcgregor at biggeeks.org Mon Dec 18 01:56:33 2017 From: hmcgregor at biggeeks.org (Harry McGregor) Date: Sun, 17 Dec 2017 18:56:33 -0700 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: <633DAADA-F0FE-472A-AF69-C11BD5946EB3@biggeeks.org> Hi, I know of some enterprise IT equipment that does this. It was reserved space at the time it was picked. It does not leak from the box, but every once in a while one of these IPs show up in a customer visible log, and causes confusion. In ways it is better then rfc 1918 space as it has less chance of conflicting with a management network. Harry On December 17, 2017 3:42:48 PM MST, Richard wrote: > > >On 12/17/2017 04:30 PM, Robert Webb wrote: >> Will anyone comment on the practice of large enterprises using non >RFC1918 IP space that other entities are assigned by ARIN for internal >routing? >> >> Just curious as to how wide spread this might be. I just heard of >this happening with a large ISP and never really thought about it until >now. >> >> Robert >> >> >     It is more common than you would think. Why use public IP's when >you can have many rfc1918 options. Always amazes me after the initial >confusion. >     Richard -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rwebb at ropeguru.com Mon Dec 18 02:20:44 2017 From: rwebb at ropeguru.com (Robert Webb) Date: Mon, 18 Dec 2017 02:20:44 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> Message-ID: Apologies for not responding sooner. This came to light with me on a forum where someone posted that they thought it strange that their MTA received an IP that is assigned to the DoD DNIC. Where I work I have the opposite issue. They have a lot of public IPv4 space and only use it internally never be advertised to the internet. Something I have never agreed With doing. Robert -----Original Message----- From: Richard Porter [mailto:richard at pedantictheory.com] Sent: Sunday, December 17, 2017 8:25 PM To: Robert Webb Cc: nanog at nanog.org Subject: Re: Companies using public IP space owned by others for internal routing Robert, I’ve heard of two cases recently, large companies (non carrier/ISP). One company looking to solve challenge with IPv6 and 6to4 and DNS. Also curious how wide-spread this is? Maybe just the kick in the butt for catching the elusive IPv6 unicorn? ~Richard > On Dec 17, 2017, at 3:30 PM, Robert Webb wrote: > > Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? > > Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. > > Robert From nanog at shat.net Mon Dec 18 02:31:01 2017 From: nanog at shat.net (Shaun) Date: Sun, 17 Dec 2017 20:31:01 -0600 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> Message-ID: <20171217203100.184A.B2447BB2@shat.net> On Sun, 17 Dec 2017 18:24:40 -0700 Richard Porter wrote: > Robert, > I’ve heard of two cases recently, large companies (non carrier/ISP). One company looking to solve challenge with IPv6 and 6to4 and DNS. > > Also curious how wide-spread this is? Maybe just the kick in the butt for catching the elusive IPv6 unicorn? As another data point, Microsoft is using parts of UK MoD's 25/8 for their hosted Exchange and Outlook infrastructure. Some references, -s From marka at isc.org Mon Dec 18 02:34:38 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 18 Dec 2017 13:34:38 +1100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> Message-ID: <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> > On 18 Dec 2017, at 1:20 pm, Robert Webb wrote: > > Apologies for not responding sooner. > > This came to light with me on a forum where someone posted that they thought it strange that their MTA received an IP that is assigned to the DoD DNIC. > > Where I work I have the opposite issue. They have a lot of public IPv4 space and only use it internally never be advertised to the internet. Something I have never agreed > With doing. > > Robert Why? This is a perfectly legitimate use of the IP addresses. The purpose of assigning addresses is so that they are unique WORLD WIDE in whatever context you wish to use them in. Mark > -----Original Message----- > From: Richard Porter [mailto:richard at pedantictheory.com] > Sent: Sunday, December 17, 2017 8:25 PM > To: Robert Webb > Cc: nanog at nanog.org > Subject: Re: Companies using public IP space owned by others for internal routing > > Robert, > I’ve heard of two cases recently, large companies (non carrier/ISP). One company looking to solve challenge with IPv6 and 6to4 and DNS. > > Also curious how wide-spread this is? Maybe just the kick in the butt for catching the elusive IPv6 unicorn? > > ~Richard > >> On Dec 17, 2017, at 3:30 PM, Robert Webb wrote: >> >> Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing? >> >> Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. >> >> Robert > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rwebb at ropeguru.com Mon Dec 18 02:49:45 2017 From: rwebb at ropeguru.com (Robert Webb) Date: Mon, 18 Dec 2017 02:49:45 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> Message-ID: > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Sunday, December 17, 2017 9:35 PM > To: Robert Webb > Cc: Richard Porter ; nanog at nanog.org > Subject: Re: Companies using public IP space owned by others for internal > routing > > > > On 18 Dec 2017, at 1:20 pm, Robert Webb wrote: > > > > Apologies for not responding sooner. > > > > This came to light with me on a forum where someone posted that they > thought it strange that their MTA received an IP that is assigned to the DoD > DNIC. > > > > Where I work I have the opposite issue. They have a lot of public IPv4 > > space and only use it internally never be advertised to the internet. > Something I have never agreed With doing. > > > > Robert > > Why? This is a perfectly legitimate use of the IP addresses. The purpose of > assigning addresses is so that they are unique WORLD WIDE in whatever > context you wish to use them in. > > Mark I going to guess you were talking about the use internally of public IP addresses.. But there are rules governing what to use where. So it is OK to hoard publicly addressable IPv4 IP's for internal use that will never reach the outside world? No the way I have been taught. Maybe I just lack that big picture.. Robert From large.hadron.collider at gmx.com Mon Dec 18 03:05:54 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Sun, 17 Dec 2017 19:05:54 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: Missent. Welcome to IPv6, where you have technically-reserved-for-future-use space that should never actually need to be used. Quite likely, you can use something like 440::/16 as your private space, but please don't do that unless you've exhausted the true private space. You're welcome. On 17/12/2017 14:57, James Downs wrote: >> On Dec 17, 2017, at 14:33, Matt Hoppes wrote: >> >> Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space. > Unless there isn't.. I've worked at more than one company that had used up all the private space. Then you have the cases where some M&A causes overlapping IP space. In addition, you'd also be surprised how many people just assign the entire 10/8 space into a flat IP space. > > -j From eric.kuhnke at gmail.com Mon Dec 18 04:31:22 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sun, 17 Dec 2017 20:31:22 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: some fun examples of the size of ipv6: https://samsclass.info/ipv6/exhaustion-2016.htm https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ On Sun, Dec 17, 2017 at 7:05 PM, Large Hadron Collider < large.hadron.collider at gmx.com> wrote: > Missent. > > Welcome to IPv6, where you have technically-reserved-for-future-use space > that should never actually need to be used. Quite likely, you can use > something like 440::/16 as your private space, but please don't do that > unless you've exhausted the true private space. > > You're welcome. > > > > On 17/12/2017 14:57, James Downs wrote: > >> On Dec 17, 2017, at 14:33, Matt Hoppes >>> wrote: >>> >>> Had a previous employee or I discovered it on the network segment after >>> we had some weird routing issues and had to get that cleaned up. I don't >>> know why anyone would do that when there is tons of private IP space. >>> >> Unless there isn't.. I've worked at more than one company that had used >> up all the private space. Then you have the cases where some M&A causes >> overlapping IP space. In addition, you'd also be surprised how many people >> just assign the entire 10/8 space into a flat IP space. >> >> -j >> > > From jason.iannone at gmail.com Mon Dec 18 13:58:37 2017 From: jason.iannone at gmail.com (Jason Iannone) Date: Mon, 18 Dec 2017 08:58:37 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: My previous employer used 198.18/15 for CE links on IPVPN services. Walgreens used an American SP's space internally and couldn't talk to any users in that space as a result. On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ > > On Sun, Dec 17, 2017 at 7:05 PM, Large Hadron Collider < > large.hadron.collider at gmx.com> wrote: > >> Missent. >> >> Welcome to IPv6, where you have technically-reserved-for-future-use space >> that should never actually need to be used. Quite likely, you can use >> something like 440::/16 as your private space, but please don't do that >> unless you've exhausted the true private space. >> >> You're welcome. >> >> >> >> On 17/12/2017 14:57, James Downs wrote: >> >>> On Dec 17, 2017, at 14:33, Matt Hoppes >>>> wrote: >>>> >>>> Had a previous employee or I discovered it on the network segment after >>>> we had some weird routing issues and had to get that cleaned up. I don't >>>> know why anyone would do that when there is tons of private IP space. >>>> >>> Unless there isn't.. I've worked at more than one company that had used >>> up all the private space. Then you have the cases where some M&A causes >>> overlapping IP space. In addition, you'd also be surprised how many people >>> just assign the entire 10/8 space into a flat IP space. >>> >>> -j >>> >> >> From bicknell at ufp.org Mon Dec 18 14:36:09 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Dec 2017 06:36:09 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <20171218143609.GA96296@ussenterprise.ufp.org> In a message written on Mon, Dec 18, 2017 at 08:58:37AM -0500, Jason Iannone wrote: > My previous employer used 198.18/15 for CE links on IPVPN services. This one is mostly legit: https://tools.ietf.org/html/rfc5735 -- Leo Bicknell - bicknell at ufp.org 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: not available URL: From shuque at gmail.com Sat Dec 16 01:22:47 2017 From: shuque at gmail.com (Shumon Huque) Date: Fri, 15 Dec 2017 20:22:47 -0500 Subject: Call For Presentations - DNS-OARC Workshop 28, San Juan, Puerto Rico, 8th/9th March 2018 Message-ID: [with apologies to those who see this on multiple lists] Call For Presentations The 28th DNS-OARC Workshop will be hosted by ICANN in San Juan, Puerto Rico, and will take place on March 8th and 9th immediately before ICANN61 (March 10th - 15th) [*] The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. The first day of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. Workshop Milestones: 19 Jan 2018 - Deadline for submission 23 Jan 2018 - Initial contribution list published 16 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Details for presentation submission are published here: The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Shumon Huque, on behalf of the OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) [*] From m1enrage at gmail.com Sun Dec 17 22:48:49 2017 From: m1enrage at gmail.com (Tom Carter) Date: Sun, 17 Dec 2017 15:48:49 -0700 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: RFC1918 isn't big enough to cover all use cases. Think about a large internet service providers. If you have ten million customers, 10.0.0.0/8 would be enough to number modems, but what happens when you need to number video set top boxes and voice end points? I don't think anyone goes out and says "Lets go use someone else's space, because I don't want to use this perfectly good private space". On Sun, Dec 17, 2017 at 3:42 PM, Richard wrote: > > > On 12/17/2017 04:30 PM, Robert Webb wrote: > >> Will anyone comment on the practice of large enterprises using non >> RFC1918 IP space that other entities are assigned by ARIN for internal >> routing? >> >> Just curious as to how wide spread this might be. I just heard of this >> happening with a large ISP and never really thought about it until now. >> >> Robert >> >> >> It is more common than you would think. Why use public IP's when you > can have many rfc1918 options. Always amazes me after the initial confusion. > Richard > From neal.rauhauser at gmail.com Sun Dec 17 20:41:57 2017 From: neal.rauhauser at gmail.com (Neal Rauhauser) Date: Sun, 17 Dec 2017 12:41:57 -0800 Subject: historic SWIP (or rwhois) data? Message-ID: Hello, I'm working on a forensics problem rather than a network operations issue. I've got a /28 that I can see is currently assigned to a certain company via rwhois. What I want to do is see this block's history over the last five years. It was involved in some problematic behavior back in 2012, I'd really like to know whose name was on it then. It would be ideal if this data were available in some sort of flat file format, or if a sensible API to it exists. I've been searching a little bit, just found this, not really seeing any place to download any of this data though. https://gist.github.com/NetwarSystem/eed78b65d881d0d384664ab713cf5e1f From narseo at gmail.com Mon Dec 18 14:22:50 2017 From: narseo at gmail.com (Narseo Vallina Rodriguez) Date: Mon, 18 Dec 2017 15:22:50 +0100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: We found a number of such instances when working in our last year's Internet Measurements Conference (IMC) paper [1] "A Multi-perspective Analysis of Carrier-Grade NAT Deployment". Back then, spring-summer 2016, we found a number of large cellular ISPs using routable IP address space for their private IP address space. Some cases were AS3651 (Sprint US) AS22140 (T−Mobile US) and AS24608 (H3G SpA IT) among others. We found this practice to be common in other ISPs but we did not have enough data to drive anything conclusive for them. One of the most common blocks was assigned to the UK Ministry of Defense as Shaun also pointed out for Microsoft. You can find the whole discussion is in Section 6.1 and Figure 7. [1] https://arxiv.org/abs/1605.05606 On Mon, Dec 18, 2017 at 2:58 PM, Jason Iannone wrote: > My previous employer used 198.18/15 for CE links on IPVPN services. > Walgreens used an American SP's space internally and couldn't talk to > any users in that space as a result. > > On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke wrote: >> some fun examples of the size of ipv6: >> >> https://samsclass.info/ipv6/exhaustion-2016.htm >> >> https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ >> >> On Sun, Dec 17, 2017 at 7:05 PM, Large Hadron Collider < >> large.hadron.collider at gmx.com> wrote: >> >>> Missent. >>> >>> Welcome to IPv6, where you have technically-reserved-for-future-use space >>> that should never actually need to be used. Quite likely, you can use >>> something like 440::/16 as your private space, but please don't do that >>> unless you've exhausted the true private space. >>> >>> You're welcome. >>> >>> >>> >>> On 17/12/2017 14:57, James Downs wrote: >>> >>>> On Dec 17, 2017, at 14:33, Matt Hoppes >>>>> wrote: >>>>> >>>>> Had a previous employee or I discovered it on the network segment after >>>>> we had some weird routing issues and had to get that cleaned up. I don't >>>>> know why anyone would do that when there is tons of private IP space. >>>>> >>>> Unless there isn't.. I've worked at more than one company that had used >>>> up all the private space. Then you have the cases where some M&A causes >>>> overlapping IP space. In addition, you'd also be surprised how many people >>>> just assign the entire 10/8 space into a flat IP space. >>>> >>>> -j >>>> >>> >>> -- Narseo Vallina-Rodriguez Research Staff, ICSI Personal web: http://www.icsi.berkeley.edu/~narseo Twitter: https://twitter.com/narseo From nanog at ics-il.net Mon Dec 18 16:01:33 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Dec 2017 10:01:33 -0600 (CST) Subject: historic SWIP (or rwhois) data? In-Reply-To: References: Message-ID: <1524477945.4984.1513612891770.JavaMail.mhammett@ThunderFuck> ARIN's WhoWas service? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Neal Rauhauser" To: "NANOG list" Sent: Sunday, December 17, 2017 2:41:57 PM Subject: historic SWIP (or rwhois) data? Hello, I'm working on a forensics problem rather than a network operations issue. I've got a /28 that I can see is currently assigned to a certain company via rwhois. What I want to do is see this block's history over the last five years. It was involved in some problematic behavior back in 2012, I'd really like to know whose name was on it then. It would be ideal if this data were available in some sort of flat file format, or if a sensible API to it exists. I've been searching a little bit, just found this, not really seeing any place to download any of this data though. https://gist.github.com/NetwarSystem/eed78b65d881d0d384664ab713cf5e1f From EPers at ansencorp.com Mon Dec 18 16:03:52 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Mon, 18 Dec 2017 16:03:52 +0000 Subject: Free access to measurement network In-Reply-To: <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, the fact that both the city I work in and the town I live in have local govt-enforced monopolies reinforces the statement that I've (and all the other people near me) been voting with our collective wallets this entire time -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, December 16, 2017 10:23 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Saturday, December 16, 2017 4:43:54 AM Subject: Re: Free access to measurement network So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone >> here in the US it would be a good way to measure certain services >> such as SIP to see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are > limited to a single provider for broadband Internet access using the > FCC definition of 25 Mbps download and 3 Mbps upload. Out of those 129 > million Americans, about 52 million must obtain Internet access from a > company that has violated network neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited > competition, the situation isn't much better. Among the 146 million > Americans with the ability to choose between two providers, 48 million > Americans must choose between two companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neut > rality > From nanog at ics-il.net Mon Dec 18 16:05:08 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Dec 2017 10:05:08 -0600 (CST) Subject: Free access to measurement network In-Reply-To: References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> Message-ID: <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> BTW: There are no government-enforced monopolies anywhere in the US, aside from possibly Native American reservations. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Edwin Pers" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, December 18, 2017 10:03:52 AM Subject: RE: Free access to measurement network Yes, the fact that both the city I work in and the town I live in have local govt-enforced monopolies reinforces the statement that I've (and all the other people near me) been voting with our collective wallets this entire time -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, December 16, 2017 10:23 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Saturday, December 16, 2017 4:43:54 AM Subject: Re: Free access to measurement network So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone >> here in the US it would be a good way to measure certain services >> such as SIP to see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are > limited to a single provider for broadband Internet access using the > FCC definition of 25 Mbps download and 3 Mbps upload. Out of those 129 > million Americans, about 52 million must obtain Internet access from a > company that has violated network neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited > competition, the situation isn't much better. Among the 146 million > Americans with the ability to choose between two providers, 48 million > Americans must choose between two companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neut > rality > From benoit.panizzon at imp.ch Mon Dec 18 16:11:01 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Mon, 18 Dec 2017 17:11:01 +0100 Subject: historic SWIP (or rwhois) data? In-Reply-To: References: Message-ID: <20171218171101.2eade002@go.imp.ch> Well @ RIPE ist is quite simple to query historical data: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/types-of-queries/16-12-historical-queries I don't know if other registries offer similar services. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From timrutherford at c4.net Mon Dec 18 16:25:37 2017 From: timrutherford at c4.net (timrutherford at c4.net) Date: Mon, 18 Dec 2017 11:25:37 -0500 Subject: Free access to measurement network In-Reply-To: <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> Message-ID: <015d01d3781c$d6775ac0$83661040$@c4.net> The problem lies in the contracts that the big providers make the municipalities sign. Basically says that the incumbent cable provider cannot be ousted without breach of contract. The towns all sign because their only other choice is to roll out their own infrastructure which very few see the real value in. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, December 18, 2017 11:05 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network BTW: There are no government-enforced monopolies anywhere in the US, aside from possibly Native American reservations. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Edwin Pers" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, December 18, 2017 10:03:52 AM Subject: RE: Free access to measurement network Yes, the fact that both the city I work in and the town I live in have local govt-enforced monopolies reinforces the statement that I've (and all the other people near me) been voting with our collective wallets this entire time -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, December 16, 2017 10:23 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Saturday, December 16, 2017 4:43:54 AM Subject: Re: Free access to measurement network So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone >> here in the US it would be a good way to measure certain services >> such as SIP to see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are > limited to a single provider for broadband Internet access using the > FCC definition of 25 Mbps download and 3 Mbps upload. Out of those 129 > million Americans, about 52 million must obtain Internet access from a > company that has violated network neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited > competition, the situation isn't much better. Among the 146 million > Americans with the ability to choose between two providers, 48 million > Americans must choose between two companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neut > rality > From nanog at ics-il.net Mon Dec 18 16:28:16 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Dec 2017 10:28:16 -0600 (CST) Subject: Free access to measurement network In-Reply-To: <015d01d3781c$d6775ac0$83661040$@c4.net> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> Message-ID: <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> Anyone can roll their own wireline at the maximum regulatory effort of becoming a CLEC and construction permits. Some jurisdictions will let you in without this, but if you have the former, they must allow you the same access as the ILEC. Otherwise, they can do fixed wireless. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: timrutherford at c4.net To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, December 18, 2017 10:25:37 AM Subject: RE: Free access to measurement network The problem lies in the contracts that the big providers make the municipalities sign. Basically says that the incumbent cable provider cannot be ousted without breach of contract. The towns all sign because their only other choice is to roll out their own infrastructure which very few see the real value in. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, December 18, 2017 11:05 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network BTW: There are no government-enforced monopolies anywhere in the US, aside from possibly Native American reservations. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Edwin Pers" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, December 18, 2017 10:03:52 AM Subject: RE: Free access to measurement network Yes, the fact that both the city I work in and the town I live in have local govt-enforced monopolies reinforces the statement that I've (and all the other people near me) been voting with our collective wallets this entire time -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, December 16, 2017 10:23 AM Cc: nanog at nanog.org Subject: Re: Free access to measurement network It's a consumer thing. If consumers wanted more options, they would be supporting those options with their wallets. They don't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Saturday, December 16, 2017 4:43:54 AM Subject: Re: Free access to measurement network So for my point of view, better solution is to push some law that ease access to the buildings for ISPs. 15.12.17 19:40, valdis.kletnieks at vt.edu пише: > On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said: >> What kind of internet are these devices on? With Net Neutrality gone >> here in the US it would be a good way to measure certain services >> such as SIP to see which ISP's if any are tampering with packets. > > Given previous history, the answer will probably be "most of them". > > "The results are not inspiring. More than 129 million people are > limited to a single provider for broadband Internet access using the > FCC definition of 25 Mbps download and 3 Mbps upload. Out of those 129 > million Americans, about 52 million must obtain Internet access from a > company that has violated network neutrality protections in the past and continues to undermine the policy today. > > In locations where subscribers have the benefit of limited > competition, the situation isn't much better. Among the 146 million > Americans with the ability to choose between two providers, 48 million > Americans must choose between two companies that have a record of violating network neutrality." > > https://muninetworks.org/content/177-million-americans-harmed-net-neut > rality > From SNaslund at medline.com Mon Dec 18 16:34:58 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 18 Dec 2017 16:34:58 +0000 Subject: Free access to measurement network In-Reply-To: <015d01d3781c$d6775ac0$83661040$@c4.net> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA5F4B0@MUNPRDMBXA1.medline.com> They may not be monopolies by definition but they act like one when there is only a single viable option. In Chicago I have access to Comcast Cable (city franchise cable provider in this area), AT&T Uverse (no fiber to the home so its DSL), or some wireless options (line of sight is tough, and non-LOS is not very fast). If I want always on > 50 mbps service it is pretty much Comcast. If you don't like the reliability or customer service, too bad. At my summer home in Wisconsin we have access to CenturyLink (the protected RLEC) or satellite. That's it. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Monday, December 18, 2017 11:05 AM >Cc: nanog at nanog.org >Subject: Re: Free access to measurement network > >BTW: There are no government-enforced monopolies anywhere in the US, aside from possibly Native American reservations. > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From SNaslund at medline.com Mon Dec 18 16:39:43 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 18 Dec 2017 16:39:43 +0000 Subject: Free access to measurement network In-Reply-To: <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> Not if you are in an RLEC controlled territory you can't. They are protected monopolies by definition. You could do fixed wireless but not real cost effective to deploy in low density rural environments. Especially when there is a lack of cellular infrastructure to piggyback the infrastructure on. Anyone that has been a CLEC knows that the ILEC have squeezed the CLECs out of the wireline space pretty effectively. It is nearly impossible to compete with the already amortized ILEC wireline networks and you can't do your own cable infrastructure without a city franchise in most areas. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Monday, December 18, 2017 10:28 AM >Cc: nanog at nanog.org >Subject: Re: Free access to measurement network > >Anyone can roll their own wireline at the maximum regulatory effort of becoming a CLEC and construction permits. Some jurisdictions will let you in without this, but if you have the former, they must allow you the same access as the >ILEC. > >Otherwise, they can do fixed wireless. > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From nanog at ics-il.net Mon Dec 18 16:43:23 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Dec 2017 10:43:23 -0600 (CST) Subject: Free access to measurement network In-Reply-To: <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> References: <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> Message-ID: <2139593962.5058.1513615401459.JavaMail.mhammett@ThunderFuck> There's nothing stopping you from using CLEC status to build in the ROW of an RLEC area. Fixed wireless is the most cost effective way to deploy in rural environments, other than at some point ultra rural, satellite takes over. That's kinda what WISPs have been doing for 20 years. So don't own cable. Build fiber. There's nothing stopping you from doing that. If you're going CLEC and using the ILEC's copper, go bigger. Most of the big ILECs are still rolling with sub 10 megabit speeds. I know some CLECs doing ADSL2+, VDSL, etc. Not as wide-reaching, no, but it's something and generates revenue while you build your own plant. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Steve Naslund" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, December 18, 2017 10:39:43 AM Subject: RE: Free access to measurement network Not if you are in an RLEC controlled territory you can't. They are protected monopolies by definition. You could do fixed wireless but not real cost effective to deploy in low density rural environments. Especially when there is a lack of cellular infrastructure to piggyback the infrastructure on. Anyone that has been a CLEC knows that the ILEC have squeezed the CLECs out of the wireline space pretty effectively. It is nearly impossible to compete with the already amortized ILEC wireline networks and you can't do your own cable infrastructure without a city franchise in most areas. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Monday, December 18, 2017 10:28 AM >Cc: nanog at nanog.org >Subject: Re: Free access to measurement network > >Anyone can roll their own wireline at the maximum regulatory effort of becoming a CLEC and construction permits. Some jurisdictions will let you in without this, but if you have the former, they must allow you the same access as the >ILEC. > >Otherwise, they can do fixed wireless. > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From baldur.norddahl at gmail.com Mon Dec 18 17:01:39 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 18 Dec 2017 18:01:39 +0100 Subject: 40G and 100G optics options Message-ID: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> Hi What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? I see a lot of switches offered with QSFP+ and QSFP28. But I do not seem to find the necessary optics to build the links I want. For example, take a look at the options available at Fiberstore: https://www.fs.com/c/generic-40g-qsfp-891 Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC Transceiver for SMF $340 Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC Transceiver for SMF $1500 https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver $1999 Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver $7000 That is it. Four modules and the 40km are prohibitive expensive. The situation at other vendors appears to be similar. I need stronger modules that can do more than 10 km without being extremely expensive. Or DWDM modules in the 1550 nm band so I can use external amplifiers. Am I looking in the wrong place? Is this expected to be available in the near future? Regards, Baldur From SNaslund at medline.com Mon Dec 18 17:19:54 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 18 Dec 2017 17:19:54 +0000 Subject: Free access to measurement network In-Reply-To: <2139593962.5058.1513615401459.JavaMail.mhammett@ThunderFuck> References: <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> <2139593962.5058.1513615401459.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA5F571@MUNPRDMBXA1.medline.com> That must be recent change then because last time I looked RLECs are pretty well protected from CLEC competition. That was the original telecom act difference between CLECs and RLECs. Their argument was that it was so hard to be economically viable in low density areas that they deserved to have exclusive access to their infrastructure. However the biggest thing stopping a CLEC from building in a ROW is economics. The RLEC wouldn't even be there without all of the government subsidies they got to build in the first place. I think the market has already spoken pretty resoundingly about building out infrastructure as a CLEC. You would have to step over all of the corpses on your way to doing so. In fact, I can’t off the top of my head think of a single CLEC that has widespread coverage over their own infrastructure. They almost universally use the ILEC infrastructure for last mile. Even the giants like Level 3 are pretty much unavailable unless you are in the heart of the NFL sized city. As far as rural wireless, we have found very few options in any of the markets we have looked into. The same density issues that prevent high quality cellular build outs also applies to WISPs. In the rural area the WISP still needs backhaul and antenna infrastructure. The lack of national scale WISPs tells me that model is not going to be viable at scale. Too much infrastructure for too few customers is the common killer of CLECs and WISPs. The biggest WISPs I know of are mostly urban as alternatives to the ILEC infrastructure not in rural areas and are used mostly as backup providers. Most facilities based DSL providers (i.e. equipment collocated with the ILECs) died quite some time ago. There were lots of them in the 1999 - 2005 timeframe and they are all dead now. You just can't compete with the ILEC cost model. I think the only model that would possibly bring out any viable competition in the last mile would be municipality owned infrastructure. The problem with that model is the municipalities love to offer exclusive contracts instead of an open infrastructure because they get the big payday. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Monday, December 18, 2017 10:43 AM >Cc: nanog at nanog.org >Subject: Re: Free access to measurement network > >There's nothing stopping you from using CLEC status to build in the ROW of an RLEC area. > >Fixed wireless is the most cost effective way to deploy in rural environments, other than at some point ultra rural, satellite takes over. That's kinda what WISPs have been doing for 20 years. > >So don't own cable. Build fiber. There's nothing stopping you from doing that. > >If you're going CLEC and using the ILEC's copper, go bigger. Most of the big ILECs are still rolling with sub 10 megabit speeds. I know some CLECs doing ADSL2+, VDSL, etc. Not as wide-reaching, no, but it's something and generates ?>revenue while you build your own plant. > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From pozar at lns.com Mon Dec 18 17:34:07 2017 From: pozar at lns.com (Tim Pozar) Date: Mon, 18 Dec 2017 09:34:07 -0800 Subject: 40G and 100G optics options In-Reply-To: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> Message-ID: <3e069b6f-6cfc-98d2-467e-125971ef1179@lns.com> Have you checked out Flexoptix? https://www.flexoptix.net/en/transceiver/qsfp_ Tim On 12/18/17 9:01 AM, Baldur Norddahl wrote: > Hi > > What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? > > I see a lot of switches offered with QSFP+ and QSFP28. But I do not seem > to find the necessary optics to build the links I want. > > For example, take a look at the options available at Fiberstore: > > https://www.fs.com/c/generic-40g-qsfp-891 > > Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC Transceiver > for SMF > $340 > > Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC Transceiver > for SMF > $1500 > > https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 > > Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver > $1999 > > Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver > $7000 > > That is it. Four modules and the 40km are prohibitive expensive. The > situation at other vendors appears to be similar. > > I need stronger modules that can do more than 10 km without being > extremely expensive. Or DWDM modules in the 1550 nm band so I can use > external amplifiers. Am I looking in the wrong place? Is this expected > to be available in the near future? > > Regards, > > Baldur From joelja at bogus.com Mon Dec 18 17:40:30 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 18 Dec 2017 09:40:30 -0800 Subject: 40G and 100G optics options In-Reply-To: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> Message-ID: <36bb0023-38b4-7b35-71eb-5ef7fe2e7d5c@bogus.com> On 12/18/17 09:01, Baldur Norddahl wrote: > Hi > > What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km > links? > > I see a lot of switches offered with QSFP+ and QSFP28. But I do not > seem to find the necessary optics to build the links I want. > > For example, take a look at the options available at Fiberstore: > > https://www.fs.com/c/generic-40g-qsfp-891 > > Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC > Transceiver for SMF > $340 > > Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC > Transceiver for SMF > $1500 > > https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 > > Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver > $1999 > > Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver > $7000 > > That is it. Four modules and the 40km are prohibitive expensive. The > situation at other vendors appears to be similar. > > I need stronger modules that can do more than 10 km without being > extremely expensive. Or DWDM modules in the 1550 nm band so I can use > external amplifiers. Am I looking in the wrong place? Is this expected > to be available in the near future? qsfp28 is heavily constrained by power budget. The inability to put a serdes in the package does also very much constrain the form factor since it's 4x25 wavelengths. cfp2-aco is the approach that stops paying for the DSP with every optic (DCO does that) gets you long haul single wave, DWDM and tunables, but it's  a bit of an incovenient form-factor for fixed configuration 1ru switches. > > Regards, > > Baldur > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From SNaslund at medline.com Mon Dec 18 17:40:38 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 18 Dec 2017 17:40:38 +0000 Subject: Free access to measurement network In-Reply-To: References: <127166.1513359634@turing-police.cc.vt.edu> <035bc299-99ab-e485-2114-912b167b691f@netassist.ua> <1894627970.2856.1513437766962.JavaMail.mhammett@ThunderFuck> <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck>, <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA5F5B1@MUNPRDMBXA1.medline.com> It absolutely is the same issue. Rural electrification and rural telecommunications are the same model, neither one happened without govt subsidies because the economics don't work any other way. Same kind of engineering challenges when you build a large expensive distribution system for a very inexpensive product (kilowatts or megabits don't matter much). The ROI is really difficult unless you have a captive audience. That is why you don't see big CLEC build outs. Why pay to put in a fiber cable with a 100 year lifecycle to a customer that might move and/or dump you in the next six months? The churn will kill you. You cannot amortize the cost of the infrastructure within any reasonable time frame. Go ahead and tell a VC that your infrastructure has a 10 - 20 year ROI (if you are lucky) and see if you get laughed out of the room. The WISPs and satellite guys are just like putting in windmills and solar panels to avoid the power company. Some will do it but most don't like the inconvenience or complexity of it. A fringe group at best. Telecom is even worse that power because there is a very good chance that your infrastructure will be obsolete or devalued before it pays for itself. Look at how DWDM technologies murdered the dark fiber markets and oceanic fiber links. Global Crossing ring a bell anyone? In some municipalities the city owns the infrastructure now but they want that big payday from the award of the exclusive contract so there really is not much competition there. In the "open" power market most cities find out that the most viable option turns out to be the incumbent power company that originally built out the infrastructure in the first place. Chicago was a major failure of the open power market when all of the "competitors" had huge price swings and everyone went back to the incumbent Commonwealth Edison. The real motivator was that the city really just wanted a way to get in between the customers and power company, they just could not resist the revenue. Same thing in cable service where the city gets their share of the money for essentially locking out the competition. Steven Naslund Chicago IL >-----Original Message----- >From: UpTide . [mailto:UpTide at live.com] >Sent: Monday, December 18, 2017 10:55 AM >To: Naslund, Steve >Subject: Re: Free access to measurement network > >Sounds like the history of the electric companies. From hugge at nordu.net Mon Dec 18 17:49:37 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Mon, 18 Dec 2017 18:49:37 +0100 Subject: 40G and 100G optics options In-Reply-To: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> Message-ID: <648a5a1a-9db6-d218-c529-8175beabc37e@nordu.net> This is the "failure" of us (the business) choosing QSFP as the de-factor formfactor for 100G, there is not power in that cage to make 10km+ optics in an easy way. If we would have pushed for CFP4 as the "last" formfactor in 100G land we would be much better off. The options you have to choose from realistically is QSFP28-ER4L It exist in a fec and non-fec option that does 30 and 40km respectively although a few vendors spec them at 25km cause its really hard to validate them in their upper ranges. But this is quite and expensive optic. On the horizon you have QSFP28-4WDM20 and 4WDM40 which uses FEC. Not sure where the MSA stands on that. If you need more then 30-40km reliable stuff you need to either to PAM4 (The "Inphi ColorZ" optic) which is 80km at best. These should not be confused for the regular 10G ZR-optics with a fixed lambda you can buy for $300 from china. These are dual-laser optics that runs two 50G PAM4 carriers with very low launchpower. They need pre and post-amps aswell as tuned DCM and a MUX to fully work. Also they are fixed wave so you need 44 different optics to populate a full MUX. These optics are great if you need tons of 100Gs on very short metro-spans. It always almost ends up with coherent being the better option in the end anyway if you wanna go beyond 20-25km. There is like 30 different competing products on the market now that acts as a stupid little transponder with a QSFP28 in one end (where you plug your DAC in) and a CFP2-ACO (or DCO) in the other end that let you run a couple of hundred kilometers (or thousands) with a proper coherent DWDM signal. Now that CFP2-DCO is GA finally i hope to see more linecards and switches that has CFP2 slots in them. > Hi > > What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? > > I see a lot of switches offered with QSFP+ and QSFP28. But I do not seem > to find the necessary optics to build the links I want. > > For example, take a look at the options available at Fiberstore: > > https://www.fs.com/c/generic-40g-qsfp-891 > > Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC Transceiver > for SMF > $340 > > Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC Transceiver > for SMF > $1500 > > https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 > > Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver > $1999 > > Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver > $7000 > > That is it. Four modules and the 40km are prohibitive expensive. The > situation at other vendors appears to be similar. > > I need stronger modules that can do more than 10 km without being > extremely expensive. Or DWDM modules in the 1550 nm band so I can use > external amplifiers. Am I looking in the wrong place? Is this expected > to be available in the near future? > > Regards, > > Baldur > -- hugge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From brandon at rd.bbc.co.uk Mon Dec 18 18:03:48 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 18 Dec 2017 18:03:48 +0000 Subject: 40G and 100G optics options In-Reply-To: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> Message-ID: <20171218180348.GA24619@sunf10.rd.bbc.co.uk> On Mon Dec 18, 2017 at 06:01:39PM +0100, Baldur Norddahl wrote: > What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? LR4 and weak ER4 (flexoptix were trying to get a 40km part out, only 25km has emerged so far) then you're into coherent stuff in a separate box (which per 100G doesn't cost a lot more than the ER4's) > I need stronger modules that can do more than 10 km without being > extremely expensive. Or DWDM modules in the 1550 nm band so I can use > external amplifiers. We use 1310 amplifiers for now, originally these http://www.hubersuhner.com/en/solutions/cube-optics/products/active-systems/metro-transport/soa-semiconductor-optical-amplifier-unit-c-250 but there is a fibrestore version too now https://www.fs.com/products/69350.html > Am I looking in the wrong place? Is this expected > to be available in the near future? Eventually there will be something once they can make it fit in qsfp package size and power limits. brandon From nanog at ics-il.net Mon Dec 18 19:20:24 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Dec 2017 13:20:24 -0600 (CST) Subject: Free access to measurement network In-Reply-To: <9578293AE169674F9A048B2BC9A081B4027EA5F571@MUNPRDMBXA1.medline.com> References: <873942930.4990.1513613104351.JavaMail.mhammett@ThunderFuck> <015d01d3781c$d6775ac0$83661040$@c4.net> <123805446.5050.1513614495715.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4027EA5F4CB@MUNPRDMBXA1.medline.com> <2139593962.5058.1513615401459.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4027EA5F571@MUNPRDMBXA1.medline.com> Message-ID: <1361251563.5222.1513624820512.JavaMail.mhammett@ThunderFuck> The RLEC infrastructure doesn't include the ROW. That belongs to the municipality. You are largely correct that you don't have access to RLEC infrastructure. IANAL, so I don't know the precise limitations. Many have been made to port their numbers, but some are still protected. You won't see me defending USF-funded golden toilets. That said, RLECs are a fairly small amount of the problem and you can always do fixed wireless to overcome economics in their areas. The biggest thing stopping a CLEC from building in the ROW is economics? That's generally the biggest inhibitor to any infrastructure, but it's being overcome all of the time. I know a lot of guys have the cost per home for FTTH well under $1k/home. Depending on services sold, that's a reasonable 1 - 3 year ROI. You don't have to be cheaper, you just have to be better. One of my clients is still going doing CLEC DSL for about 13 years. They don't mess with their customer's traffic. They have good customer support. We all know you can't expect them to have a superior service and compete on price. If you want something not shit, buy it. Don't force someone to polish a turd. There are thousands of WISPs in the US. I know because I've been one for about 13 years, I go to the trade shows, and I have the largest WISP-focused podcast. I'll go tell them that they can't do what they're doing. Those urban guys are pretty new to the scene and represent probably less than 5% of the WISP industry. Some of the non-urban ones are delivering 100M+ services. Some of them are in the middle of nowhere, building their own infrastructure to deliver the only non-satellite service available. The biggest WISPs I know (100k+ customers) are all outside of urban areas. There are a ton that are 10k+. Most are probably 500 - 5k. Obviously nothing compared to the incumbents, but I'm not sure being like the incumbents is what anyone wants. I think the biggest thing this thread reveals is that just because someone operates a network doesn't mean they know how all types of networks operate (or are available). ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Monday, December 18, 2017 11:19:54 AM Subject: RE: Free access to measurement network That must be recent change then because last time I looked RLECs are pretty well protected from CLEC competition. That was the original telecom act difference between CLECs and RLECs. Their argument was that it was so hard to be economically viable in low density areas that they deserved to have exclusive access to their infrastructure. However the biggest thing stopping a CLEC from building in a ROW is economics. The RLEC wouldn't even be there without all of the government subsidies they got to build in the first place. I think the market has already spoken pretty resoundingly about building out infrastructure as a CLEC. You would have to step over all of the corpses on your way to doing so. In fact, I can’t off the top of my head think of a single CLEC that has widespread coverage over their own infrastructure. They almost universally use the ILEC infrastructure for last mile. Even the giants like Level 3 are pretty much unavailable unless you are in the heart of the NFL sized city. As far as rural wireless, we have found very few options in any of the markets we have looked into. The same density issues that prevent high quality cellular build outs also applies to WISPs. In the rural area the WISP still needs backhaul and antenna infrastructure. The lack of national scale WISPs tells me that model is not going to be viable at scale. Too much infrastructure for too few customers is the common killer of CLECs and WISPs. The biggest WISPs I know of are mostly urban as alternatives to the ILEC infrastructure not in rural areas and are used mostly as backup providers. Most facilities based DSL providers (i.e. equipment collocated with the ILECs) died quite some time ago. There were lots of them in the 1999 - 2005 timeframe and they are all dead now. You just can't compete with the ILEC cost model. I think the only model that would possibly bring out any viable competition in the last mile would be municipality owned infrastructure. The problem with that model is the municipalities love to offer exclusive contracts instead of an open infrastructure because they get the big payday. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Monday, December 18, 2017 10:43 AM >Cc: nanog at nanog.org >Subject: Re: Free access to measurement network > >There's nothing stopping you from using CLEC status to build in the ROW of an RLEC area. > >Fixed wireless is the most cost effective way to deploy in rural environments, other than at some point ultra rural, satellite takes over. That's kinda what WISPs have been doing for 20 years. > >So don't own cable. Build fiber. There's nothing stopping you from doing that. > >If you're going CLEC and using the ILEC's copper, go bigger. Most of the big ILECs are still rolling with sub 10 megabit speeds. I know some CLECs doing ADSL2+, VDSL, etc. Not as wide-reaching, no, but it's something and generates ?>revenue while you build your own plant. > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From chk at pobox.com Mon Dec 18 19:34:29 2017 From: chk at pobox.com (Harald Koch) Date: Mon, 18 Dec 2017 14:34:29 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On 17 December 2017 at 17:48, Tom Carter wrote: > RFC1918 isn't big enough to cover all use cases. Think about a large > internet service providers. If you have ten million customers, 10.0.0.0/8 > would be enough to number modems, but what happens when you need to number > video set top boxes and voice end points? I don't think anyone goes out and > says "Lets go use someone else's space, because I don't want to use this > perfectly good private space". > :cough: They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can... -- Harald From marka at isc.org Mon Dec 18 20:34:23 2017 From: marka at isc.org (Mark Andrews) Date: Tue, 19 Dec 2017 07:34:23 +1100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: <60D511B3-4EBE-4AAA-A3E0-068AD079BBAB@isc.org> Companies like COMCAST did. They manage the modems over IPv6. They also supported DS-Lite’s development as a transition mechanism so they wouldn’t have to run IPv4 to their customers. They wanted to be able to go IPv6 only. That meant having IPv4 as a service available. -- Mark Andrews > On 19 Dec 2017, at 06:34, Harald Koch wrote: > >> On 17 December 2017 at 17:48, Tom Carter wrote: >> >> RFC1918 isn't big enough to cover all use cases. Think about a large >> internet service providers. If you have ten million customers, 10.0.0.0/8 >> would be enough to number modems, but what happens when you need to number >> video set top boxes and voice end points? I don't think anyone goes out and >> says "Lets go use someone else's space, because I don't want to use this >> perfectly good private space". >> > > :cough: > > They could use IPv6. I mean, if the mobile phone companies can figure it > out, surely an ISP can... > > -- > Harald From tmorizot at gmail.com Mon Dec 18 21:09:05 2017 From: tmorizot at gmail.com (Scott Morizot) Date: Mon, 18 Dec 2017 15:09:05 -0600 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> Message-ID: On Sun, Dec 17, 2017 at 8:49 PM, Robert Webb wrote: > > From: Mark Andrews [mailto:marka at isc.org] > > > On 18 Dec 2017, at 1:20 pm, Robert Webb wrote: > > > > > > Where I work I have the opposite issue. They have a lot of public IPv4 > > > space and only use it internally never be advertised to the internet. > > > Something I have never agreed With doing. > > > > Why? This is a perfectly legitimate use of the IP addresses. The > purpose of > > assigning addresses is so that they are unique WORLD WIDE in whatever > > context you wish to use them in. > > I going to guess you were talking about the use internally of public IP > addresses.. > > But there are rules governing what to use where. So it is OK to hoard > publicly addressable IPv4 IP's for internal > use that will never reach the outside world? No the way I have been taught. > > Maybe I just lack that big picture.. > > I think the big picture here is that they helped fund the development of IP and received large enough v4 allocations at the outset that they haven't had to use kludges like RFC1918 as much as most others have. It's not "hoarding" IPs if you're using them, whether or not you choose to advertise and make them accessible to other networks. It's the world everyone gets to live in with the current version of IP. Scott From bill at herrin.us Mon Dec 18 23:09:16 2017 From: bill at herrin.us (William Herrin) Date: Mon, 18 Dec 2017 18:09:16 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/ > 2qxgxw/self_just_how_big_is_ipv6/ Hi Eric, Lies, damn lies and statistics. Both projections assume that IPv6 addresses are assigned the same way we assign IPv4 addresses. They are not. There are several practices which consume IPv6 at a drastically higher rate than IPv4. The most notable is the assignment of a /64 to every LAN. Your /26 LAN that used to consume 2^6th IP addresses? Now it's 2^64th. Used to consume RFC1918 addresses? Now it's 2^64th of the global IPv6 addresses. Why did we need a /64 for each LAN? So we could incorporate the Ethernet MAC address in to the IP address. Only we can't actually do that because it turns out to be crazy insecure. Nevertheless, the 3 computers in your basement will still consume 2^64th IPv6 addresses between them. But hey, what's 20 orders of magnitude between friends. We have ISPs that have received allocations of entire /19s. A /19 in IPv6 is exactly the same percentage of the total address space as a /19 in IPv4. Before considering reserved addresses, it's 1/2^19th of the total address space. For a single ISP. Think about it. Meanwhile the IETF has learned nothing from the gargantuan waste that is 224.0.0.0/4 ($2billion at current prices). They went and assigned FC00::/7. /7!! Almost 1% of the IPv6 address space gone in a single RFC. I haven't attempted to compute the actual rate of IPv6 consumption but it's not inconceivable that we could exhaust them by the end of the century through sheer ineptitude. On the plus side, we're mostly only screwing around with 2000::/3 right now. After we burn through that in the next 20 years, we can if we so desire change the rules for how (and how quickly) we use 4000::/3. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From rwebb at ropeguru.com Tue Dec 19 00:33:00 2017 From: rwebb at ropeguru.com (Robert Webb) Date: Tue, 19 Dec 2017 00:33:00 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> , Message-ID: Who are you alluding to who helped fund the development of the internet? Get Outlook for Android From: Scott Morizot Sent: Monday, December 18, 16:09 Subject: Re: Companies using public IP space owned by others for internal routing To: Robert Webb Cc: Mark Andrews, nanog at nanog.org On Sun, Dec 17, 2017 at 8:49 PM, Robert Webb > wrote: > From: Mark Andrews [mailto:marka at isc.org] > > On 18 Dec 2017, at 1:20 pm, Robert Webb > wrote: > > > > Where I work I have the opposite issue. They have a lot of public IPv4 > > space and only use it internally never be advertised to the internet. > > Something I have never agreed With doing. > > Why? This is a perfectly legitimate use of the IP addresses. The purpose of > assigning addresses is so that they are unique WORLD WIDE in whatever > context you wish to use them in. I going to guess you were talking about the use internally of public IP addresses.. But there are rules governing what to use where. So it is OK to hoard publicly addressable IPv4 IP's for internal use that will never reach the outside world? No the way I have been taught. Maybe I just lack that big picture.. I think the big picture here is that they helped fund the development of IP and received large enough v4 allocations at the outset that they haven't had to use kludges like RFC1918 as much as most others have. It's not "hoarding" IPs if you're using them, whether or not you choose to advertise and make them accessible to other networks. It's the world everyone gets to live in with the current version of IP. Scott From bedard.phil at gmail.com Tue Dec 19 05:18:20 2017 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 19 Dec 2017 00:18:20 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <60D511B3-4EBE-4AAA-A3E0-068AD079BBAB@isc.org> References: <60D511B3-4EBE-4AAA-A3E0-068AD079BBAB@isc.org> Message-ID: I’m pretty sure Comcast, along with most other MSOs in NA, use squat space for various endpoints because they have run out of public and private IPv4 space. Everyone obviously wants to get to all IPv6 but there are millions of end devices and other gear they speak to which do not support it. For the most part I think they try to re-use space and use the transition space when they can, but some deployed squat space before that came about or it’s simply not enough. Phil On 12/18/17, 3:36 PM, "NANOG on behalf of Mark Andrews" wrote: Companies like COMCAST did. They manage the modems over IPv6. They also supported DS-Lite’s development as a transition mechanism so they wouldn’t have to run IPv4 to their customers. They wanted to be able to go IPv6 only. That meant having IPv4 as a service available. -- Mark Andrews > On 19 Dec 2017, at 06:34, Harald Koch wrote: > >> On 17 December 2017 at 17:48, Tom Carter wrote: >> >> RFC1918 isn't big enough to cover all use cases. Think about a large >> internet service providers. If you have ten million customers, 10.0.0.0/8 >> would be enough to number modems, but what happens when you need to number >> video set top boxes and voice end points? I don't think anyone goes out and >> says "Lets go use someone else's space, because I don't want to use this >> perfectly good private space". >> > > :cough: > > They could use IPv6. I mean, if the mobile phone companies can figure it > out, surely an ISP can... > > -- > Harald From yang.yu.list at gmail.com Tue Dec 19 07:54:02 2017 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 19 Dec 2017 00:54:02 -0700 Subject: historic SWIP (or rwhois) data? In-Reply-To: <20171218171101.2eade002@go.imp.ch> References: <20171218171101.2eade002@go.imp.ch> Message-ID: APNIC has whowas also https://www.apnic.net/static/whowas-ui/ For RWhois, check with the organization operating rwhoisd? They might have the information beyond RWhois. Yang On Mon, Dec 18, 2017 at 9:11 AM, Benoit Panizzon wrote: > Well @ RIPE ist is quite simple to query historical data: > > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/types-of-queries/16-12-historical-queries > > I don't know if other registries offer similar services. > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G - Leiter Commerce Kunden > ______________________________________________________ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 Pratteln Fax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > ______________________________________________________ From Jason_Livingood at comcast.com Tue Dec 19 15:39:26 2017 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Tue, 19 Dec 2017 15:39:26 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" wrote: > They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can... Except for cases when it is impossible or impractical to update software on a great number of legacy devices… JL From jbothe at me.com Tue Dec 19 16:16:51 2017 From: jbothe at me.com (JASON BOTHE) Date: Tue, 19 Dec 2017 10:16:51 -0600 Subject: Geolocate data for allocated blocks Message-ID: I am seeking assistance in getting nets I’ve allocated (several months ago) to an office in another RIR region to properly update its geolocate data. In this particular case, I have a net in use in India, but currently reflects Houston as its address although the allocation indicates otherwise. Any databases I should contact or other info is appreciated. Cheers! Jason From magicsata at gmail.com Tue Dec 19 16:29:48 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Tue, 19 Dec 2017 16:29:48 +0000 Subject: Geolocate data for allocated blocks In-Reply-To: References: Message-ID: Most places are using Maxmind for their GeoIP. You can ask them to update the database here: https://support.maxmind.com/geoip-data-correction-request/ It takes about a month in my experience to see results. Make sure the data in whois is also up to date for your blocks. On Tue, Dec 19, 2017 at 4:16 PM, JASON BOTHE wrote: > > > I am seeking assistance in getting nets I’ve allocated (several months > ago) to an office in another RIR region to properly update its geolocate > data. In this particular case, I have a net in use in India, but currently > reflects Houston as its address although the allocation indicates > otherwise. Any databases I should contact or other info is appreciated. > > Cheers! > > Jason > > > From baldur.norddahl at gmail.com Tue Dec 19 16:38:12 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 19 Dec 2017 17:38:12 +0100 Subject: Multi lane optics Message-ID: <8038b469-bc89-8b89-b716-7130991022ed@gmail.com> Hello, Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load balanced between those lanes? Is it bit by bit or more like LACP (packet by packet)? I need to make sure my solution will handle 10G streams correctly. We have a problem with N x 10G and LACP because our L2VPN MPLS endpoints are lacking the flow label support. If I sell a 10G circuit to a customer and uses a L2VPN to transport his port, everything may go on the same sub channel. LACP will not load balance correctly, because it only sees the outer MAC address for hashing, which is the same for all packets. Now we are worried that multi lane optics might have the exact same problem. Regards, Baldur From tyler at tgconrad.com Tue Dec 19 16:45:30 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Tue, 19 Dec 2017 08:45:30 -0800 Subject: Multi lane optics In-Reply-To: <8038b469-bc89-8b89-b716-7130991022ed@gmail.com> References: <8038b469-bc89-8b89-b716-7130991022ed@gmail.com> Message-ID: This blog has a pretty good runthrough - http://fmad.io/blog-100g-ethernet.html Scroll down to "100G PROTOCOLS". On Tue, Dec 19, 2017 at 8:38 AM, Baldur Norddahl wrote: > Hello, > > Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G > = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load > balanced between those lanes? Is it bit by bit or more like LACP (packet by > packet)? > > I need to make sure my solution will handle 10G streams correctly. We have > a problem with N x 10G and LACP because our L2VPN MPLS endpoints are > lacking the flow label support. If I sell a 10G circuit to a customer and > uses a L2VPN to transport his port, everything may go on the same sub > channel. LACP will not load balance correctly, because it only sees the > outer MAC address for hashing, which is the same for all packets. > > Now we are worried that multi lane optics might have the exact same > problem. > > Regards, > > Baldur > > From joelja at bogus.com Tue Dec 19 17:13:11 2017 From: joelja at bogus.com (joel jaeggli) Date: Tue, 19 Dec 2017 09:13:11 -0800 Subject: Multi lane optics In-Reply-To: References: <8038b469-bc89-8b89-b716-7130991022ed@gmail.com> Message-ID: On 12/19/17 08:45, Tyler Conrad wrote: > This blog has a pretty good runthrough - > http://fmad.io/blog-100g-ethernet.html > > Scroll down to "100G PROTOCOLS". > > On Tue, Dec 19, 2017 at 8:38 AM, Baldur Norddahl > wrote: > >> Hello, >> >> Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G >> = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load >> balanced between those lanes? Is it bit by bit or more like LACP (packet by >> packet)? >> >> I need to make sure my solution will handle 10G streams correctly. We have >> a problem with N x 10G and LACP because our L2VPN MPLS endpoints are >> lacking the flow label support. If I sell a 10G circuit to a customer and >> uses a L2VPN to transport his port, everything may go on the same sub >> channel. LACP will not load balance correctly, because it only sees the >> outer MAC address for hashing, which is the same for all packets. >> >> Now we are worried that multi lane optics might have the exact same >> problem. 100G frames are striped across the 4 x 25G lanes either with or without fec. That operates as one link from the vantage point of the ethernet frame. The fec (reed solomon coding generally) offers protection against bit errors at the expense of some latency. >> Regards, >> >> Baldur >> >> > From rod.beck at unitedcablecompany.com Tue Dec 19 17:31:57 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 19 Dec 2017 17:31:57 +0000 Subject: Eurofiber Contact Message-ID: Please contact me ASAP concerning Amsterdam DF. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From sabri at cluecentral.net Tue Dec 19 18:24:45 2017 From: sabri at cluecentral.net (Sabri Berisha) Date: Tue, 19 Dec 2017 10:24:45 -0800 (PST) Subject: 40G and 100G optics options In-Reply-To: <648a5a1a-9db6-d218-c529-8175beabc37e@nordu.net> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> <648a5a1a-9db6-d218-c529-8175beabc37e@nordu.net> Message-ID: <1970053774.29986.1513707885381.JavaMail.zimbra@cluecentral.net> ----- On Dec 18, 2017, at 9:49 AM, Fredrik Korsbäck hugge at nordu.net wrote: > This is the "failure" of us (the business) choosing QSFP as the de-factor > formfactor for 100G, there is not power in > that cage to make 10km+ optics in an easy way. If we would have pushed for CFP4 > as the "last" formfactor in 100G land we > would be much better off. How about OSFP? The OSFP MSA has a large number of backers, including Juniper, Arista, Finisar and Google. It's the vendors that chose to go for QSFP due to the density options in a single RU chassis. Thanks, Sabri From hugge at nordu.net Tue Dec 19 19:30:19 2017 From: hugge at nordu.net (=?utf-8?Q?Fredrik_Korsb=C3=A4ck?=) Date: Tue, 19 Dec 2017 20:30:19 +0100 Subject: 40G and 100G optics options In-Reply-To: <1970053774.29986.1513707885381.JavaMail.zimbra@cluecentral.net> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> <648a5a1a-9db6-d218-c529-8175beabc37e@nordu.net> <1970053774.29986.1513707885381.JavaMail.zimbra@cluecentral.net> Message-ID: <77080CE8-E1E3-4A6C-A912-6AD85FA926EE@nordu.net> > 19 dec. 2017 kl. 19:24 skrev Sabri Berisha : > > ----- On Dec 18, 2017, at 9:49 AM, Fredrik Korsbäck hugge at nordu.net wrote: > >> This is the "failure" of us (the business) choosing QSFP as the de-factor >> formfactor for 100G, there is not power in >> that cage to make 10km+ optics in an easy way. If we would have pushed for CFP4 >> as the "last" formfactor in 100G land we >> would be much better off. > > How about OSFP? The OSFP MSA has a large number of backers, including Juniper, Arista, Finisar and Google. Yes, on OSFP we have the possbility of making this right again for 400G. It will not have the same backward compability as QSFP-DD and not the same faceplate density (but close enough i would say). But in return we would most likely see longrange optics MUCH earlier in the lifecycle of 400G > > It's the vendors that chose to go for QSFP due to the density options in a single RU chassis. > > Thanks, > > Sabri From joelja at bogus.com Tue Dec 19 19:38:32 2017 From: joelja at bogus.com (joel jaeggli) Date: Tue, 19 Dec 2017 11:38:32 -0800 Subject: 40G and 100G optics options In-Reply-To: <1970053774.29986.1513707885381.JavaMail.zimbra@cluecentral.net> References: <2287c16f-1ed0-ee6e-cff9-9d75dd23cd96@gmail.com> <648a5a1a-9db6-d218-c529-8175beabc37e@nordu.net> <1970053774.29986.1513707885381.JavaMail.zimbra@cluecentral.net> Message-ID: On 12/19/17 10:24, Sabri Berisha wrote: > ----- On Dec 18, 2017, at 9:49 AM, Fredrik Korsbäck hugge at nordu.net wrote: > >> This is the "failure" of us (the business) choosing QSFP as the de-factor >> formfactor for 100G, there is not power in >> that cage to make 10km+ optics in an easy way. If we would have pushed for CFP4 >> as the "last" formfactor in 100G land we >> would be much better off. > How about OSFP? The OSFP MSA has a large number of backers, including Juniper, Arista, Finisar and Google. > > It's the vendors that chose to go for QSFP due to the density options in a single RU chassis. osfp is potentially 540W in the front panel of a 1ru switch which poses it's own engineering challenges. > > Thanks, > > Sabri > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From ITG at itechgeek.com Tue Dec 19 19:56:58 2017 From: ITG at itechgeek.com (ITechGeek) Date: Tue, 19 Dec 2017 14:56:58 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: While a single network gets at /64, isn't the practice suppose to be providers allocating a /56 or a /60 for home users (you know so your IOT, wired lan, wifi, guest network, gaming systems, bathroom, bedroom, etc. can all be on their own networks)? ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) | ITG at ITechGeek.Com https://keybase.io/itechgeek | https://itg.nu/ Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Dec 18, 2017 at 6:09 PM, William Herrin wrote: > On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke > wrote: > > > some fun examples of the size of ipv6: > > > > https://samsclass.info/ipv6/exhaustion-2016.htm > > > > https://www.reddit.com/r/theydidthemath/comments/ > > 2qxgxw/self_just_how_big_is_ipv6/ > > > Hi Eric, > > Lies, damn lies and statistics. Both projections assume that IPv6 addresses > are assigned the same way we assign IPv4 addresses. They are not. > > There are several practices which consume IPv6 at a drastically higher rate > than IPv4. The most notable is the assignment of a /64 to every LAN. Your > /26 LAN that used to consume 2^6th IP addresses? Now it's 2^64th. Used to > consume RFC1918 addresses? Now it's 2^64th of the global IPv6 addresses. > > Why did we need a /64 for each LAN? So we could incorporate the Ethernet > MAC address in to the IP address. Only we can't actually do that because it > turns out to be crazy insecure. Nevertheless, the 3 computers in your > basement will still consume 2^64th IPv6 addresses between them. But hey, > what's 20 orders of magnitude between friends. > > We have ISPs that have received allocations of entire /19s. A /19 in IPv6 > is exactly the same percentage of the total address space as a /19 in IPv4. > Before considering reserved addresses, it's 1/2^19th of the total address > space. For a single ISP. Think about it. > > Meanwhile the IETF has learned nothing from the gargantuan waste that is > 224.0.0.0/4 ($2billion at current prices). They went and assigned > FC00::/7. > /7!! Almost 1% of the IPv6 address space gone in a single RFC. > > I haven't attempted to compute the actual rate of IPv6 consumption but it's > not inconceivable that we could exhaust them by the end of the century > through sheer ineptitude. > > On the plus side, we're mostly only screwing around with 2000::/3 right > now. After we burn through that in the next 20 years, we can if we so > desire change the rules for how (and how quickly) we use 4000::/3. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From bill at herrin.us Tue Dec 19 20:55:49 2017 From: bill at herrin.us (William Herrin) Date: Tue, 19 Dec 2017 15:55:49 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Tue, Dec 19, 2017 at 2:56 PM, ITechGeek wrote: > While a single network gets at /64, isn't the practice suppose to be > providers allocating a /56 or a /60 for home users (you know so your IOT, > wired lan, wifi, guest network, gaming systems, bathroom, bedroom, etc. can > all be on their own networks)? > Yes, that's what it's _supposed_ to be. Anything from a /48 to a /60 is reasonable given the way IPv6 is intended to be used. My personal preference is /56 by default, /48 by request. Providers assigning a single /64 or a /128 to an always-on customer are doing it wrong. You know who you are. If this seems inconsistent with my last email, my key point there was not that we're using IPv6 in a crazy way (although to some extent we are) but rather that the IPv6 address space is by tens of orders of magnitude much smaller than you think. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bryan at shout.net Tue Dec 19 21:07:40 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 19 Dec 2017 15:07:40 -0600 Subject: Geolocate data for allocated blocks In-Reply-To: References: Message-ID: <39bb5975-f666-bb6c-da3f-8050d5b34631@shout.net> https://www.iplocation.net/ ... is pretty comprehensive. Includes Maxmind and others ... On 12/19/17 10:29 AM, Alistair Mackenzie wrote: > Most places are using Maxmind for their GeoIP. You can ask them to update > the database here: > https://support.maxmind.com/geoip-data-correction-request/ > It takes about a month in my experience to see results. > > Make sure the data in whois is also up to date for your blocks. > > On Tue, Dec 19, 2017 at 4:16 PM, JASON BOTHE wrote: > >> >> >> I am seeking assistance in getting nets I’ve allocated (several months >> ago) to an office in another RIR region to properly update its geolocate >> data. In this particular case, I have a net in use in India, but currently >> reflects Houston as its address although the allocation indicates >> otherwise. Any databases I should contact or other info is appreciated. >> >> Cheers! >> >> Jason >> >> >> From UpTide at live.com Tue Dec 19 20:18:57 2017 From: UpTide at live.com (UpTide .) Date: Tue, 19 Dec 2017 20:18:57 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> , Message-ID: If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 (16777216) times larger; but if we start doing something crazy like allocating a /48 or /56 that number plummets. (256 times larger, and 65536 times larger respectfully.) But then again I'm bad with math, maybe not? While a single network gets at /64, isn't the practice suppose to be providers allocating a /56 or a /60 for home users (you know so your IOT, wired lan, wifi, guest network, gaming systems, bathroom, bedroom, etc. can all be on their own networks)? From gtaylor at tnetconsulting.net Tue Dec 19 22:03:19 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 19 Dec 2017 15:03:19 -0700 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On 12/19/2017 01:55 PM, William Herrin wrote: > Providers assigning a single /64 or a /128 to an always-on customer are > doing it wrong. You know who you are. The cable ISP that I had (prior to moving) assigned a single /64 for the outside of the router. I could also request provider delegation for something that I could use internally breaking into multiple /64s. I just don't remember if it was a /56 or /60. The point being that the outside of the SOHO router and the inside PD were two different DHCP processes, both of which needed to happen. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From fkittred at gwi.net Tue Dec 19 02:09:37 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 18 Dec 2017 21:09:37 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <30F19719-F268-44B6-AE4A-9B326A596C4A@pedantictheory.com> <4630F576-B342-4907-8BBE-983E1308E81B@isc.org> Message-ID: On Mon, Dec 18, 2017 at 4:09 PM, Scott Morizot wrote: > > I think the big picture here is that they helped fund the development of IP > and received > large enough v4 allocations at the outset that they haven't had to use > kludges like RFC1918 Um, sorry but as an old timer and a former employee of the company that owned 10/8 and returned it back to the address pool...who is it you are claiming "helped fund the development of IP?" -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From joe.carroll at telplicity.com Tue Dec 19 20:05:22 2017 From: joe.carroll at telplicity.com (Joe Carroll) Date: Tue, 19 Dec 2017 15:05:22 -0500 Subject: MSN/Azure Message-ID: Anyone have a clueful contact at Azure/MSN? We have a block of recently acquired address space being filtered. From phiber at phiber.org Tue Dec 19 19:17:44 2017 From: phiber at phiber.org (Christopher Rogers) Date: Tue, 19 Dec 2017 11:17:44 -0800 Subject: contact for WCGDB routing registry? Message-ID: Does anyone have a contact for the WCGDB RR? They've got an invalid object registered that is being mirrored to other providers, but I am unable to find any working poc. Also why is wcg.com running an RR that's being mirrored by t1s to begin with? (changed had wcg.com email addr.) cheers -chris From job at ntt.net Tue Dec 19 22:18:20 2017 From: job at ntt.net (Job Snijders) Date: Tue, 19 Dec 2017 22:18:20 +0000 Subject: a new source for authoritative routing data: ARIN WHOIS Message-ID: <20171219221820.GD4435@vurt.meerval.net> Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/ That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job at vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" route: 204.209.252.0/23 descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job at ntt.net 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job From chkuhtz at microsoft.com Tue Dec 19 22:20:30 2017 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 19 Dec 2017 22:20:30 +0000 Subject: MSN/Azure In-Reply-To: References: Message-ID: Joe, Happy to help get you to the right person. Please reply direct with details. Thanks, Christian From: Joe Carroll Sent: Tuesday, December 19, 2:14 PM Subject: MSN/Azure To: nanog at nanog.org Anyone have a clueful contact at Azure/MSN? We have a block of recently acquired address space being filtered. From bryan at shout.net Tue Dec 19 23:03:36 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 19 Dec 2017 17:03:36 -0600 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: Comcast, at least in my neck of the woods, hands out /56s. On 12/19/17 4:03 PM, Grant Taylor via NANOG wrote: > On 12/19/2017 01:55 PM, William Herrin wrote: >> Providers assigning a single /64 or a /128 to an always-on customer are >> doing it wrong. You know who you are. > > The cable ISP that I had (prior to moving) assigned a single /64 for the > outside of the router.  I could also request provider delegation for > something that I could use internally breaking into multiple /64s.  I > just don't remember if it was a /56 or /60. > > The point being that the outside of the SOHO router and the inside PD > were two different DHCP processes, both of which needed to happen. > > > From sean at donelan.com Tue Dec 19 23:10:57 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 19 Dec 2017 18:10:57 -0500 (EST) Subject: Final Reminder to Re-Register DMCA Agents in Electronic System Message-ID: The U.S. Copyright Office has been moving DMCA registration from paper forms to an online registration system. All previously filed paper DMCA agent registration forms expire on December 31, 2017. U.S. ISPs and non-US ISPs doing business in the United States should have re-registered using the online DMCA electronic registration. If you've neglected to register using the online system, you have until December 31, 2017. https://www.copyright.gov/newsnet/2017/694.html From owen at delong.com Wed Dec 20 01:50:56 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Dec 2017 17:50:56 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> > On Dec 19, 2017, at 07:39 , Livingood, Jason wrote: > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" wrote: >> They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can... > > Except for cases when it is impossible or impractical to update software on a great number of legacy devices… > > JL > > Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism. Owen From valdis.kletnieks at vt.edu Wed Dec 20 02:22:12 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 19 Dec 2017 21:22:12 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> , Message-ID: <29891.1513736532@turing-police.cc.vt.edu> On Tue, 19 Dec 2017 20:18:57 +0000, "UpTide ." said: > If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 > (16777216) times larger; but if we start doing something crazy like allocating > a /48 or /56 that number plummets. (256 times larger, and 65536 times larger > respectfully.) You seem to have missed an entire octet's worth of bits, so off by a factor of 256... A /48 is 16 more bits than a /32, so 65536 times bigger. A /56 is 24 more bits than a /32, so 16777216 times bigger. And a /64 is 32 bits more than a /32... so.... Given that a /33 is just about enough to give everybody in the planet one, giving away 8 million times that many is going to be a challenge, unless somebody invents nanotech that wants a separate address for each nanomachine. But I'd argue that if I have personal nanotech, I *really* want to use ULA addresses. They're *my* nanotech. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Wed Dec 20 02:18:38 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 19 Dec 2017 20:18:38 -0600 (CST) Subject: Foundry FastIron Message-ID: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> A client of mine has some Foundry FastIron Edge X424HFs. Brocade and Extreme don't seem overly ambitious to help. Anyone have any documentation they can scrounge up? SFP compatibility list? The ones I see in there already look substantially like the ones I get from FiberStore, but that doesn't mean much. Do they still sell support on these? I'm largely just interested in newer firmware for them. I don't think they were updated since they left the factory and there are a few quirks I'm hoping they addressed at some point. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From valdis.kletnieks at vt.edu Wed Dec 20 02:28:53 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 19 Dec 2017 21:28:53 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <30648.1513736933@turing-police.cc.vt.edu> On Tue, 19 Dec 2017 17:03:36 -0600, Bryan Holloway said: > Comcast, at least in my neck of the woods, hands out /56s. Hmm. Odd. Around here, they're handing out /60s. Which is OK, since I'm living in a 3 bedroom apartment that can be covered by one router. If I had to do downstream delegation to another router at the other end of a large house, I'd want a /56 so I can delegate a /60 to the far router so it could farm out / 64s, and I'd still have address space to carve /64's out of at the head-end router. (Actually, a /59 would allow that, but PD on non-nybble boundaries is just crazy talk ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Wed Dec 20 03:03:10 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 19 Dec 2017 21:03:10 -0600 (CST) Subject: IPSec SPI In-Reply-To: <2017500544.1589.1513738658642.JavaMail.mhammett@ThunderFuck> Message-ID: <1017163958.1595.1513738986363.JavaMail.mhammett@ThunderFuck> Is it possible for light packet loss (0.1% - 0.3%) to cause these errors: Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing. My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Wed Dec 20 03:09:10 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 19 Dec 2017 21:09:10 -0600 (CST) Subject: IPSec SPI In-Reply-To: <1017163958.1595.1513738986363.JavaMail.mhammett@ThunderFuck> References: <1017163958.1595.1513738986363.JavaMail.mhammett@ThunderFuck> Message-ID: <1259154177.1608.1513739348208.JavaMail.mhammett@ThunderFuck> Note: I'm working on figuring out the cause of the packet loss regardless of their position. I would just like them to solve their problem if it isn't me. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Tuesday, December 19, 2017 9:03:10 PM Subject: IPSec SPI Is it possible for light packet loss (0.1% - 0.3%) to cause these errors: Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing. My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From marka at isc.org Wed Dec 20 04:52:15 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 20 Dec 2017 15:52:15 +1100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: > On 20 Dec 2017, at 2:39 am, Livingood, Jason wrote: > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" wrote: >> They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can... > > Except for cases when it is impossible or impractical to update software on a great number of legacy devices… > > JL You mean devices where the manufacture ignore IPv6 and shipped you a dud. Even devices with a 15 year life cycle should be IPv6 capable today. Microsoft shipped IPv6 capable versions of Windows in 2001. If they could see the writing on the wall back then *every* other device manufacture should have also been able to see this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hank at efes.iucc.ac.il Wed Dec 20 06:21:42 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 20 Dec 2017 08:21:42 +0200 Subject: a new source for authoritative routing data: ARIN WHOIS In-Reply-To: <20171219221820.GD4435@vurt.meerval.net> References: <20171219221820.GD4435@vurt.meerval.net> Message-ID: <912fc677-5de1-4daf-eabd-039402419ecb@efes.iucc.ac.il> On 20/12/2017 00:18, Job Snijders wrote: Wow!  This is great!  I have just started using it and will need to set aside a swath of time to delve deeper into this. Regards, Hank > Dear NANOG, > > I'd like to share an update on some routing security activities that > ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG > Foundation, and the arouteserver project have been collaborating on. > Quite some puzzles pieces were brought together! :) > > Traditionally, there are two commonly-used methods to signal to your > peers or upstream providers what Origin ASN(s) are allowed to originate > a given IP prefix. As an operator, you can either create a "route > object" in the IRR, or you can compose a Letter Of Agency (LOA) and send > that to your upstream providerfor manual verification. > > When it comes to manual verification of routing data (such a LOA), one > of the big questions is "what data source is actually authoritative for > the verification?". In the ARIN registry the so-called "OriginAS" > attribute can be used for this purpose. The OriginAS attribute can only > be set or modified by authorized accounts (such as the holder of the IP > space). This makes the OriginAS attribute a very reliable source of > truth! ARIN shared some notes on LOAs & OriginAS in the following article: > https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/ > > That teamarin posting got me thinking: clearly there is a lot of > valuable routing information in the ARIN WHOIS registry. What if we make > the process such that you don't have to email in a LOA, and, have the > recipient verify it against against the web interface output (which you > updated before sending in the LOA). What if the prefix-filter generation > software could just programmatically fetch all (CIDR, OriginAS) tuples > from the ARIN WHOIS registry and load that into the list of prefixes a > customer is allowed to announce. Just like we do with IRR objects! > > A few weeks ago I approached John Curran from ARIN asking whether we > could work out a mechanism to somehow obtain a computer parsable > rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path > forward turned out to be an agreement between the NLNOG Foundation and > ARIN, which authorises NLNOG to publish a subset of the bulk whois data > in the convenient format (JSON) for operational purposes. The ARIN WHOIS > (CIDR, OriginAS) tuples can be downloaded in JSON format here: > http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 > > Because of the JSON dump, the ARIN WHOIS data can now be easily consumed > by software programs. For example, the JSON file is now loaded into IRR > Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 > You can see the 'arin-whois' column which lists what ASN(s) are > authorized to announce the blocks (this, in addition to what is signaled > in IRR or RPKI). > > The novel thing here is that JSON file not only allows you to look up an > OriginAS using the IP prefix as a lookup key, but the reverse can now > also be done: lookup what IP prefixes an ASN is allowed to originate > (based on ARIN WHOIS data). > > Deployment Experience YYCIX: > > At this point you may be wondering - what does any of the above have to > do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) > or a python-based IXP Route Server management software from Italian > origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) > > As an experiment to explore real world use of the ARIN WHOIS data and > prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo > de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source > in the prefix filter generation process governing the YYCIX route > servers. The YYCIX route servers see roughly 80,000 prefixes. > > The results are fantastic: ~ 1,700 IPv4 prefixes that were previously > rejected by the YYCIX route servers (because no IRR route object > exists), are now accepted because those announcements can be verified > against data from ARIN's WHOIS registry. This resolved roughly 23% of > invalid path announcements sent to the YYCIX route servers. > > Deployment Experience NTT: > > Based on the above positive results, starting today, NTT is also > accepting ARIN WHOIS OriginAS information in conjunction with IRR route > objects. Our implementation fetches the ARIN WHOIS data, transforms it > into RPSL format, and imports it into our IRRd instance at rr.ntt.net as > IRR objects. This way we don't need to update our toolchain to make use > of this new data source. An example is here: > > job at vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" > route: 204.209.252.0/23 > descr: NET-204-209-252-0-1 > origin: AS22512 > remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. > remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 > remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. > mnt-by: MAINT-JOB > changed: job at ntt.net 20090220 > source: ARIN-WHOIS > > NTT also observed a substantial number (similar to YYCIX) of BGP > announcements from its customers that were previously rejected because > of the lack of an IRR object, but now are validated via ARIN WHOIS. > > Conclusion: > > It is great to be able to offer network operators a choice: either > register your BGP announcements as route objects in RPSL format in IRR, > or use the ARIN WHOIS web interface, (or both) - either way, as IP > transit carrier, we can now pick up your attestations in an automated > fashion. This which improves accuracy and reduces red tape! :) > > Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source > in their automation toolchain. The code & procedures to make use of this > source are open. I'm happy to help you both on-list and off-list. > > Kind regards, > > Job > From nanog at ics-il.net Wed Dec 20 12:09:06 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Dec 2017 06:09:06 -0600 (CST) Subject: a new source for authoritative routing data: ARIN WHOIS In-Reply-To: <20171219221820.GD4435@vurt.meerval.net> References: <20171219221820.GD4435@vurt.meerval.net> Message-ID: <864964471.1870.1513771743887.JavaMail.mhammett@ThunderFuck> Shall we meet again, I owe you a beer. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: nanog at nanog.org Sent: Tuesday, December 19, 2017 4:18:20 PM Subject: a new source for authoritative routing data: ARIN WHOIS Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/ That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job at vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" route: 204.209.252.0/23 descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job at ntt.net 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job From denys at visp.net.lb Wed Dec 20 14:55:51 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 20 Dec 2017 16:55:51 +0200 Subject: Bandwidth distribution per ip Message-ID: National operator here ask customers to distribute bandwidth between all ip's equally, e.g. if i have /22, and i have in it CDN from one of the big content providers, this CDN use only 3 ips for ingress bandwidth, so bandwidth distribution is not equal between ips and i am not able to use all my bandwidth. And for me, it sounds like faulty aggregation + shaping setup, for example, i heard once if i do policing on some models of Cisco switch, on an aggregated interface, if it has 4 interfaces it will install 25% policer on each interface and if hashing is done by dst ip only, i will face such issue, but that is old and cheap model, as i recall. Did anybody in the world face such requirements? Is such requirements can be considered as legit? From SNaslund at medline.com Wed Dec 20 15:07:40 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 20 Dec 2017 15:07:40 +0000 Subject: Bandwidth distribution per ip In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA62505@MUNPRDMBXA1.medline.com> That seems completely unworkable to me. I would think most environment are going to have heavy hitting devices like firewalls and servers that cause traffic aggregation points in the networks. If they shape on their customer's uplink port I don't see why the individual addresses matter at all. I've never heard of that one. As far as policing on an aggregated interface it would seem to be better to police at a different point where all of the traffic for a given customer can be policed together regardless of the physical port it is received on. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces+snaslund=medline.com at nanog.org] On Behalf Of Denys Fedoryshchenko >Sent: Wednesday, December 20, 2017 8:56 AM >To: nanog at nanog.org >Subject: Bandwidth distribution per ip > >National operator here ask customers to distribute bandwidth between all ip's equally, e.g. if i have /22, and i have in it CDN from one of the big content providers, this CDN use only 3 ips for ingress bandwidth, so bandwidth >distribution is not equal between ips and i am not able to use all my bandwidth. > >And for me, it sounds like faulty aggregation + shaping setup, for example, i heard once if i do policing on some models of Cisco switch, on an aggregated interface, if it has 4 interfaces it will install 25% policer on each >interface and if hashing is done by dst ip only, i will face such issue, but that is old and cheap model, as i recall. > >Did anybody in the world face such requirements? >Is such requirements can be considered as legit? From SNaslund at medline.com Wed Dec 20 15:19:28 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 20 Dec 2017 15:19:28 +0000 Subject: IPSec SPI In-Reply-To: <1017163958.1595.1513738986363.JavaMail.mhammett@ThunderFuck> References: <2017500544.1589.1513738658642.JavaMail.mhammett@ThunderFuck> <1017163958.1595.1513738986363.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4027EA6251F@MUNPRDMBXA1.medline.com> It is definitely possible. The invalid SPI indicates that the device received a packet for which is does not have a valid SA. It is normal during a crypto rekey when the traffic was sent on an older or newer SA than the receiving device. It all depends how often it is happening. A couple a day would probably just be normal operation. If they are very often it could be a code bug or packet loss causing loss of crypto sync between devices. I would first ask how often and next ask if they have dead peer detection enabled. Not having dead peer detection can cause this condition to go on for much longer than necessary. Note that Cisco limits the messages to one per minute to avoid DoS attacks. Which brings up another point, are you sure that the traffic causing the messages is sourced from a peer they should actually be talking with? You would get the same message if I sent IPsec encrypted traffic to them and I am not configured as a peer. If it was working and just now started happening it is probably packet loss or a bug. I would also suggest a reboot on the devices to make sure that this is not a low mem condition which also causes these once in a while on our devices. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >Sent: Tuesday, December 19, 2017 9:03 PM >To: NANOG list >Subject: IPSec SPI > >Is it possible for light packet loss (0.1% - 0.3%) to cause these errors: > >Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %>CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4->RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 > > >I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing. > >My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss. >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From saku at ytti.fi Wed Dec 20 15:52:46 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 20 Dec 2017 17:52:46 +0200 Subject: Bandwidth distribution per ip In-Reply-To: References: Message-ID: On 20 December 2017 at 16:55, Denys Fedoryshchenko wrote: > And for me, it sounds like faulty aggregation + shaping setup, for example, > i heard once if i do policing on some models of Cisco switch, on an > aggregated interface, if it has 4 interfaces it will install 25% policer on > each interface and if hashing is done by dst ip only, i will face such > issue, but that is old and cheap model, as i recall. One such old and cheap model is ASR9k trident, typhoon and tomahawk. It's actually pretty demanding problem, as technically two linecards or even just ports sitting on two different NPU might as well be different routers, they don't have good way to communicate to each other on BW use. So N policer being installed as N/member_count per link is very typical. ECMP is fact of life, and even thought none if any provider document that they have per-flow limitations which are lower than nominal rate of connection you purchases, these do exist almost universally everywhere. People who are most likely to see these limits are people who tunnel everything, so that everything from their say 10Gbps is single flow, from POV of the network. In IPv6 world at least tunnel encap end could write hash to IPv6 flow label, allowing core potentially to balance tunneled traffic, unless tunnel itself guarantees order. I don't think it's fair for operator to demand equal bandwidth per IP, but you will expose yourself to more problems if you do not have sufficient entropy. We are slowly getting solutions to this, Juniper Trio and BRCM Tomahawk3 can detect elephant flows and dynamically unequally map hash results to physical ports to alleviate the problem. -- ++ytti From denys at visp.net.lb Wed Dec 20 17:04:46 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 20 Dec 2017 19:04:46 +0200 Subject: Bandwidth distribution per ip In-Reply-To: References: Message-ID: <442a112d54a872695a16c6636be22a8d@visp.net.lb> On 2017-12-20 17:52, Saku Ytti wrote: > On 20 December 2017 at 16:55, Denys Fedoryshchenko > wrote: > >> And for me, it sounds like faulty aggregation + shaping setup, for >> example, >> i heard once if i do policing on some models of Cisco switch, on an >> aggregated interface, if it has 4 interfaces it will install 25% >> policer on >> each interface and if hashing is done by dst ip only, i will face such >> issue, but that is old and cheap model, as i recall. > > One such old and cheap model is ASR9k trident, typhoon and tomahawk. > > It's actually pretty demanding problem, as technically two linecards > or even just ports sitting on two different NPU might as well be > different routers, they don't have good way to communicate to each > other on BW use. So N policer being installed as N/member_count per > link is very typical. > > ECMP is fact of life, and even thought none if any provider document > that they have per-flow limitations which are lower than nominal rate > of connection you purchases, these do exist almost universally > everywhere. People who are most likely to see these limits are people > who tunnel everything, so that everything from their say 10Gbps is > single flow, from POV of the network. > In IPv6 world at least tunnel encap end could write hash to IPv6 flow > label, allowing core potentially to balance tunneled traffic, unless > tunnel itself guarantees order. > > I don't think it's fair for operator to demand equal bandwidth per IP, > but you will expose yourself to more problems if you do not have > sufficient entropy. We are slowly getting solutions to this, Juniper > Trio and BRCM Tomahawk3 can detect elephant flows and dynamically > unequally map hash results to physical ports to alleviate the problem. As person who is in love with embedded systems development, i just watched today beautiful 10s of meters long 199x machine, where multi kW VFDs manage huge motors(not steppers), dragging synchronously and printing on thin paper with crazy speed and all they have is long ~9600 link between a bunch of encoders and PLC dinosaur managing all this beauty. If any of them will apply a bit wrong torque, stretched paper will rip apart. In fact nothing complex there, and technology is ancient these days. Engineers who cannot synchronize and update few virtual "subinstances" policing ratio based on feedback, in one tiny, expensive box, with reasonable update ratio, having in hands modern technologies, maybe incompetent? National operator doesn't provide IPv6, that's one of the problems. In most of cases there is no tunnels, but imperfection still exist. When ISP pays ~$150k/month (bandwidth very expensive here), and because CDN has 3 units & 3 ingress ips, and carrier have bonding somewhere over 4 links, it just means ~$37.5k is lost in rough estimations, no sane person will accept that. Sometimes one CDN unit are in maintenance, and 2 existing can perfectly serve demand, but because of this "balancing" issues - it just go down, as half of capacity missing. But, tunnels in rare cases true too, but what we can do, if they don't have reasonable DDoS protection tools all world have (not even blackholing). Many DDoS-protection operators charge extra for more tunnel endpoints with balancing, and this balancing is not so equal as well (same src+dst ip at best). And when i did round-robin on my own solution, i noticed except this "bandwidth distribution" issue, latency on each ip is unequal, so RR create for me "out of order" issues. Another problem, most popular services in region (in matters of bandwidth) is facebook, whatsapp, youtube. Most of them is big fat flows running over few ips. I doubt i can convince them to balance over more. From saku at ytti.fi Wed Dec 20 17:12:19 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 20 Dec 2017 19:12:19 +0200 Subject: Bandwidth distribution per ip In-Reply-To: <442a112d54a872695a16c6636be22a8d@visp.net.lb> References: <442a112d54a872695a16c6636be22a8d@visp.net.lb> Message-ID: On 20 December 2017 at 19:04, Denys Fedoryshchenko wrote: > As person who is in love with embedded systems development, i just watched > today beautiful 10s of meters long 199x machine, where multi kW VFDs manage > huge motors(not steppers), dragging synchronously and printing on thin paper > with crazy speed and all they have is long ~9600 link between a bunch of > encoders > and PLC dinosaur managing all this beauty. If any of them will apply a bit > wrong > torque, stretched paper will rip apart. > In fact nothing complex there, and technology is ancient these days. > Engineers who cannot synchronize and update few virtual "subinstances" > policing ratio based on feedback, in one tiny, expensive box, with > reasonable > update ratio, having in hands modern technologies, maybe incompetent? As appealing it is to say everyone, present company excluded, is incompetent, I think explanation is more complex than that. Solution has to be economic and marketable. I think elephant flow detection and unequal mapping of hash result to physical interface is economic and marketable solution, but it needs that extra level of abstraction, i.e. you cannot just backport it via software if hardware is missing that sort of capability. -- ++ytti From blake at ispn.net Wed Dec 20 17:16:29 2017 From: blake at ispn.net (Blake Hudson) Date: Wed, 20 Dec 2017 11:16:29 -0600 Subject: Bandwidth distribution per ip In-Reply-To: References: Message-ID: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> Denys Fedoryshchenko wrote on 12/20/2017 8:55 AM: > National operator here ask customers to distribute bandwidth between > all ip's equally, e.g. if i have /22, and i have in it CDN from one of > the big content providers, this CDN use only 3 ips for ingress > bandwidth, so bandwidth distribution is not equal between ips and i am > not able to use all my bandwidth. > > And for me, it sounds like faulty aggregation + shaping setup, for > example, i heard once if i do policing on some models of Cisco switch, > on an aggregated interface, if it has 4 interfaces it will install 25% > policer on each interface and if hashing is done by dst ip only, i > will face such issue, but that is old and cheap model, as i recall. > > Did anybody in the world face such requirements? > Is such requirements can be considered as legit? Not being able to use all of your bandwidth is a common issue if you are provided a bonded connection (aka Link Aggregation Group). For example, you are provided a 4Gbps service over 4x1Gbps ethernet links. Ethernet traffic is not typically balanced across links per frame, because this could lead to out of order delivery or jitter, especially in cases where the links have different physical characteristics. Instead, a hashing algorithm is typically used to distribute traffic based on flows. This results in each flow having consistent packet order and latency characteristics, but does force a flow over a single link, resulting in the flow being limited to the performance of that link. In this context, flows can be based on src/dst MAC address, IP address, or TCP/UDP port information, depending on the traffic type (some IP traffic is not TCP/UDP and won't have a port) and equipment type (layer 3 devices typically hash by layer 3 or 4 info). Your operator may be able to choose an alternative hashing algorithm that could work better for you (hashing based on layer 4 information instead of layer 3 or 2, for example). This is highly dependent on your provider's equipment and configuration - it may be a global option on the equipment or may not be an option at all. Bottom line, if you expected 4Gbps performance for each host on your network, you're unlikely to get it on service delivered through 4x 1Gbps links. 10Gbps+ links between you and your ISP's peers would better serve those needs (any 1Gbps bonds in the path between you and your provider's edge are likely to exhibit the same characteristics). --Blake From denys at visp.net.lb Wed Dec 20 17:42:17 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 20 Dec 2017 19:42:17 +0200 Subject: Bandwidth distribution per ip In-Reply-To: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> References: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> Message-ID: <577650667dc0020075aabcd0fddd9c49@visp.net.lb> On 2017-12-20 19:16, Blake Hudson wrote: > Denys Fedoryshchenko wrote on 12/20/2017 8:55 AM: >> National operator here ask customers to distribute bandwidth between >> all ip's equally, e.g. if i have /22, and i have in it CDN from one of >> the big content providers, this CDN use only 3 ips for ingress >> bandwidth, so bandwidth distribution is not equal between ips and i am >> not able to use all my bandwidth. >> >> And for me, it sounds like faulty aggregation + shaping setup, for >> example, i heard once if i do policing on some models of Cisco switch, >> on an aggregated interface, if it has 4 interfaces it will install 25% >> policer on each interface and if hashing is done by dst ip only, i >> will face such issue, but that is old and cheap model, as i recall. >> >> Did anybody in the world face such requirements? >> Is such requirements can be considered as legit? > > Not being able to use all of your bandwidth is a common issue if you > are provided a bonded connection (aka Link Aggregation Group). For > example, you are provided a 4Gbps service over 4x1Gbps ethernet links. > Ethernet traffic is not typically balanced across links per frame, > because this could lead to out of order delivery or jitter, especially > in cases where the links have different physical characteristics. > Instead, a hashing algorithm is typically used to distribute traffic > based on flows. This results in each flow having consistent packet > order and latency characteristics, but does force a flow over a single > link, resulting in the flow being limited to the performance of that > link. In this context, flows can be based on src/dst MAC address, IP > address, or TCP/UDP port information, depending on the traffic type > (some IP traffic is not TCP/UDP and won't have a port) and equipment > type (layer 3 devices typically hash by layer 3 or 4 info). > > Your operator may be able to choose an alternative hashing algorithm > that could work better for you (hashing based on layer 4 information > instead of layer 3 or 2, for example). This is highly dependent on > your provider's equipment and configuration - it may be a global > option on the equipment or may not be an option at all. Bottom line, > if you expected 4Gbps performance for each host on your network, > you're unlikely to get it on service delivered through 4x 1Gbps links. > 10Gbps+ links between you and your ISP's peers would better serve > those needs (any 1Gbps bonds in the path between you and your > provider's edge are likely to exhibit the same characteristics). > > --Blake No bonding to me, usually it is dedicated 1G/10G/etc link. Also i simulated this bandwidth for "hashability", and any layer4 aware hashing on cisco/juniper provided perfectly balanced bandwidth distribution. On my tests i can see that they have some balancing clearly by dst ip only. From nanog at antiphase.net Tue Dec 19 22:19:52 2017 From: nanog at antiphase.net (Anthony Newman) Date: Tue, 19 Dec 2017 14:19:52 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <398a124e-ba54-ada0-8be5-3f184f2bd7a6@antiphase.net> On 2017-12-19 12:18 PM, UpTide . wrote: > If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 (16777216) times larger; but if we start doing something crazy like allocating a /48 or /56 that number plummets. (256 times larger, and 65536 times larger respectfully.) > > But then again I'm bad with math, maybe not? You most certainly are. There are (2^32)*(2^32) in 2^64, meaning everyone who has a /32 of IPv4 would get about 4 billion /64s if we chopped it all up the same way. Or 65536 /48s, or 16777216 /56s. I think the argument is not that there isn't enough address space to go around; more that profligate allocations to begin with may restrict future options on a century-scale timeline. From michael at wi-fiber.io Wed Dec 20 02:05:16 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 19 Dec 2017 19:05:16 -0700 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: +1 for Nat64. dual stack is just keeping ipv4 around longer than it needs to be On 19 December 2017 at 18:50, Owen DeLong wrote: > > > On Dec 19, 2017, at 07:39 , Livingood, Jason < > Jason_Livingood at comcast.com> wrote: > > > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < > nanog-bounces at nanog.org on behalf of chk at pobox.com> wrote: > >> They could use IPv6. I mean, if the mobile phone companies can figure > it out, surely an ISP can... > > > > Except for cases when it is impossible or impractical to update software > on a great number of legacy devices… > > > > JL > > > > > Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism. > > Owen > > From neal.rauhauser at gmail.com Wed Dec 20 10:24:21 2017 From: neal.rauhauser at gmail.com (Neal Rauhauser) Date: Wed, 20 Dec 2017 02:24:21 -0800 Subject: historic SWIP (or rwhois) data? In-Reply-To: References: <20171218171101.2eade002@go.imp.ch> Message-ID: An interesting answer to this problem: whois --list-versions w.x.y.z/prefix - gotta know the object size, so some hunt & peck might be needed. And for the princely sum of $45/mo this site seems to have all sorts of info, and an API, but mysteriously there is no Maltego transform yet. https://myip.ms/ On Mon, Dec 18, 2017 at 11:54 PM, Yang Yu wrote: > APNIC has whowas also > https://www.apnic.net/static/whowas-ui/ > > For RWhois, check with the organization operating rwhoisd? They might > have the information beyond RWhois. > > > Yang > > On Mon, Dec 18, 2017 at 9:11 AM, Benoit Panizzon > wrote: > > Well @ RIPE ist is quite simple to query historical data: > > > > https://www.ripe.net/manage-ips-and-asns/db/support/ > documentation/ripe-database-documentation/types-of- > queries/16-12-historical-queries > > > > I don't know if other registries offer similar services. > > > > Mit freundlichen Grüssen > > > > -Benoît Panizzon- > > -- > > I m p r o W a r e A G - Leiter Commerce Kunden > > ______________________________________________________ > > > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > > CH-4133 Pratteln Fax +41 61 826 93 01 > > Schweiz Web http://www.imp.ch > > ______________________________________________________ > From blake at ispn.net Wed Dec 20 17:45:08 2017 From: blake at ispn.net (Blake Hudson) Date: Wed, 20 Dec 2017 11:45:08 -0600 Subject: Bandwidth distribution per ip In-Reply-To: References: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> Message-ID: <4941dcd5-2b92-0c11-d090-31f707abf6d4@ispn.net> Denys Fedoryshchenko wrote on 12/20/2017 11:38 AM: > On 2017-12-20 19:16, Blake Hudson wrote: >> Denys Fedoryshchenko wrote on 12/20/2017 8:55 AM: >>> National operator here ask customers to distribute bandwidth between >>> all ip's equally, e.g. if i have /22, and i have in it CDN from one >>> of the big content providers, this CDN use only 3 ips for ingress >>> bandwidth, so bandwidth distribution is not equal between ips and i >>> am not able to use all my bandwidth. >>> >>> And for me, it sounds like faulty aggregation + shaping setup, for >>> example, i heard once if i do policing on some models of Cisco >>> switch, on an aggregated interface, if it has 4 interfaces it will >>> install 25% policer on each interface and if hashing is done by dst >>> ip only, i will face such issue, but that is old and cheap model, as >>> i recall. >>> >>> Did anybody in the world face such requirements? >>> Is such requirements can be considered as legit? >> >> Not being able to use all of your bandwidth is a common issue if you >> are provided a bonded connection (aka Link Aggregation Group). For >> example, you are provided a 4Gbps service over 4x1Gbps ethernet links. >> Ethernet traffic is not typically balanced across links per frame, >> because this could lead to out of order delivery or jitter, especially >> in cases where the links have different physical characteristics. >> Instead, a hashing algorithm is typically used to distribute traffic >> based on flows. This results in each flow having consistent packet >> order and latency characteristics, but does force a flow over a single >> link, resulting in the flow being limited to the performance of that >> link. In this context, flows can be based on src/dst MAC address, IP >> address, or TCP/UDP port information, depending on the traffic type >> (some IP traffic is not TCP/UDP and won't have a port) and equipment >> type (layer 3 devices typically hash by layer 3 or 4 info). >> >> Your operator may be able to choose an alternative hashing algorithm >> that could work better for you (hashing based on layer 4 information >> instead of layer 3 or 2, for example). This is highly dependent on >> your provider's equipment and configuration - it may be a global >> option on the equipment or may not be an option at all. Bottom line, >> if you expected 4Gbps performance for each host on your network, >> you're unlikely to get it on service delivered through 4x 1Gbps links. >> 10Gbps+ links between you and your ISP's peers would better serve >> those needs (any 1Gbps bonds in the path between you and your >> provider's edge are likely to exhibit the same characteristics). >> >> --Blake > > No bonding to me, usually it is dedicated 1G/10G/etc link. > Also i simulated this bandwidth for "hashability", and any layer4 > aware hashing > on cisco/juniper provided perfectly balanced bandwidth distribution. > On my tests i can see that they have some balancing clearly by dst ip > only. > Are you claiming that your bandwidth is being equally divided 1024 ways (you mentioned a /22) or just that each host (IP) is not receiving the full bandwidth? What is the bandwidth ordered and what is the bandwidth you're seeing per host(IP)? From oliver.oboyle at gmail.com Wed Dec 20 17:56:08 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 20 Dec 2017 12:56:08 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: Agreed. There now. We need cheap, open source, options for widespread adoption. Oliver On Dec 20, 2017 12:51, "Michael Crapse" wrote: > +1 for Nat64. dual stack is just keeping ipv4 around longer than it needs > to be > > On 19 December 2017 at 18:50, Owen DeLong wrote: > > > > > > On Dec 19, 2017, at 07:39 , Livingood, Jason < > > Jason_Livingood at comcast.com> wrote: > > > > > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < > > nanog-bounces at nanog.org on behalf of chk at pobox.com> wrote: > > >> They could use IPv6. I mean, if the mobile phone companies can figure > > it out, surely an ISP can... > > > > > > Except for cases when it is impossible or impractical to update > software > > on a great number of legacy devices… > > > > > > JL > > > > > > > > Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism. > > > > Owen > > > > > From denys at visp.net.lb Wed Dec 20 18:07:31 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 20 Dec 2017 20:07:31 +0200 Subject: Bandwidth distribution per ip In-Reply-To: References: <442a112d54a872695a16c6636be22a8d@visp.net.lb> Message-ID: <2555be5e8ff077b41d1be873ecdda332@visp.net.lb> On 2017-12-20 19:12, Saku Ytti wrote: > On 20 December 2017 at 19:04, Denys Fedoryshchenko > wrote: > >> As person who is in love with embedded systems development, i just >> watched >> today beautiful 10s of meters long 199x machine, where multi kW VFDs >> manage >> huge motors(not steppers), dragging synchronously and printing on thin >> paper >> with crazy speed and all they have is long ~9600 link between a bunch >> of >> encoders >> and PLC dinosaur managing all this beauty. If any of them will apply a >> bit >> wrong >> torque, stretched paper will rip apart. >> In fact nothing complex there, and technology is ancient these days. >> Engineers who cannot synchronize and update few virtual "subinstances" >> policing ratio based on feedback, in one tiny, expensive box, with >> reasonable >> update ratio, having in hands modern technologies, maybe incompetent? > > As appealing it is to say everyone, present company excluded, is > incompetent, I think explanation is more complex than that. Solution > has to be economic and marketable. I think elephant flow detection and > unequal mapping of hash result to physical interface is economic and > marketable solution, but it needs that extra level of abstraction, > i.e. you cannot just backport it via software if hardware is missing > that sort of capability. Even highly incompetent in such matters person as me, know, that some of modern architecture challenges is when NPU consists of a large number of "processing cores", each having his own counters, and additionally it might be also multiple NPU handling same customer traffic. On such conditions updating _precise_ counters(for bitrate measurements, for example) is not trivial anymore as sum = a(1) + .. + a(n), due synchronization, shared resources access and etc. But still it's solvable in most of cases, even dead wrong way of running script and changing policer value on each "unit" once per second mostly solve problem. And if architecturally some NPU cannot do such job, it means they are flawed, and should be avoided for specific tasks, same as some BCM chipset switches with claimed 32k macs, but choking from 20k macs, because of 8192 entries tcam and probably imperfect hash + linear probing on collision. Sure such switch is not suitable for aggregation and termination. Still, i am running some dedicated servers on colo in EU/US, some over 10G(bonding), and _single_ ip on server, i never faced such balancing issues, thats why i am asking, if someone had such carrier, who require to balance bandwidth between many ips, with quite high precision, to not lose expensive bandwidth. From mike-nanog at tiedyenetworks.com Wed Dec 20 18:23:57 2017 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 20 Dec 2017 10:23:57 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ > Every time I see these "Look how many more addresses we have now with IPv6", I just shake my head.   Yes, the address space is very large. But, all of the protocols, all of the addressing guides, all of the operational 'best practices', ALL OF IT, increases by orders of magnitude the amount of waste along with it. Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. So, the actual waste is dilutes the actual implementable size of the total ipv6 address space due to the waste component. And I have not yet seen any study or even proposed theory to explore what the IPv6 Internet would look like, if used in place of all IPv4 in all the places and ways that it's used. I think, in time, we will discover that we have only increased our usable ip space by no more than 2 orders of magnitude over that which is achieved in ipv4, and we will be looking again at a global ip protocol upgrade I bet within my lifetime. While we are at it, why is nobody thinking or talking about the looming exhaustion of ieee OUI addresses? Network cards made 15 years ago and since consigned to the electronics scrap heap in the sky, take with them their addresses never to be reused again (unless you are a freak like me and keep some for 'positively never assigned anywhere'). And old dead companies that were assigned OUIs, they get 24 bits of address space to take to their graves. We should be re-thinking mac addressing altogether too. (Please no hate mail, these opinions are strictly mine...) Mike- From denys at visp.net.lb Wed Dec 20 18:34:39 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 20 Dec 2017 20:34:39 +0200 Subject: Bandwidth distribution per ip In-Reply-To: <4941dcd5-2b92-0c11-d090-31f707abf6d4@ispn.net> References: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> <4941dcd5-2b92-0c11-d090-31f707abf6d4@ispn.net> Message-ID: <7f48297a0dedb344cd684687c9ef13b7@nuclearcat.com> <> > > Are you claiming that your bandwidth is being equally divided 1024 > ways (you mentioned a /22) or just that each host (IP) is not > receiving the full bandwidth? What is the bandwidth ordered and what > is the bandwidth you're seeing per host(IP)? Some facts from today. Ordered capacity 3.3Gbit Received capacity ~2.1Gbit if they apply bandwidth limit In this example they removed limit, but you can have approximate picture how bandwidth is distributed (top 20 ips): [x.x.x.14 ] 22433902b 36435p avg 615b 0.81%b 1.10%p 26596 Kbit/s [x.x.x.13 ] 22715108b 34887p avg 651b 0.82%b 1.06%p 26929 Kbit/s [x.x.x.10 ] 22741911b 31719p avg 716b 0.83%b 0.96%p 26961 Kbit/s [x.x.x.11 ] 23874482b 34157p avg 698b 0.87%b 1.04%p 28304 Kbit/s [x.x.x.15 ] 24393258b 29622p avg 823b 0.89%b 0.90%p 28919 Kbit/s [x.x.x.12 ] 24715746b 33880p avg 729b 0.90%b 1.03%p 29301 Kbit/s [x.x.x.9 ] 25720774b 36000p avg 714b 0.93%b 1.09%p 30492 Kbit/s [x.x.x.8 ] 29599218b 40647p avg 728b 1.07%b 1.23%p 35090 Kbit/s [y.y.y.122 ] 52015361b 52743p avg 986b 1.89%b 1.60%p 61666 Kbit/s [y.y.y.116 ] 52161788b 55435p avg 940b 1.89%b 1.68%p 61839 Kbit/s [y.y.y.114 ] 55409677b 56945p avg 973b 2.01%b 1.73%p 65690 Kbit/s [y.y.y.120 ] 59971853b 59782p avg 1003b 2.18%b 1.81%p 71098 Kbit/s [y.y.y.126 ] 60821991b 65184p avg 933b 2.21%b 1.98%p 72106 Kbit/s [y.y.y.117 ] 61811624b 58374p avg 1058b 2.24%b 1.77%p 73279 Kbit/s [y.y.y.113 ] 62492070b 63001p avg 991b 2.27%b 1.91%p 74086 Kbit/s [y.y.y.119 ] 63128246b 63545p avg 993b 2.29%b 1.93%p 74840 Kbit/s [y.y.y.121 ] 64392950b 66418p avg 969b 2.34%b 2.01%p 76340 Kbit/s [y.y.y.115 ] 65723751b 64100p avg 1025b 2.39%b 1.94%p 77917 Kbit/s [y.y.y.124 ] 66646572b 62637p avg 1064b 2.42%b 1.90%p 79011 Kbit/s [y.y.y.123 ] 70332553b 68284p avg 1030b 2.55%b 2.07%p 83381 Kbit/s [y.y.y.125 ] 70545386b 67441p avg 1046b 2.56%b 2.04%p 83634 Kbit/s [y.y.y.118 ] 71393238b 69490p avg 1027b 2.59%b 2.11%p 84639 Kbit/s [x.x.x.6 ] 123028709b 137530p avg 894b 4.47%b 4.17%p 145855 Kbit/s [x.x.x.4 ] 124816100b 137221p avg 909b 4.53%b 4.16%p 147974 Kbit/s [x.x.x.7 ] 126130939b 143443p avg 879b 4.58%b 4.35%p 149532 Kbit/s [x.x.x.3 ] 128316371b 139360p avg 920b 4.66%b 4.22%p 152123 Kbit/s [x.x.x.0 ] 132445418b 143143p avg 925b 4.81%b 4.34%p 157018 Kbit/s [x.x.x.1 ] 133197094b 143713p avg 926b 4.84%b 4.35%p 157910 Kbit/s [x.x.x.2 ] 135346483b 146510p avg 923b 4.91%b 4.44%p 160458 Kbit/s [x.x.x.5 ] 135366769b 147766p avg 916b 4.92%b 4.48%p 160482 Kbit/s Average packet size 834 (with ethernet header, max avg sz 1514) Time 6748, total bytes 2753819139, total speed 3188235 Kbit/s As you can see max single ip takes is 4.48% of bandwidth. Also i cannot waste ipv4 for larger pools, just because of some deadly flawed equipment/configuration. From mel at beckman.org Wed Dec 20 18:48:25 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 20 Dec 2017 18:48:25 +0000 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude. Using a /64 for P2P links is no problem, really. Worrying about that is like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea. There’s plenty, and until we colonize Alpha Centauri Bb, there will continue to be plenty :) They’re just integers, after all. -mel > On Dec 20, 2017, at 10:23 AM, Mike wrote: > > On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >> some fun examples of the size of ipv6: >> >> https://samsclass.info/ipv6/exhaustion-2016.htm >> >> https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ >> > > > Every time I see these "Look how many more addresses we have now with > IPv6", I just shake my head. > > Yes, the address space is very large. But, all of the protocols, all > of the addressing guides, all of the operational 'best practices', ALL > OF IT, increases by orders of magnitude the amount of waste along with > it. Call this the 'shavings', in IPv4 for example, when you assign a P2P > link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > due to ping-pong and just so many technical manuals and other advices, > you are told to "just use a /64' for your point to points. So, the > actual waste is dilutes the actual implementable size of the total ipv6 > address space due to the waste component. And I have not yet seen any > study or even proposed theory to explore what the IPv6 Internet would > look like, if used in place of all IPv4 in all the places and ways that > it's used. I think, in time, we will discover that we have only > increased our usable ip space by no more than 2 orders of magnitude over > that which is achieved in ipv4, and we will be looking again at a global > ip protocol upgrade I bet within my lifetime. While we are at it, why is > nobody thinking or talking about the looming exhaustion of ieee OUI > addresses? Network cards made 15 years ago and since consigned to the > electronics scrap heap in the sky, take with them their addresses never > to be reused again (unless you are a freak like me and keep some for > 'positively never assigned anywhere'). And old dead companies that were > assigned OUIs, they get 24 bits of address space to take to their > graves. We should be re-thinking mac addressing altogether too. > > (Please no hate mail, these opinions are strictly mine...) > > Mike- > From saku at ytti.fi Wed Dec 20 18:51:31 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 20 Dec 2017 20:51:31 +0200 Subject: Bandwidth distribution per ip In-Reply-To: <7f48297a0dedb344cd684687c9ef13b7@nuclearcat.com> References: <561ce1c4-401e-f45b-9702-c81868451e76@ispn.net> <4941dcd5-2b92-0c11-d090-31f707abf6d4@ispn.net> <7f48297a0dedb344cd684687c9ef13b7@nuclearcat.com> Message-ID: On 20 December 2017 at 20:34, Denys Fedoryshchenko wrote: > As you can see max single ip takes is 4.48% of bandwidth. > Also i cannot waste ipv4 for larger pools, just because of some deadly > flawed equipment/configuration. This indeed sounds unacceptable. I would suspect intentional per-prefix policing, intended for broadband subscriber interfaces. -- ++ytti From chk at pobox.com Wed Dec 20 18:55:40 2017 From: chk at pobox.com (Harald Koch) Date: Wed, 20 Dec 2017 13:55:40 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On 20 December 2017 at 13:23, Mike wrote: > in IPv4 for example, when you assign a P2P > link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > due to ping-pong and just so many technical manuals and other advices, > you are told to "just use a /64' for your point to points. There are 2^64 *networks* available in IPv6. That's 2^32 times as many *networks* as there are IPv4 *addresses*. That doesn't mean twice as many; that means almost 4.3 BILLION times as many. Yeah, go ahead and use a /64 for your point-to-point networks. Or don't; there are ways to use /128s carved out of a single /64 (I do so on my private VPNs), and then route the whole /64 to my VPN concentrator). -- Harald From lee at asgard.org Wed Dec 20 19:00:03 2017 From: lee at asgard.org (Lee Howard) Date: Wed, 20 Dec 2017 14:00:03 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: Message-ID: On 12/19/17, 11:52 PM, "NANOG on behalf of Mark Andrews" wrote: > >> On 20 Dec 2017, at 2:39 am, Livingood, Jason >> wrote: >> >> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" >> wrote: >>> They could use IPv6. I mean, if the mobile phone companies can figure >>>it out, surely an ISP can... >> >> Except for cases when it is impossible or impractical to update >>software on a great number of legacy devices… >> >> JL > >You mean devices where the manufacture ignore IPv6 and shipped you a dud. > Even devices with a 15 year life cycle should be IPv6 capable today. “should” doesn’t buy developer cycles, especially for EOL products or from bankrupt vendors. You deal with the network you have, upgrade what you can, and replace the rest as fast as you can while doing what it takes to stay in business. Lee From aaron1 at gvtc.com Wed Dec 20 19:01:05 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 20 Dec 2017 13:01:05 -0600 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <000001d379c4$e3693470$aa3b9d50$@gvtc.com> Sounds prophetic... we will see ... or our (x)grandchildren will see... Yeah, if you give me a billion dollars, and I buy something for 1 million dollars every day for the next ~3 years, at the end of those 3 years, I would have no more, ... money-space :| I wonder if the 20 bit mpls label will be re-thought down the road also ? -Aaron From aaron1 at gvtc.com Wed Dec 20 19:03:49 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 20 Dec 2017 13:03:49 -0600 Subject: Waste will kill ipv6 too References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <000201d379c5$4508f710$cf1ae530$@gvtc.com> Maybe my analogy of "billion" doesn’t correctly compare to 2^128 ip addresses -Aaron From lee at asgard.org Wed Dec 20 18:57:46 2017 From: lee at asgard.org (Lee Howard) Date: Wed, 20 Dec 2017 13:57:46 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: On 12/19/17, 8:50 PM, "NANOG on behalf of Owen DeLong" wrote: > >> On Dec 19, 2017, at 07:39 , Livingood, Jason >> wrote: >> >> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" >> wrote: >>> They could use IPv6. I mean, if the mobile phone companies can figure >>>it out, surely an ISP can... >> >> Except for cases when it is impossible or impractical to update >>software on a great number of legacy devices… >> >> JL >> >> >Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism. I’m a fan of IPv6-only plus translation, but not in this case. If I have a functioning management network that’s mostly in IPv6 and partly in rfc1918 space (or even squatted space), I don’t get much out of NAT64. Renumbering the servers that actually touch/manage devices gets, what, a /29 of IPv4 addresses? Better to focus on evolving to whatever will replace those legacy devices. Lee > >Owen > > From saku at ytti.fi Wed Dec 20 19:17:12 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 20 Dec 2017 21:17:12 +0200 Subject: Waste will kill ipv6 too In-Reply-To: <000001d379c4$e3693470$aa3b9d50$@gvtc.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <000001d379c4$e3693470$aa3b9d50$@gvtc.com> Message-ID: On 20 December 2017 at 21:01, Aaron Gould wrote: > I wonder if the 20 bit mpls label will be re-thought down the road also ? No comment to the IPv6 discussion. But size of MPLS label is consideration, and we do spend two labels for one thing, partly due to size limit, partly due to the lack of expressiveness of MPLS label wire-format. Examples of such things are ELI and Extension Label. There are more and more consumers for MPLS labels, and canonical implementation (label manager) gives each consumer own dedicated block, this alone makes 20b less than arbitrarily large. -- ++ytti From lee at asgard.org Wed Dec 20 19:16:24 2017 From: lee at asgard.org (Lee Howard) Date: Wed, 20 Dec 2017 14:16:24 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On 12/20/17, 1:23 PM, "NANOG on behalf of Mike" wrote: >On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >> some fun examples of the size of ipv6: >> >> https://samsclass.info/ipv6/exhaustion-2016.htm >> >> >>https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big >>_is_ipv6/ >> > > >Every time I see these "Look how many more addresses we have now with >IPv6", I just shake my head. > > Yes, the address space is very large. But, all of the protocols, all >of the addressing guides, all of the operational 'best practices', ALL >OF IT, increases by orders of magnitude the amount of waste along with >it. Call this the 'shavings', in IPv4 for example, when you assign a P2P >link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >due to ping-pong and just so many technical manuals and other advices, >you are told to "just use a /64' for your point to points. So, the >actual waste is dilutes the actual implementable size of the total ipv6 >address space due to the waste component. And I have not yet seen any >study or even proposed theory to explore what the IPv6 Internet would >look like, if used in place of all IPv4 in all the places and ways that Okay, so do the thought experiment. Let’s say 10 billion people in the world. Let’s say each of them has 10 devices, each with a /64, and to be ridiculous, each with a p2p link to the others, so we have 100 /64 per person. That’s 1 trillion /64s. Oh, dear, I’ve used up the first /27 of IPv6 space. What if we try giving ten /48s to each of 10 billion people, one for each of the ten providers they’ll have? Sure, I’m handwaving the p2p links, but that’s why we assign that /48. That’s 100 billion /48s, which is something like a /11. I’ve tried several times to come up with a scenario that leads to depletion in less than 200 years, and I haven’t managed it. Can you do it? > why is >nobody thinking or talking about the looming exhaustion of ieee OUI >addresses? > Network cards made 15 years ago and since consigned to the >electronics scrap heap in the sky, take with them their addresses never >to be reused again (unless you are a freak like me and keep some for >'positively never assigned anywhere'). And old dead companies that were >assigned OUIs, they get 24 bits of address space to take to their >graves. We should be re-thinking mac addressing altogether too. Like EUI-64? https://standards.ieee.org/develop/regauth/tut/eui.pdf Lee From jordi.palet at consulintel.es Wed Dec 20 19:18:51 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 20 Dec 2017 20:18:51 +0100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <28ED8D73-BEC5-4107-90A5-BBEC1BDF0903@consulintel.es> This may be helpful: https://www.ripe.net/publications/docs/ripe-690/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Mike Responder a: Fecha: miércoles, 20 de diciembre de 2017, 19:26 Para: Asunto: Waste will kill ipv6 too On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ > Every time I see these "Look how many more addresses we have now with IPv6", I just shake my head. Yes, the address space is very large. But, all of the protocols, all of the addressing guides, all of the operational 'best practices', ALL OF IT, increases by orders of magnitude the amount of waste along with it. Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. So, the actual waste is dilutes the actual implementable size of the total ipv6 address space due to the waste component. And I have not yet seen any study or even proposed theory to explore what the IPv6 Internet would look like, if used in place of all IPv4 in all the places and ways that it's used. I think, in time, we will discover that we have only increased our usable ip space by no more than 2 orders of magnitude over that which is achieved in ipv4, and we will be looking again at a global ip protocol upgrade I bet within my lifetime. While we are at it, why is nobody thinking or talking about the looming exhaustion of ieee OUI addresses? Network cards made 15 years ago and since consigned to the electronics scrap heap in the sky, take with them their addresses never to be reused again (unless you are a freak like me and keep some for 'positively never assigned anywhere'). And old dead companies that were assigned OUIs, they get 24 bits of address space to take to their graves. We should be re-thinking mac addressing altogether too. (Please no hate mail, these opinions are strictly mine...) Mike- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From blake at ispn.net Wed Dec 20 19:23:05 2017 From: blake at ispn.net (Blake Hudson) Date: Wed, 20 Dec 2017 13:23:05 -0600 Subject: Bandwidth distribution per ip In-Reply-To: <2555be5e8ff077b41d1be873ecdda332@visp.net.lb> References: <442a112d54a872695a16c6636be22a8d@visp.net.lb> <2555be5e8ff077b41d1be873ecdda332@visp.net.lb> Message-ID: <60bfc313-d0f9-1fdc-2cc3-f95345d3a0ca@ispn.net> Denys Fedoryshchenko wrote on 12/20/2017 12:07 PM: > Still, i am running some dedicated servers on colo in EU/US, some over > 10G(bonding), > and _single_ ip on server, i never faced such balancing issues, thats > why i am asking, > if someone had such carrier, who require to balance bandwidth between > many ips, > with quite high precision, to not lose expensive bandwidth. I have not heard of this. We typically purchase a connection and bring our own IP space. The capacity of the connection and the number of IP addresses (if any) are unrelated to each other. That said, I would find a bonded ethernet connection acceptable in some applications. Bonded ethernet generally works well to increase aggregate bandwidth when used by multiple hosts whose individual bandwidth is well below the speed of each link in the bond. With few hosts, bonded ethernet connections are not likely to work well to increase bandwidth and would generally be unsuitable for providing connectivity to a single IP/host. From jordi.palet at consulintel.es Wed Dec 20 19:31:13 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 20 Dec 2017 20:31:13 +0100 Subject: Waste will kill ipv6 too In-Reply-To: <28ED8D73-BEC5-4107-90A5-BBEC1BDF0903@consulintel.es> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <28ED8D73-BEC5-4107-90A5-BBEC1BDF0903@consulintel.es> Message-ID: This may be useful as well, somehow related, as using /64 has a clear advantage: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de JORDI PALET MARTINEZ Responder a: Fecha: miércoles, 20 de diciembre de 2017, 20:26 Para: Asunto: Re: Waste will kill ipv6 too This may be helpful: https://www.ripe.net/publications/docs/ripe-690/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Mike Responder a: Fecha: miércoles, 20 de diciembre de 2017, 19:26 Para: Asunto: Waste will kill ipv6 too On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is_ipv6/ > Every time I see these "Look how many more addresses we have now with IPv6", I just shake my head. Yes, the address space is very large. But, all of the protocols, all of the addressing guides, all of the operational 'best practices', ALL OF IT, increases by orders of magnitude the amount of waste along with it. Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. So, the actual waste is dilutes the actual implementable size of the total ipv6 address space due to the waste component. And I have not yet seen any study or even proposed theory to explore what the IPv6 Internet would look like, if used in place of all IPv4 in all the places and ways that it's used. I think, in time, we will discover that we have only increased our usable ip space by no more than 2 orders of magnitude over that which is achieved in ipv4, and we will be looking again at a global ip protocol upgrade I bet within my lifetime. While we are at it, why is nobody thinking or talking about the looming exhaustion of ieee OUI addresses? Network cards made 15 years ago and since consigned to the electronics scrap heap in the sky, take with them their addresses never to be reused again (unless you are a freak like me and keep some for 'positively never assigned anywhere'). And old dead companies that were assigned OUIs, they get 24 bits of address space to take to their graves. We should be re-thinking mac addressing altogether too. (Please no hate mail, these opinions are strictly mine...) Mike- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From bill at herrin.us Wed Dec 20 20:57:27 2017 From: bill at herrin.us (William Herrin) Date: Wed, 20 Dec 2017 15:57:27 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> Message-ID: On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman wrote: > I won’t do the math for you, but you’re circumcising the mosquito here. We > didn’t just increase our usable space by 2 orders of magnitude. It’s > increased more than 35 orders of magnitude. > Hi Mel, The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces. Using a /64 for P2P links is no problem, really. Worrying about that is > like a scuba diver worrying about how many air molecules are surrounding > the boat on the way out to sea. > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lists at quux.de Wed Dec 20 21:12:27 2017 From: lists at quux.de (Jens Link) Date: Wed, 20 Dec 2017 22:12:27 +0100 Subject: Waste will kill ipv6 too In-Reply-To: (Lee Howard's message of "Wed, 20 Dec 2017 14:16:24 -0500") References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <87fu85je84.fsf@pc8.berlin.quux.de> Lee Howard writes: > I’ve tried several times to come up with a scenario that leads to > depletion in less than 200 years, and I haven’t managed it. Can you do it? Self replicating nano bots. Which will be a good thing (probably): https://xkcd.com/865/ SCNR Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From cb.list6 at gmail.com Wed Dec 20 21:17:23 2017 From: cb.list6 at gmail.com (Ca By) Date: Wed, 20 Dec 2017 21:17:23 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: On Wed, Dec 20, 2017 at 1:01 PM Oliver O'Boyle wrote: > Agreed. There now. We need cheap, open source, options for widespread > adoption. > http://jool.mx/en/index.html Free open source nat64 > Oliver > > On Dec 20, 2017 12:51, "Michael Crapse" wrote: > > > +1 for Nat64. dual stack is just keeping ipv4 around longer than it needs > > to be > > > > On 19 December 2017 at 18:50, Owen DeLong wrote: > > > > > > > > > On Dec 19, 2017, at 07:39 , Livingood, Jason < > > > Jason_Livingood at comcast.com> wrote: > > > > > > > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < > > > nanog-bounces at nanog.org on behalf of chk at pobox.com> wrote: > > > >> They could use IPv6. I mean, if the mobile phone companies can > figure > > > it out, surely an ISP can... > > > > > > > > Except for cases when it is impossible or impractical to update > > software > > > on a great number of legacy devices… > > > > > > > > JL > > > > > > > > > > > Yeah, in those cases, they should use IPv6 + NAT64 or similar > mechanism. > > > > > > Owen > > > > > > > > > From oliver.oboyle at gmail.com Wed Dec 20 21:24:28 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 20 Dec 2017 16:24:28 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: Excellent, thanks! Will dig into it. Oliver On Wed, Dec 20, 2017 at 4:17 PM, Ca By wrote: > > On Wed, Dec 20, 2017 at 1:01 PM Oliver O'Boyle > wrote: > >> Agreed. There now. We need cheap, open source, options for widespread >> adoption. >> > > http://jool.mx/en/index.html > > Free open source nat64 > > >> Oliver >> >> On Dec 20, 2017 12:51, "Michael Crapse" wrote: >> >> > +1 for Nat64. dual stack is just keeping ipv4 around longer than it >> needs >> > to be >> > >> > On 19 December 2017 at 18:50, Owen DeLong wrote: >> > >> > > >> > > > On Dec 19, 2017, at 07:39 , Livingood, Jason < >> > > Jason_Livingood at comcast.com> wrote: >> > > > >> > > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < >> > > nanog-bounces at nanog.org on behalf of chk at pobox.com> wrote: >> > > >> They could use IPv6. I mean, if the mobile phone companies can >> figure >> > > it out, surely an ISP can... >> > > > >> > > > Except for cases when it is impossible or impractical to update >> > software >> > > on a great number of legacy devices… >> > > > >> > > > JL >> > > > >> > > > >> > > Yeah, in those cases, they should use IPv6 + NAT64 or similar >> mechanism. >> > > >> > > Owen >> > > >> > > >> > >> > -- :o@> From eric.kuhnke at gmail.com Wed Dec 20 21:29:02 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 20 Dec 2017 13:29:02 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <87fu85je84.fsf@pc8.berlin.quux.de> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <87fu85je84.fsf@pc8.berlin.quux.de> Message-ID: I am trying to imagine the corporate boards of APNIC, RIPE and ARIN planning for a venn diagram overlap between a grey goo scenario, and fully automated ipv6 allocations... Just imagine the size of the RPKI backend! On Wed, Dec 20, 2017 at 1:12 PM, Jens Link wrote: > Lee Howard writes: > > > I’ve tried several times to come up with a scenario that leads to > > depletion in less than 200 years, and I haven’t managed it. Can you do > it? > > Self replicating nano bots. Which will be a good thing (probably): > > https://xkcd.com/865/ > > SCNR > > Jens > -- > ------------------------------------------------------------ > ---------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 > | > | http://blog.quux.de | jabber: jenslink at quux.de | > --------------- | > ------------------------------------------------------------ > ---------------- > From lists at silverlakeinternet.com Wed Dec 20 21:28:16 2017 From: lists at silverlakeinternet.com (lists at silverlakeinternet.com) Date: Wed, 20 Dec 2017 14:28:16 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> References: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> Message-ID: I could use a contact for all of these as well. I have been trying to get my subnet unblocked with all of these providers and have reached out in many ways to all of them over the past few months, but never get a response. Thank you, Brett A Mansfield On 2017-12-15 19:57, Mike Hammett wrote: > Bump for Hulu. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Michael Crapse" > To: nanog at nanog.org > Sent: Wednesday, December 6, 2017 3:38:20 PM > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others > > I am a local WISP. And my customers have trouble reaching Hulu, Disney > now, > and previously netflix and amazon prime(both resolved). > I have emailed, mailed, and called both HULU and Disney now to get my > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) > from > their services. They have replied saying it takes 3-5 days to resolve > the > issue, that was several weeks ago. Can i get contact from those two > services that can help my customers reach their services, thank you. > > > Thank you for the help. > -Michael From mel at beckman.org Wed Dec 20 21:38:51 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 20 Dec 2017 21:38:51 +0000 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org>, Message-ID: <3A6AF008-7967-4C15-BD88-06C787B93959@beckman.org> Bill, You are correct. As a double check, I divided 340282366920938463463374607431768211456 by 4294967296, getting 79228162514264337593543950336, which is 28.8 orders of magnitude :) -mel On Dec 20, 2017, at 12:58 PM, William Herrin > wrote: On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman > wrote: I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude. Hi Mel, The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces. Using a /64 for P2P links is no problem, really. Worrying about that is like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea. It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mel at beckman.org Wed Dec 20 21:46:24 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 20 Dec 2017 21:46:24 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <3A6AF008-7967-4C15-BD88-06C787B93959@beckman.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org>, , <3A6AF008-7967-4C15-BD88-06C787B93959@beckman.org> Message-ID: <749AFBCE-C6ED-4853-BD68-F8742210D6B0@beckman.org> And something in the message stream tried to convert my elegantly computed result into a phone number. Sigh. -mel > On Dec 20, 2017, at 1:39 PM, Mel Beckman wrote: > > [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > Bill, > > You are correct. > > As a double check, I divided 340282366920938463463374607431768211456 by 4294967296, getting 79228162514264337593543950336, which is 28.8 orders of magnitude :) > > -mel > > On Dec 20, 2017, at 12:58 PM, William Herrin > wrote: > > On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman > wrote: > I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude. > > Hi Mel, > > The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. > > There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces. > > > Using a /64 for P2P links is no problem, really. Worrying about that is like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea. > > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. > > Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From eric.kuhnke at gmail.com Wed Dec 20 21:57:03 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 20 Dec 2017 13:57:03 -0800 Subject: Bandwidth distribution per ip In-Reply-To: <60bfc313-d0f9-1fdc-2cc3-f95345d3a0ca@ispn.net> References: <442a112d54a872695a16c6636be22a8d@visp.net.lb> <2555be5e8ff077b41d1be873ecdda332@visp.net.lb> <60bfc313-d0f9-1fdc-2cc3-f95345d3a0ca@ispn.net> Message-ID: This is based on feedback from a colleague that spent several years in Lebanon and did a fair amount of research into the AS-adjacency paths in and out of the country, and the OSI layer 1 (submarine fiber to Cyprus, etc) paths... It sounds to me like your upstream carrier does not actually have any such limitation in place and is making a nonsensical excuse, intended for consumption by less technically savvy persons, as so why they're running their international transit connections too too close to full. International connectivity in and our of Beirut is quite costly on a $/Mbps basis. If you had the ability to see a traffic chart on one of their upstream connections I would not be surprised to see that they're running a 10GbE to, for example, telekom italia/sparkle at 87% utilization. On Wed, Dec 20, 2017 at 11:23 AM, Blake Hudson wrote: > > Denys Fedoryshchenko wrote on 12/20/2017 12:07 PM: > >> Still, i am running some dedicated servers on colo in EU/US, some over >> 10G(bonding), >> and _single_ ip on server, i never faced such balancing issues, thats why >> i am asking, >> if someone had such carrier, who require to balance bandwidth between >> many ips, >> with quite high precision, to not lose expensive bandwidth. >> > > I have not heard of this. We typically purchase a connection and bring our > own IP space. The capacity of the connection and the number of IP addresses > (if any) are unrelated to each other. > > That said, I would find a bonded ethernet connection acceptable in some > applications. Bonded ethernet generally works well to increase aggregate > bandwidth when used by multiple hosts whose individual bandwidth is well > below the speed of each link in the bond. With few hosts, bonded ethernet > connections are not likely to work well to increase bandwidth and would > generally be unsuitable for providing connectivity to a single IP/host. > From marka at isc.org Wed Dec 20 21:57:35 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Dec 2017 08:57:35 +1100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> Message-ID: <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> When the IETF decided on 128 bit addresses it was taking into consideration /80 sized subnet. Prior to that it was looking at a 64 bit address size and allocating addresses the IPv4 way with lots of variable sized networks. This was changed to /64 subnets to accomodate 64 bit MAC. After that there was discussion about how many subnet should be enough for 99.99% of sites which gave /48 per site using /64 sized network. That 281474976710656 sites or 35184372088832 out of the /3 we are currently allocating from. Now there are very few sites that need 65536 subnets and those that do can request additional /48’s. Now if you assume the earth’s population will get to 25B, and every person is a site, that still leaves 35159372088832 sites. And if each of those people also has a home and a vehicle, that still leaves 35109372088832 sites. Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. Mark > On 21 Dec 2017, at 7:57 am, William Herrin wrote: > > On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman wrote: > >> I won’t do the math for you, but you’re circumcising the mosquito here. We >> didn’t just increase our usable space by 2 orders of magnitude. It’s >> increased more than 35 orders of magnitude. >> > > Hi Mel, > > The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. > > There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of > magnitude." Orders of magnitude describes a difference between one thing > and another, in this case the IPv4 and IPv6 address spaces. > > > Using a /64 for P2P links is no problem, really. Worrying about that is >> like a scuba diver worrying about how many air molecules are surrounding >> the boat on the way out to sea. >> > > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders > of magnitude to just 9 orders of magnitude. Your link which needed at most > 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. > > Then we do /48s from which the /64s are assigned and we lose another 3 or > so orders of magnitude... Sparsely allocate those /48s for another order of > magnitude. From sparsely allocated ISP blocks for another order of > magnitude. It slips away faster than you might think. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lists at quux.de Wed Dec 20 22:33:09 2017 From: lists at quux.de (Jens Link) Date: Wed, 20 Dec 2017 23:33:09 +0100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: (Ca By's message of "Wed, 20 Dec 2017 21:17:23 +0000") References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> Message-ID: <87bmitjahm.fsf@pc8.berlin.quux.de> Ca By writes: > http://jool.mx/en/index.html > > Free open source nat64 And the DNS64 part can be done with powerdns (recursor), unbound, bind, ... All OpenSource Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From marka at isc.org Wed Dec 20 22:50:33 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Dec 2017 09:50:33 +1100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <87bmitjahm.fsf@pc8.berlin.quux.de> References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> <87bmitjahm.fsf@pc8.berlin.quux.de> Message-ID: <5DC7BE9D-54D4-48ED-9E28-40820C16A238@isc.org> As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 breaks stuff. Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the NAT64 you already have. Mark > On 21 Dec 2017, at 9:33 am, Jens Link wrote: > > Ca By writes: > >> http://jool.mx/en/index.html >> >> Free open source nat64 > > And the DNS64 part can be done with powerdns (recursor), unbound, bind, > ... All OpenSource > > Jens > -- > ---------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | > ---------------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Wed Dec 20 23:01:20 2017 From: cb.list6 at gmail.com (Ca By) Date: Wed, 20 Dec 2017 23:01:20 +0000 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <5DC7BE9D-54D4-48ED-9E28-40820C16A238@isc.org> References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> <87bmitjahm.fsf@pc8.berlin.quux.de> <5DC7BE9D-54D4-48ED-9E28-40820C16A238@isc.org> Message-ID: On Wed, Dec 20, 2017 at 5:54 PM Mark Andrews wrote: > As someone who has written a DNS64 implementation - DO NOT USE DNS64. > DNS64 breaks stuff. > > Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use > the NAT64 you already have. > > Mark > That’s just your opinion, man. Works for me and my 70 million customers. Anything that is broken by DNS64 can be properly fixed by eliminating the need for it — by deploying ipv6. DNS64 only appears when the far end resource is single stacked (!) We won’t be held hostage by folks who refuse to deploy ipv6, those days are over Happy holidays! > > > On 21 Dec 2017, at 9:33 am, Jens Link wrote: > > > > Ca By writes: > > > >> http://jool.mx/en/index.html > >> > >> Free open source nat64 > > > > And the DNS64 part can be done with powerdns (recursor), unbound, bind, > > ... All OpenSource > > > > Jens > > -- > > > ---------------------------------------------------------------------------- > > | Foelderichstr. 40 | 13595 Berlin, Germany | > +49-151-18721264 | > > | http://blog.quux.de | jabber: jenslink at quux.de | > --------------- | > > > ---------------------------------------------------------------------------- > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From morrowc.lists at gmail.com Wed Dec 20 23:07:35 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Dec 2017 18:07:35 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard wrote: > > I’ve tried several times to come up with a scenario that leads to > depletion in less than 200 years, and I haven’t managed it. Can you do it? > during some ARIN discussions that revolved around Transition Technologies and allocations to large ISPs, there were more than a few folk batting around the idea that they may need to allocate a /24 or a /20 even to a single provider. I believe DT has a /19 assigned to them currently? how many /19's are there in the v6 space? (524288-ish) That's only ~100x the current number of active ASN in the field. It's unclear (to me) how many of those could/would justify a /19 equivalent, and how fast the ASN field is growing over time. 200 years seems optomistic, 20 years seems easy to imagine surpassing though. What's the sweet spot? From jmaimon at jmaimon.com Wed Dec 20 23:15:44 2017 From: jmaimon at jmaimon.com (Joe Maimon) Date: Wed, 20 Dec 2017 18:15:44 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> Message-ID: <5A3AEF20.4050606@jmaimon.com> William Herrin wrote: > > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders > of magnitude to just 9 orders of magnitude. Your link which needed at most > 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. > > Then we do /48s from which the /64s are assigned and we lose another 3 or > so orders of magnitude... Sparsely allocate those /48s for another order of > magnitude. From sparsely allocated ISP blocks for another order of > magnitude. It slips away faster than you might think. > > Regards, > Bill Herrin > > When you consider that the default starting ISP size is /32, and that is sufficient to address something less than 64k subscribers, purist style, in broadest possible theoretical terms the following emerges. a) ipv6 has one ISP per every 1.x human (enough?), IPv4 has one IP per every 1.x human (not enough) b) IPv4 has 64k ISP's capable of servicing 64k customers, IPv6 has 64k multiples of that. So that will be one paradigm shift and one order of magnitude (exponentially speaking) for your total. There is plenty more to wonder about, for example, will the rest of the unicast space get Class E'd? Joe From marka at isc.org Wed Dec 20 23:41:59 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Dec 2017 10:41:59 +1100 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <9BC09A1A-C326-4FD3-8C1E-CA0D874DEB43@delong.com> <87bmitjahm.fsf@pc8.berlin.quux.de> <5DC7BE9D-54D4-48ED-9E28-40820C16A238@isc.org> Message-ID: DNS64 “works” if you ignore what it breaks. MAP-T does NAT46 to the NAT64 and doesn’t have the side effects of DNS64. Why people insist that DNS64 is a “good" way to direct traffic to the NAT 64 I don’t understand. MAP-T directs the traffic to the NAT64 without the side effects. DNS64 was only ever a stop gap mechanism with lots of know side effects. Mark > On 21 Dec 2017, at 10:01 am, Ca By wrote: > > > On Wed, Dec 20, 2017 at 5:54 PM Mark Andrews wrote: > As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 breaks stuff. > > Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the NAT64 you already have. > > Mark > > > That’s just your opinion, man. Works for me and my 70 million customers. > > Anything that is broken by DNS64 can be properly fixed by eliminating the need for it — by deploying ipv6. DNS64 only appears when the far end resource is single stacked (!) > > We won’t be held hostage by folks who refuse to deploy ipv6, those days are over > > Happy holidays! > > > > > On 21 Dec 2017, at 9:33 am, Jens Link wrote: > > > > Ca By writes: > > > >> http://jool.mx/en/index.html > >> > >> Free open source nat64 > > > > And the DNS64 part can be done with powerdns (recursor), unbound, bind, > > ... All OpenSource > > > > Jens > > -- > > ---------------------------------------------------------------------------- > > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > > | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | > > ---------------------------------------------------------------------------- > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From valdis.kletnieks at vt.edu Thu Dec 21 00:14:51 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Dec 2017 19:14:51 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <5A3AEF20.4050606@jmaimon.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <5A3AEF20.4050606@jmaimon.com> Message-ID: <14858.1513815291@turing-police.cc.vt.edu> On Wed, 20 Dec 2017 18:15:44 -0500, Joe Maimon said: > There is plenty more to wonder about, for example, will the rest of the > unicast space get Class E'd? That's a non-starter, as pretty much all the gear out there has code that says 'Class E is reserved" (including gear that's *already* doing production IPv6). If you're going to upgrade everything *anyhow*, deploying IPv6 has better bang for the buck than Class E support. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From george.metz at gmail.com Thu Dec 21 00:54:25 2017 From: george.metz at gmail.com (George Metz) Date: Wed, 20 Dec 2017 19:54:25 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <14858.1513815291@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <5A3AEF20.4050606@jmaimon.com> <14858.1513815291@turing-police.cc.vt.edu> Message-ID: I think he's referring to all the Unicast IPv6 outside of 2000::/3 getting designated as "reserved", and therefore no gear will ever successfully route it... just like happened with the Class E space. You'd think we would know better than to let that happen, but there's a lot of things you'd think we would know better than to let happen, and yet it still happens, with dreary regularity. On Wed, Dec 20, 2017 at 7:14 PM, wrote: > On Wed, 20 Dec 2017 18:15:44 -0500, Joe Maimon said: > > > There is plenty more to wonder about, for example, will the rest of the > > unicast space get Class E'd? > > That's a non-starter, as pretty much all the gear out there has code that > says > 'Class E is reserved" (including gear that's *already* doing production > IPv6). If > you're going to upgrade everything *anyhow*, deploying IPv6 has better > bang for > the buck than Class E support. > From jmaimon at jmaimon.com Thu Dec 21 00:54:57 2017 From: jmaimon at jmaimon.com (Joe Maimon) Date: Wed, 20 Dec 2017 19:54:57 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <14858.1513815291@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <5A3AEF20.4050606@jmaimon.com> <14858.1513815291@turing-police.cc.vt.edu> Message-ID: <5A3B0661.1080401@jmaimon.com> valdis.kletnieks at vt.edu wrote: > On Wed, 20 Dec 2017 18:15:44 -0500, Joe Maimon said: > >> There is plenty more to wonder about, for example, will the rest of the >> unicast space get Class E'd? > That's a non-starter, as pretty much all the gear out there has code that says > 'Class E is reserved" (including gear that's *already* doing production IPv6). If > you're going to upgrade everything *anyhow*, deploying IPv6 has better bang for > the buck than Class E support. They got class E'd....will that happen to the rest of ipv6? From kmedcalf at dessus.com Thu Dec 21 00:59:13 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 20 Dec 2017 17:59:13 -0700 Subject: Waste will kill ipv6 too In-Reply-To: <3A6AF008-7967-4C15-BD88-06C787B93959@beckman.org> Message-ID: The "minimum" network size for IPv4 is a /29 The "Minimum" network size for IPv6 is a /64 That means that IPv6 has 2**(64-29) more minimal sized networks that IPv4 (the fact that the size of those networks is different is immaterial). 2**(64-29) is 34,359,738,368 or 3.4e10 That is quite a few more networks. Even the currently allocated space contains 2,147,483,648 times the number of "minimum sized networks" as IPv4. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman >Sent: Wednesday, 20 December, 2017 14:39 >To: William Herrin >Cc: nanog at nanog.org >Subject: Re: Waste will kill ipv6 too > >Bill, > >You are correct. > >As a double check, I divided 340282366920938463463374607431768211456 >by 4294967296, getting >79228162514264337593543950336%20593%20543%20950%20336>, which is 28.8 orders of magnitude :) > > -mel > >On Dec 20, 2017, at 12:58 PM, William Herrin >> wrote: > >On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman >> wrote: >I won’t do the math for you, but you’re circumcising the mosquito >here. We didn’t just increase our usable space by 2 orders of >magnitude. It’s increased more than 35 orders of magnitude. > >Hi Mel, > >The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = >7.9*10^28. > >There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders >of magnitude." Orders of magnitude describes a difference between one >thing and another, in this case the IPv4 and IPv6 address spaces. > > >Using a /64 for P2P links is no problem, really. Worrying about that >is like a scuba diver worrying about how many air molecules are >surrounding the boat on the way out to sea. > >It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 >orders of magnitude to just 9 orders of magnitude. Your link which >needed at most 2 bits of IPv4 address space now consumes 64 bits of >IPv6 address space. > >Then we do /48s from which the /64s are assigned and we lose another >3 or so orders of magnitude... Sparsely allocate those /48s for >another order of magnitude. From sparsely allocated ISP blocks for >another order of magnitude. It slips away faster than you might >think. > >Regards, >Bill Herrin > > >-- >William Herrin ................ >herrin at dirtside.com >bill at herrin.us >Dirtside Systems ......... Web: From bill at herrin.us Thu Dec 21 01:27:50 2017 From: bill at herrin.us (William Herrin) Date: Wed, 20 Dec 2017 20:27:50 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> Message-ID: On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews wrote: > > Handing out /48’s to homes was never ever going to cause us to run out of > IPv6 space. Even if the homes are are connected to multiple providers > there isn’t a issue. > Hi Mark, No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Thu Dec 21 01:47:22 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Dec 2017 12:47:22 +1100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> Message-ID: <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses. Automatic assignment in homenet does dense assignment. > On 21 Dec 2017, at 12:27 pm, William Herrin wrote: > > On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews wrote: > Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. > > Hi Mark, > > No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with > it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Dec 21 04:09:08 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Dec 2017 20:09:08 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <29891.1513736532@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <29891.1513736532@turing-police.cc.vt.edu> Message-ID: <2F5B5AC8-5349-416F-8370-C2A707912C0D@delong.com> > On Dec 19, 2017, at 18:22 , Valdis.Kletnieks at vt.edu wrote: > > On Tue, 19 Dec 2017 20:18:57 +0000, "UpTide ." said: >> If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 >> (16777216) times larger; but if we start doing something crazy like allocating >> a /48 or /56 that number plummets. (256 times larger, and 65536 times larger >> respectfully.) > > You seem to have missed an entire octet's worth of bits, so off by a factor of 256… > That’s OK… You seem to have your directions reversed... > A /48 is 16 more bits than a /32, so 65536 times bigger. You mean smaller. > A /56 is 24 more bits than a /32, so 16777216 times bigger. You mean smaller. > And a /64 is 32 bits more than a /32... so.... > > Given that a /33 is just about enough to give everybody in the planet one, > giving away 8 million times that many is going to be a challenge, unless > somebody invents nanotech that wants a separate address for each nanomachine. Not outside the realm of possibility, but they’d need to invent nonotech that resulted in 8+million * 18 quintillion machines per person to really cause a problem. > > But I'd argue that if I have personal nanotech, I *really* want to use ULA > addresses. They're *my* nanotech. :) > Feel free. Personally, I still see ULA as an absurdity. Owen From surfer at mauigateway.com Thu Dec 21 04:23:56 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Dec 2017 20:23:56 -0800 Subject: Companies using public IP space owned by others for internal routing Message-ID: <20171220202356.2D188F30@m0117565.ppops.net> --- owen at delong.com wrote: From: Owen DeLong > But I'd argue that if I have personal nanotech, I *really* want > to use ULA addresses. They're *my* nanotech. :) Feel free. Personally, I still see ULA as an absurdity. ------------------------------------------------------------ Why? More tools to solve more problems. scott From valdis.kletnieks at vt.edu Thu Dec 21 04:26:19 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Dec 2017 23:26:19 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: <2F5B5AC8-5349-416F-8370-C2A707912C0D@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <29891.1513736532@turing-police.cc.vt.edu> <2F5B5AC8-5349-416F-8370-C2A707912C0D@delong.com> Message-ID: <41466.1513830379@turing-police.cc.vt.edu> On Wed, 20 Dec 2017 20:09:08 -0800, Owen DeLong said: > That���s OK��� You seem to have your directions reversed... > > > A /48 is 16 more bits than a /32, so 65536 times bigger. > > You mean smaller. The original poster obviously meant "bigger" as in "number of them available". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From karsten.elfenbein at gmail.com Thu Dec 21 10:35:08 2017 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Thu, 21 Dec 2017 11:35:08 +0100 Subject: Bandwidth distribution per ip In-Reply-To: <442a112d54a872695a16c6636be22a8d@visp.net.lb> References: <442a112d54a872695a16c6636be22a8d@visp.net.lb> Message-ID: Hi, sounds like you are hosting the origin for the CDN which causes issues. Does the CDN care where it is pulling the data from? Could you place a cheaper origin somewhere else? Like AWS, Italy, Katar or Amsterdam? For 150k/month you can get a lot of bandwidth/storage/rack space somewhere else. An other option could be to use something like origin storage where the content is stored on a CDN provider server already. Other than that you could check the hashing with your upstream provider and make them use layer 4 info as well. If they refuse you might be able to free up some IPs by reducing ptp links to /31 or some ugly NAT tricks where ports are pointing to different services. (Mail ports go to mailserver and http to CDN unit) For ~$37.5k you can also buy some more prefixes to announce. Karsten 2017-12-20 18:04 GMT+01:00 Denys Fedoryshchenko : > On 2017-12-20 17:52, Saku Ytti wrote: >> >> On 20 December 2017 at 16:55, Denys Fedoryshchenko >> wrote: >> >>> And for me, it sounds like faulty aggregation + shaping setup, for >>> example, >>> i heard once if i do policing on some models of Cisco switch, on an >>> aggregated interface, if it has 4 interfaces it will install 25% policer >>> on >>> each interface and if hashing is done by dst ip only, i will face such >>> issue, but that is old and cheap model, as i recall. >> >> >> One such old and cheap model is ASR9k trident, typhoon and tomahawk. >> >> It's actually pretty demanding problem, as technically two linecards >> or even just ports sitting on two different NPU might as well be >> different routers, they don't have good way to communicate to each >> other on BW use. So N policer being installed as N/member_count per >> link is very typical. >> >> ECMP is fact of life, and even thought none if any provider document >> that they have per-flow limitations which are lower than nominal rate >> of connection you purchases, these do exist almost universally >> everywhere. People who are most likely to see these limits are people >> who tunnel everything, so that everything from their say 10Gbps is >> single flow, from POV of the network. >> In IPv6 world at least tunnel encap end could write hash to IPv6 flow >> label, allowing core potentially to balance tunneled traffic, unless >> tunnel itself guarantees order. >> >> I don't think it's fair for operator to demand equal bandwidth per IP, >> but you will expose yourself to more problems if you do not have >> sufficient entropy. We are slowly getting solutions to this, Juniper >> Trio and BRCM Tomahawk3 can detect elephant flows and dynamically >> unequally map hash results to physical ports to alleviate the problem. > > As person who is in love with embedded systems development, i just watched > today beautiful 10s of meters long 199x machine, where multi kW VFDs manage > huge motors(not steppers), dragging synchronously and printing on thin paper > with crazy speed and all they have is long ~9600 link between a bunch of > encoders > and PLC dinosaur managing all this beauty. If any of them will apply a bit > wrong > torque, stretched paper will rip apart. > In fact nothing complex there, and technology is ancient these days. > Engineers who cannot synchronize and update few virtual "subinstances" > policing ratio based on feedback, in one tiny, expensive box, with > reasonable > update ratio, having in hands modern technologies, maybe incompetent? > > National operator doesn't provide IPv6, that's one of the problems. > In most of cases there is no tunnels, but imperfection still exist. > When ISP pays ~$150k/month (bandwidth very expensive here), and because > CDN has 3 units & 3 ingress ips, and carrier have bonding somewhere over > 4 links, it just means ~$37.5k is lost in rough estimations, > no sane person will accept that. > Sometimes one CDN unit are in maintenance, and 2 existing can perfectly > serve demand, but because of this "balancing" issues - it just go down, > as half of capacity missing. > > But, tunnels in rare cases true too, but what we can do, if they don't have > reasonable DDoS protection tools all world have (not even blackholing). > Many DDoS-protection operators charge extra for more tunnel endpoints with > balancing, and this balancing is not so equal as well (same src+dst ip at > best). > And when i did round-robin on my own solution, i noticed except > this "bandwidth distribution" issue, latency on each ip is unequal, > so RR create for me "out of order" issues. > Another problem, most popular services in region (in matters of bandwidth) > is facebook, whatsapp, youtube. Most of them is big fat flows running over > few ips. I doubt i can convince them to balance over more. From jwbensley at gmail.com Thu Dec 21 12:27:03 2017 From: jwbensley at gmail.com (James Bensley) Date: Thu, 21 Dec 2017 12:27:03 +0000 Subject: Bandwidth distribution per ip In-Reply-To: References: Message-ID: On 20 December 2017 at 15:52, Saku Ytti wrote: > On 20 December 2017 at 16:55, Denys Fedoryshchenko wrote: > >> And for me, it sounds like faulty aggregation + shaping setup, for example, >> i heard once if i do policing on some models of Cisco switch, on an >> aggregated interface, if it has 4 interfaces it will install 25% policer on >> each interface and if hashing is done by dst ip only, i will face such >> issue, but that is old and cheap model, as i recall. > > One such old and cheap model is ASR9k trident, typhoon and tomahawk. > > It's actually pretty demanding problem, as technically two linecards > or even just ports sitting on two different NPU might as well be > different routers, they don't have good way to communicate to each > other on BW use. So N policer being installed as N/member_count per > link is very typical. Hi, In the case of ASR9K IOS-XR 6.0.1 added the following command: "hw-module all qos-mode bundle-qos-aggregate-mode" This splits the bandwidth over the links and takes into account the link bandwidth; with bundle bandwidth 50G (with 10G+40G members) the ratios become 5/1 and 5/4 respectively (it is supporting unbalanced member link speeds). Also the NPUs don't need to talk to each other on the ASR9K; the central fabric arbiter has a view of bandwidth per VoQ and can control the bandwidth across the LAG member interfaces when they are spread over multiple lines cards and NPUs. Cheers, James, From mysidia at gmail.com Thu Dec 21 14:50:06 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 21 Dec 2017 08:50:06 -0600 Subject: Waste will kill ipv6 too In-Reply-To: <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> Message-ID: On Wed, Dec 20, 2017 at 3:57 PM, Mark Andrews wrote: [SNIP] 25B estimate for earth's carrying capacity for humans is likely on the high side, but sure: IPv6 should suffice until we have a few planets' worth of humans, and require an interstellar IP network with end-to-end comms between every remote device in our galaxy cluster --- and may have to fallback to planetary NAT or LISP for some applications. Something should probably go into some FAQ at some point..... "Q: IPv6 could still run out of addresses / Waste will kill ipv6 too / Etc." "A: No, although there is an occasional point of confusion regarding IPv6 that we will still run out of addresses: that is a highly-improbable event: please see list archives. >From evaluation of the arithmetic, there is not a reasonable forecast model that can be made that would start from realistic assumptions about network growth and could come to the conclusion that depletion of IPv6 would be a possibility under current regional registry allocation policies based on justified need, even allocating up to a couple dedicated /48s per person up to the expected maximum population capacities of earth.... -- -JH When the IETF decided on 128 bit addresses it was taking into consideration > /80 sized subnet. Prior to that it was looking at a 64 bit address size > and allocating addresses the IPv4 way with lots of variable sized > networks. This was changed to /64 subnets to accomodate 64 bit MAC. After > that there was discussion about how many subnet should be enough for 99.99% > of sites which gave /48 per site using /64 sized network. That > 281474976710656 sites or 35184372088832 out of the /3 we are currently > allocating from. > > Now there are very few sites that need 65536 subnets and those that do can > request additional /48’s. > > Now if you assume the earth’s population will get to 25B, and every person > is a site, that still leaves 35159372088832 sites. > And if each of those people also has a home and a vehicle, that still > leaves 35109372088832 sites. > > Handing out /48’s to homes was never ever going to cause us to run out of > IPv6 space. Even if the homes are are connected to multiple providers > there isn’t a issue. > > Mark > > > On 21 Dec 2017, at 7:57 am, William Herrin wrote: > > > > On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman wrote: > > > >> I won’t do the math for you, but you’re circumcising the mosquito here. > We > >> didn’t just increase our usable space by 2 orders of magnitude. It’s > >> increased more than 35 orders of magnitude. > >> > > > > Hi Mel, > > > > The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. > > > > There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of > > magnitude." Orders of magnitude describes a difference between one thing > > and another, in this case the IPv4 and IPv6 address spaces. > > > > > > Using a /64 for P2P links is no problem, really. Worrying about that is > >> like a scuba diver worrying about how many air molecules are surrounding > >> the boat on the way out to sea. > >> > > > > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 > orders > > of magnitude to just 9 orders of magnitude. Your link which needed at > most > > 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. > > > > Then we do /48s from which the /64s are assigned and we lose another 3 or > > so orders of magnitude... Sparsely allocate those /48s for another order > of > > magnitude. From sparsely allocated ISP blocks for another order of > > magnitude. It slips away faster than you might think. > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Dirtside Systems ......... Web: > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From jason.iannone at gmail.com Thu Dec 21 15:16:25 2017 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 21 Dec 2017 10:16:25 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> Message-ID: M&A plays into this too. By my calculations, CenturyLink controls at least 17 million /48s. How many sites does CenturyLink provide service to? I'm gonna go out on a limb and say it's not 17 million. 3 acquisitions rolled up into AS209: as3549 2605:a300::/32 2001:450::/32 as4323 2604:6680::/32 2602:ff99::/36 2620:12e:6000::/40 2620:10e:8000::/40 2620:124:8000::/44 2001:506:8::/48 2620:75::/48 2620:f:4000::/48 2620:3b:4000::/48 2620:c5:4000::/48 as3356 2607:6e00::/32 2606:8a00::/32 2604:3a00::/32 2605:1280::/32 2605:4680::/32 2605:c680::/32 2604:24c0::/32 2602:ffeb::/36 2602:ffe1::/36 2620:109::/40 2620:123:d000::/40 2620:12d:c000::/44 2620:42:4000::/48 2620:87:4000::/48 2620:8d:c000::/48 2620:ba:c000::/48 2620:f8:c000::/48 2604:5200:1007::/48 2620:6:e000::/48 as209 2602::/24 2606:5000::/32 2605:c680::/32 2602:ff5f::/36 2620:123:3000::/40 2620:12e:6000::/40 2620:9c:4000::/44 2620:122:4000::/44 2620:123:b000::/44 2001:428:902::/48 2001:428:7001::/48 2001:428:7004::/48 2001:428:4004::/48 2001:428:3000::/48 2001:428:2403::/48 2001:428:7005::/48 2001:428:939::/48 2001:428:6803::/48 2001:428:5003::/48 2001:428:e203::/48 2001:428:3804::/48 2620:0:2280::/48 2620:0:2b20::/48 2001:428:4c04::/48 2001:428:4c05::/48 2001:428:5004::/48 2001:428:1403::/48 2001:428:1404::/48 2001:428:6804::/48 2001:428:2502::/48 2001:428:2501::/48 2001:428:200c::/48 2001:428:480a::/48 2620:d9:8000::/48 2001:428:5804::/48 2001:428:2406::/48 2001:428:1804::/48 2001:428:2405::/48 2001:428:2408::/48 2001:428:1c03::/48 2001:428:6403::/48 2001:428:1803::/48 2001:428:7009::/48 2001:428:5806::/48 2620:42:4000::/48 2001:428:1405::/48 2001:428:3c03::/48 2001:428:e204::/48 2001:428:e205::/48 2001:428:1806::/48 2001:428:6805::/48 2001:428:1808::/48 2001:428:1809::/48 2001:428:a403::/48 2001:428:4407::/48 2001:428:3807::/48 2001:428:c0c::/48 2001:428:4003::/48 2001:428:4803::/48 2001:428:1003::/48 2001:428:3808::/48 2001:428:30::/48 2620:ac:c000::/48 2001:428:700c::/48 2001:428:5803::/48 2001:428:380b::/48 2001:428:380c::/48 2001:428:380d::/48 2001:428:4403::/48 2001:428:aa03::/48 2001:428:4404::/48 2001:428:2407::/48 2001:428:240b::/48 2001:428:4c09::/48 2001:428:700a::/48 2001:428:c08::/48 2001:428:2004::/48 2001:428:2404::/48 2001:428:7007::/48 2001:428:7405::/48 2001:428:c0b::/48 2001:428:4406::/48 2001:428:c05::/48 2001:428:c06::/48 2001:428:3805::/48 2001:428:4c07::/48 2001:428:2003::/48 2001:428:2005::/48 2001:428:6404::/48 2001:428:7404::/48 2001:428:240a::/48 2001:428:4405::/48 2001:428:4c08::/48 2001:428:2002::/48 2001:428:c09::/48 2001:428:240e::/48 2001:428:4408::/48 2001:428:380e::/48 2001:428:4005::/48 2001:428:4409::/48 2001:428:a404::/48 2001:428:1004::/48 2001:428:8c03::/48 2001:428:9e03::/48 2001:428:3810::/48 2001:428:700d::/48 2001:428:2006::/48 2001:428:6405::/48 2001:428:a405::/48 2001:428:8c04::/48 2001:428:5805::/48 2620:74:c040::/48 2620:6:e000::/48 2001:428:1805::/48 2001:428:b003::/48 2001:428:3c04::/48 2001:428:6400::/48 2001:428:8c00::/48 2001:428:9e00::/48 2001:428:1c00::/48 2001:428:7006::/48 2001:428:4c00::/48 2001:428:2400::/48 2001:428:7008::/48 source: source: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Jason On Wed, Dec 20, 2017 at 8:47 PM, Mark Andrews wrote: > The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses. > > Automatic assignment in homenet does dense assignment. > >> On 21 Dec 2017, at 12:27 pm, William Herrin wrote: >> >> On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews wrote: >> Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. >> >> Hi Mark, >> >> No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with >> it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From ops.lists at gmail.com Thu Dec 21 15:51:33 2017 From: ops.lists at gmail.com (ops.lists at gmail.com) Date: Thu, 21 Dec 2017 15:51:33 +0000 (UTC) Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> Message-ID: <3891E66D23A71805.4ED3CC5E-8815-4614-BA7E-BEC9B22C56D8@mail.outlook.com> A very familiar pattern. Pretty soon, our children will be going to intergalactic governance fora debating v6 exhaustion and dusting off Jim Fleming’s ipv9 -srs —srs On Thu, Dec 21, 2017 at 8:48 PM +0530, "Jason Iannone" wrote: M&A plays into this too. By my calculations, CenturyLink controls at least 17 million /48s. How many sites does CenturyLink provide service to? I'm gonna go out on a limb and say it's not 17 million. 3 acquisitions rolled up into AS209: as3549 2605:a300::/32 2001:450::/32 as4323 2604:6680::/32 2602:ff99::/36 2620:12e:6000::/40 2620:10e:8000::/40 2620:124:8000::/44 2001:506:8::/48 2620:75::/48 2620:f:4000::/48 2620:3b:4000::/48 2620:c5:4000::/48 as3356 2607:6e00::/32 2606:8a00::/32 2604:3a00::/32 2605:1280::/32 2605:4680::/32 2605:c680::/32 2604:24c0::/32 2602:ffeb::/36 2602:ffe1::/36 2620:109::/40 2620:123:d000::/40 2620:12d:c000::/44 2620:42:4000::/48 2620:87:4000::/48 2620:8d:c000::/48 2620:ba:c000::/48 2620:f8:c000::/48 2604:5200:1007::/48 2620:6:e000::/48 as209 2602::/24 2606:5000::/32 2605:c680::/32 2602:ff5f::/36 2620:123:3000::/40 2620:12e:6000::/40 2620:9c:4000::/44 2620:122:4000::/44 2620:123:b000::/44 2001:428:902::/48 2001:428:7001::/48 2001:428:7004::/48 2001:428:4004::/48 2001:428:3000::/48 2001:428:2403::/48 2001:428:7005::/48 2001:428:939::/48 2001:428:6803::/48 2001:428:5003::/48 2001:428:e203::/48 2001:428:3804::/48 2620:0:2280::/48 2620:0:2b20::/48 2001:428:4c04::/48 2001:428:4c05::/48 2001:428:5004::/48 2001:428:1403::/48 2001:428:1404::/48 2001:428:6804::/48 2001:428:2502::/48 2001:428:2501::/48 2001:428:200c::/48 2001:428:480a::/48 2620:d9:8000::/48 2001:428:5804::/48 2001:428:2406::/48 2001:428:1804::/48 2001:428:2405::/48 2001:428:2408::/48 2001:428:1c03::/48 2001:428:6403::/48 2001:428:1803::/48 2001:428:7009::/48 2001:428:5806::/48 2620:42:4000::/48 2001:428:1405::/48 2001:428:3c03::/48 2001:428:e204::/48 2001:428:e205::/48 2001:428:1806::/48 2001:428:6805::/48 2001:428:1808::/48 2001:428:1809::/48 2001:428:a403::/48 2001:428:4407::/48 2001:428:3807::/48 2001:428:c0c::/48 2001:428:4003::/48 2001:428:4803::/48 2001:428:1003::/48 2001:428:3808::/48 2001:428:30::/48 2620:ac:c000::/48 2001:428:700c::/48 2001:428:5803::/48 2001:428:380b::/48 2001:428:380c::/48 2001:428:380d::/48 2001:428:4403::/48 2001:428:aa03::/48 2001:428:4404::/48 2001:428:2407::/48 2001:428:240b::/48 2001:428:4c09::/48 2001:428:700a::/48 2001:428:c08::/48 2001:428:2004::/48 2001:428:2404::/48 2001:428:7007::/48 2001:428:7405::/48 2001:428:c0b::/48 2001:428:4406::/48 2001:428:c05::/48 2001:428:c06::/48 2001:428:3805::/48 2001:428:4c07::/48 2001:428:2003::/48 2001:428:2005::/48 2001:428:6404::/48 2001:428:7404::/48 2001:428:240a::/48 2001:428:4405::/48 2001:428:4c08::/48 2001:428:2002::/48 2001:428:c09::/48 2001:428:240e::/48 2001:428:4408::/48 2001:428:380e::/48 2001:428:4005::/48 2001:428:4409::/48 2001:428:a404::/48 2001:428:1004::/48 2001:428:8c03::/48 2001:428:9e03::/48 2001:428:3810::/48 2001:428:700d::/48 2001:428:2006::/48 2001:428:6405::/48 2001:428:a405::/48 2001:428:8c04::/48 2001:428:5805::/48 2620:74:c040::/48 2620:6:e000::/48 2001:428:1805::/48 2001:428:b003::/48 2001:428:3c04::/48 2001:428:6400::/48 2001:428:8c00::/48 2001:428:9e00::/48 2001:428:1c00::/48 2001:428:7006::/48 2001:428:4c00::/48 2001:428:2400::/48 2001:428:7008::/48 source: source: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Jason On Wed, Dec 20, 2017 at 8:47 PM, Mark Andrews wrote: > The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses. > > Automatic assignment in homenet does dense assignment. > >> On 21 Dec 2017, at 12:27 pm, William Herrin wrote: >> >> On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews wrote: >> Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. >> >> Hi Mark, >> >> No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with >> it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From owen at delong.com Thu Dec 21 15:54:04 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Dec 2017 07:54:04 -0800 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: > On Dec 18, 2017, at 15:09 , William Herrin wrote: > > On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke wrote: > >> some fun examples of the size of ipv6: >> >> https://samsclass.info/ipv6/exhaustion-2016.htm >> >> https://www.reddit.com/r/theydidthemath/comments/ >> 2qxgxw/self_just_how_big_is_ipv6/ > > > Hi Eric, > > Lies, damn lies and statistics. Both projections assume that IPv6 addresses > are assigned the same way we assign IPv4 addresses. They are not. > > There are several practices which consume IPv6 at a drastically higher rate > than IPv4. The most notable is the assignment of a /64 to every LAN. Your > /26 LAN that used to consume 2^6th IP addresses? Now it's 2^64th. Used to > consume RFC1918 addresses? Now it's 2^64th of the global IPv6 addresses. > > Why did we need a /64 for each LAN? So we could incorporate the Ethernet > MAC address in to the IP address. Only we can't actually do that because it > turns out to be crazy insecure. Nevertheless, the 3 computers in your > basement will still consume 2^64th IPv6 addresses between them. But hey, > what's 20 orders of magnitude between friends. > > We have ISPs that have received allocations of entire /19s. A /19 in IPv6 > is exactly the same percentage of the total address space as a /19 in IPv4. > Before considering reserved addresses, it's 1/2^19th of the total address > space. For a single ISP. Think about it. Sure… However, we have a few very large ISPs that have received /19s (~1/524,288 of the total space each). Unlike IPv4 where we have thousands and thousands of ISPs and even some end users that have more than a /19. Do you really think we’re anywhere near likely to have 500 ISPs world wide that get /19s, let alone 524,288? An IPv6 /19 provides enough addressing in IPv6 to give out 2^29 or roughly 536 million customers /48s. Even if we allow for pretty large overhead, there’s still plenty of address space there for ~100 million customer /48s. Let’s round up the 7 billion current population to 10 for the sake of conservatism, even still we only need roughly 100 ISPs that size to handle everyone on the planet. If we allow for some overlap and then quadruple the requirement to cover content-side needs in addition to eyeballs, that’s still less than 1,000 /19 sized allocations needed. So, even at that rate, we’ve still got 523,288 /19s left. > Meanwhile the IETF has learned nothing from the gargantuan waste that is > 224.0.0.0/4 ($2billion at current prices). They went and assigned FC00::/7. > /7!! Almost 1% of the IPv6 address space gone in a single RFC. As much as I consider the fc00::/7 reservation to be ridiculous, the reality is that RFC-1918 wasn’t that much short of the 1% mark in IPv4, either. The reservation of fc00::/7 is much more analogous to RFC-1918 than to 224.0.0.0/4. In fact, fd00::/8 is analogous to 224.0.0.0/4 and I think that use makes sense in both cases. While multicast didn’t take off or work out well in IPv4, a smaller address space would only have made that worse. I think that your real target was 240.0.0.0/4, which was set aside for experimental and other undefined purposes and never really got used for much of anything. Unfortunately, if you want to claim the IETF didn’t lear the lesson there, it’s a bit harder since there’s no such reservation in IPv6, > I haven't attempted to compute the actual rate of IPv6 consumption but it's > not inconceivable that we could exhaust them by the end of the century > through sheer ineptitude. Well, to the best of my knowledge, no RIR has yet requested a second /12. I’ll be surprised if we burn through the first /3 using current allocation practices within my lifetime. If we do, then I’ll join your quest to burden IPv6 with more restrictive allocation practices for the remaining 5 virgin /3s and the remaining space in the other 2. > On the plus side, we're mostly only screwing around with 2000::/3 right > now. After we burn through that in the next 20 years, we can if we so > desire change the rules for how (and how quickly) we use 4000::/3. However, even if your prediction somehow comes true and we don’t change the rules, that gives us roughly a 120 year timeframe for running out of the existing /3 and the remaining 5 /3s that have not been touched, without even invading ::/3 or e000::/3 (the first and last /3s which each have some carve-outs, but remain mostly free space as well). If we don’t end up needing to fix other things and replace the codebase with something that would allow us to redo the address space in the next 120 years, I’ll be quite surprised. Owen From morrowc.lists at gmail.com Thu Dec 21 15:58:58 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Dec 2017 10:58:58 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> Message-ID: On Thu, Dec 21, 2017 at 10:16 AM, Jason Iannone wrote: > M&A plays into this too. By my calculations, CenturyLink controls at > least 17 million /48s. How many sites does CenturyLink provide > service to? I'm gonna go out on a limb and say it's not 17 million. > there are less than 17m households served by centurylink's residential product? really? each of those could be considered a site and then get a /48. Oh: http://news.centurylink.com/CenturyLink-Reports-First-Quarter-2016-Results says in 2016 ~6.1m households. From lee at asgard.org Thu Dec 21 16:20:06 2017 From: lee at asgard.org (Lee Howard) Date: Thu, 21 Dec 2017 11:20:06 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: From: on behalf of Christopher Morrow Date: Wednesday, December 20, 2017 at 6:07 PM To: Lee Howard Cc: Mike , nanog list Subject: Re: Waste will kill ipv6 too > > > On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard wrote: >> >> I’ve tried several times to come up with a scenario that leads to >> depletion in less than 200 years, and I haven’t managed it. Can you do it? > > during some ARIN discussions that revolved around Transition Technologies and > allocations to large ISPs, there were more than a few folk batting around the > idea that they may need to allocate a /24 or a /20 even to a single provider. > > I believe DT has a /19 assigned to them currently? how many /19's are there in > the v6 space? (524288-ish) > That's only ~100x the current number of active ASN in the field. It's unclear > (to me) how many of those could/would justify a /19 equivalent, and how fast > the ASN field is growing over time. DT is one of the largest ISPs in the world, isn’t it? Can you devise a scenario in which there are 524,288 ISPs the size of DT? Or one where every currently active ASN, times 100X, needs/justifies a /19? > > 200 years seems optomistic, 20 years seems easy to imagine surpassing though. > What's the sweet spot? > 200 years seems pessimistic to me. Every scenario I run uses ridiculously profligate assumptions, and usually multiplies those by a few orders of magnitude. Even extrapolating from your math above, I don’t get less than 2222CE. Lee From bill at herrin.us Thu Dec 21 16:42:03 2017 From: bill at herrin.us (William Herrin) Date: Thu, 21 Dec 2017 11:42:03 -0500 Subject: Companies using public IP space owned by others for internal routing In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Thu, Dec 21, 2017 at 10:54 AM, Owen DeLong wrote: > If we don’t end up needing to fix other things and replace the codebase > with something that would allow us to redo the address space in the > next 120 years, I’ll be quite surprised. Hi Owen, I bet you're wrong about that. I've been doing experiments with using ephemeral aggregated address hierarchies instead of routing. That's about as radical a change as changes get. No surprise that TCP fails, DNS blows up and the static subnet is rendered obsolete. One of the surprises was that IPv6 itself, the layer 3 protocol, works as well as anything new that could be designed. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From morrowc.lists at gmail.com Thu Dec 21 16:48:18 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Dec 2017 11:48:18 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Thu, Dec 21, 2017 at 11:20 AM, Lee Howard wrote: > > > From: on behalf of Christopher Morrow < > morrowc.lists at gmail.com> > Date: Wednesday, December 20, 2017 at 6:07 PM > To: Lee Howard > Cc: Mike , nanog list > Subject: Re: Waste will kill ipv6 too > > > > On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard wrote: > >> >> I’ve tried several times to come up with a scenario that leads to >> depletion in less than 200 years, and I haven’t managed it. Can you do it? >> > > during some ARIN discussions that revolved around Transition Technologies > and allocations to large ISPs, there were more than a few folk batting > around the idea that they may need to allocate a /24 or a /20 even to a > single provider. > > I believe DT has a /19 assigned to them currently? how many /19's are > there in the v6 space? (524288-ish) > That's only ~100x the current number of active ASN in the field. It's > unclear (to me) how many of those could/would justify a /19 equivalent, and > how fast the ASN field is growing over time. > > > DT is one of the largest ISPs in the world, isn’t it? > > it's large, but really it's going to hit the same number of homes (about) as att/verizon/comcast/embarq ... and I'm sure ntt, 'russian cableco', the 5 china-cablecos etc. Right? germany is ~83m people... 100x that is about 1.2x world population, so ... it seems conceivable that there are ~100 isps (one per country) about the same size, right? > Can you devise a scenario in which there are 524,288 ISPs the size of DT? > I think I did something in my reply which I should not have done, I conflated the DT issue and the transition technology discussion...splitting those up: 1) For DT, my understanding is that their allocation is this size due to part of their deployment plan/technology. (multiple /48's per site, one per particular technology in use - video, voice, intertubes, on-demand-video, something...7/site I believe was their target) 2) For the transition technology discussion I believe it centered around attempting to get a /48 to each 'site' (home/customer) and doing ds-lite as the transition technology in use. (map the customer to not a /128 in the ds-lite, but a /48) > Or one where every currently active ASN, times 100X, needs/justifies a /19? > > > 200 years seems optomistic, 20 years seems easy to imagine surpassing > though. What's the sweet spot? > > > > 200 years seems pessimistic to me. Every scenario I run uses ridiculously > profligate assumptions, and usually multiplies those by a few orders of > magnitude. Even extrapolating from your math above, I don’t get less than > 2222CE. > > ok. I think a bunch of the analysis so far in this thread has basically assumed dense packing at teh ISP and RIR level.. which really won't happen, in practice anyway. I was simply stating that if we follow some of the examples today it's no where near as certain (I think) that '200' is ok to assume. A larger point is: "so what?" we've run a number conversion / renumbering once... we can do it again, better the second time, right? :) Maybe this next time we'll even plan based on lessons learned in the v4 -> v6 slog? > Lee > > From owen at delong.com Thu Dec 21 17:00:17 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Dec 2017 09:00:17 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <6B4A81A9-7851-4157-9622-A0AABDF52284@delong.com> > ok. I think a bunch of the analysis so far in this thread has basically > assumed dense packing at teh ISP and RIR level.. which really won't happen, > in practice anyway. I was simply stating that if we follow some of the > examples today it's no where near as certain (I think) that '200' is ok to > assume. 200 might be optimistic, agreed. I think 100 is pretty well assured absent something much more profligate than current policies. > A larger point is: "so what?” Agreed. > we've run a number conversion / renumbering once... we can do it again, > better the second time, right? :) Maybe this next time we'll even plan > based on lessons learned in the v4 -> v6 slog? Technically, we’ve run one, we’re running a second one now, and yeah, hopefully lessons learned can play a part. Of course this also ignores the third transition which included a numbering transition as enterprises went from running everything else (x.25, vines, IPX, DECNET, AppleTalk, etc.) to IP. Owen From jmaimon at jmaimon.com Thu Dec 21 17:33:11 2017 From: jmaimon at jmaimon.com (Joe Maimon) Date: Thu, 21 Dec 2017 12:33:11 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <6B4A81A9-7851-4157-9622-A0AABDF52284@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <6B4A81A9-7851-4157-9622-A0AABDF52284@delong.com> Message-ID: <5A3BF057.8010905@jmaimon.com> Owen DeLong wrote: > > 200 might be optimistic, agreed. I think 100 is pretty well assured absent > something much more profligate than current policies. > > Profligacy based on the assumption of exhaustion impossibility needs to be avoided. Agreed. >> we've run a number conversion / renumbering once... we can do it again, >> better the second time, right? :) Maybe this next time we'll even plan >> based on lessons learned in the v4 -> v6 slog? > Technically, we’ve run one, we’re running a second one now, and yeah, > hopefully lessons learned can play a part. > > Of course this also ignores the third transition which included a numbering > transition as enterprises went from running everything else (x.25, vines, > IPX, DECNET, AppleTalk, etc.) to IP. > > Owen The lesson we are still learning is that the longer entrenched and successful a numbering scheme is, the more monumental the conversion effort becomes. And that therefore we should never again do one, as we have every intention of this scheme vastly exceeding the old one. Joe From owen at delong.com Thu Dec 21 18:30:57 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Dec 2017 10:30:57 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <36A1C4C6-4DB0-4F72-BC15-E6BA62A46128@delong.com> Current ARIN policy contemplated as much as a /12 per provider and set a cap there allowing a provider that needed more than that to only get additional /12s rather than nibble boundary round-ups. Owen > On Dec 20, 2017, at 15:07 , Christopher Morrow wrote: > > On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard wrote: > >> >> I’ve tried several times to come up with a scenario that leads to >> depletion in less than 200 years, and I haven’t managed it. Can you do it? >> > > during some ARIN discussions that revolved around Transition Technologies > and allocations to large ISPs, there were more than a few folk batting > around the idea that they may need to allocate a /24 or a /20 even to a > single provider. > > I believe DT has a /19 assigned to them currently? how many /19's are there > in the v6 space? (524288-ish) > That's only ~100x the current number of active ASN in the field. It's > unclear (to me) how many of those could/would justify a /19 equivalent, and > how fast the ASN field is growing over time. > > 200 years seems optomistic, 20 years seems easy to imagine surpassing > though. What's the sweet spot? From aaron1 at gvtc.com Thu Dec 21 19:08:41 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 21 Dec 2017 13:08:41 -0600 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <000001d379c4$e3693470$aa3b9d50$@gvtc.com> Message-ID: <002f01d37a8f$1d8f02e0$58ad08a0$@gvtc.com> Thanks.... but... that's the most elaborate "no comment" I've ever seen. Lol... thanks ytti -Aaron From marka at isc.org Thu Dec 21 20:21:18 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Dec 2017 07:21:18 +1100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: > On 22 Dec 2017, at 3:48 am, Christopher Morrow wrote: > > 2) For the transition technology discussion I believe it centered around > attempting to get a /48 to each 'site' (home/customer) and doing ds-lite as > the transition technology in use. > (map the customer to not a /128 in the ds-lite, but a /48) I think you mean 6rd. DS-Lite doesn’t use any extra IPv6 addresses. 6rd can be poorly done by embedding the entire IPv4 address in the IPv6 address. Doing that does waste space. 6rd deployment should not require much more IPv6 /48’s than a native IPv6 deployment would. That does require properly configuring your DHCPv4 servers with DIFFERENT 6rd DHCPv4 Option values on a per IPv4 DHCP pool basis which I’m sure every ISP here is capable of doing as there is nothing really new here to do. You have all carved up IPv4 assignments into IPv4 pools. This is no different. You carve up a IPv6 assignments into similar sized pools of /48’s then set the 6rd DHCPv4 Option to the appropriate values for that IPv4 to IPv6 pool mapping. Add the mapping to the BRs and you are done. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Thu Dec 21 23:17:58 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Dec 2017 18:17:58 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: On Thu, Dec 21, 2017 at 3:21 PM, Mark Andrews wrote: > > > On 22 Dec 2017, at 3:48 am, Christopher Morrow > wrote: > > > > 2) For the transition technology discussion I believe it centered around > > attempting to get a /48 to each 'site' (home/customer) and doing ds-lite > as > > the transition technology in use. > > (map the customer to not a /128 in the ds-lite, but a /48) > > I think you mean 6rd. DS-Lite doesn’t use any extra IPv6 addresses. > > yes, sure, it was some time ago that the discussion happened :( > 6rd can be poorly done by embedding the entire IPv4 address in the IPv6 > address. Doing that does waste space. > > 6rd deployment should not require much more IPv6 /48’s than a native IPv6 > deployment would. That does require properly configuring your DHCPv4 > servers with DIFFERENT 6rd DHCPv4 Option values on a per IPv4 DHCP pool > basis which I’m sure every ISP here is capable of doing as there is nothing > really new here to do. You have all carved up IPv4 assignments into IPv4 > pools. This is no different. You carve up a IPv6 assignments into similar > sized pools of /48’s then set the 6rd DHCPv4 Option to the appropriate > values for that IPv4 to IPv6 pool mapping. Add the mapping to the BRs and > you are done. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From maillist at webjogger.net Fri Dec 22 15:28:09 2017 From: maillist at webjogger.net (Adam Greene) Date: Fri, 22 Dec 2017 10:28:09 -0500 Subject: Small full BGP table capable router with low power consumption In-Reply-To: <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> References: <16022f7d072.f15e6c8e3911.2826654087516377228@zoho.com> <9578293AE169674F9A048B2BC9A081B40273141C3F@MUNPRDMBXA1.medline.com> Message-ID: <031501d37b39$78c735b0$6a55a110$@webjogger.net> Hey Steve (or anyone else), How much RAM are you running on your 4431? We have a similar application and are trying to figure out whether to order a 4431 with the default 4GB RAM, or upgrade it proactively to 8GB to support the full BGP table. Thanks, Adam -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Monday, December 4, 2017 5:04 PM To: nanog at nanog.org Subject: RE: Small full BGP table capable router with low power consumption Watch the memory requirements on a full Internet table in the Cisco 2900 series. More current model would be the Cisco 4300 - 4400 ISR series. They have 2/4/8/16 gigs of memory. Power consumption MAX ranges from 0.6A to 3.0A depending on model. Higher models have more throughput and more interfaces. Throughput ranges from 35 mbps to 2 gbps. I rarely see Cisco routers running near the max power rating especially if you are not using PoE or etherswitch interfaces. The 43xx series is replacing the 29xx series and the 44xx series is replacing the 39xx series. I've put in a few of them and they are pretty nice. They are either 1 or 2 U in size. We are using 4431 with throughput license to 1 GB receiving a full table from the provider and three IBGP peers with no issues and full gig throughput. It is currently drawing 65 watts of power in steady state and 250 watts on bootup (not using any PoE or network modules, just built in Ethernets). Steven Naslund Chicago IL >>-----Original Message----- >>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William >>Herrin >>Sent: Monday, December 04, 2017 3:43 PM >>To: Adam Lawson >>Cc: nanog >>Subject: Re: Small full BGP table capable router with low power >>consumption >>On Mon, Dec 4, 2017 at 2:19 PM, Adam Lawson wrote: >> The router needs to be squeezed in to a rack which doesn't have a lot >>of space nor power. As for space, maybe I can make space for 3U or 4U >>but as for power, I can only do around 1.5A at 100V on average. (There is >>room for burst power usage.) >A Cisco 2911 or 3945 does this though the 3945 is a little more power hungry. >A current generation x86 server running Linux and Quagga does this. >Regards, >Bill Herrin >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From math at sizone.org Fri Dec 22 15:44:57 2017 From: math at sizone.org (Ken Chase) Date: Fri, 22 Dec 2017 10:44:57 -0500 Subject: AS PATH limits In-Reply-To: <20171013210242.GJ11838@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> Message-ID: <20171222154457.GF6349@sizone.org> And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the router that fed us the long route, so I cant tell what it was (since we never consumed it before barfing). Let's hope for no more over holiday season... /kc On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said: > It is happening AGAIN. > >And of course it started on a friday aft 15 min before quittin' time in EDT: > >Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 > >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 ? > >/kc >-- >Ken Chase - math at sizone.org Guelph Canada -- Ken Chase - math at sizone.org Guelph Canada From nick at foobar.org Fri Dec 22 17:40:28 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Dec 2017 17:40:28 +0000 Subject: AS PATH limits In-Reply-To: <20171222154457.GF6349@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> Message-ID: <5A3D438C.3000600@foobar.org> What router software version are you running that barfs on long as-paths? Nick Ken Chase wrote: > And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the > router that fed us the long route, so I cant tell what it was (since we never > consumed it before barfing). > > Let's hope for no more over holiday season... > > /kc > > > On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said: > > It is happening AGAIN. > > > >And of course it started on a friday aft 15 min before quittin' time in EDT: > > > >Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 > > > >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262 197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 26 2197 262197 262197 262197 262197 262197 262197 262197 262197 ? > > > >/kc > >-- > >Ken Chase - math at sizone.org Guelph Canada > From math at sizone.org Fri Dec 22 17:46:59 2017 From: math at sizone.org (Ken Chase) Date: Fri, 22 Dec 2017 12:46:59 -0500 Subject: AS PATH limits In-Reply-To: <5A3D438C.3000600@foobar.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> Message-ID: <20171222174659.GK15700@sizone.org> quagga 0.99.22.4, yes i need to upgrade, as my other router on 0.99.23.1 seems ok. now coordinating with customers to get it upgraded is a different issue. /kc On Fri, Dec 22, 2017 at 05:40:28PM +0000, Nick Hilliard said: >What router software version are you running that barfs on long as-paths? > >Nick > >Ken Chase wrote: >> And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the >> router that fed us the long route, so I cant tell what it was (since we never >> consumed it before barfing). >> >> Let's hope for no more over holiday season... >> >> /kc >> >> >> On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said: >> > It is happening AGAIN. >> > >> >And of course it started on a friday aft 15 min before quittin' time in EDT: >> > >> >Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 >> > >> >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 >262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262 >197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 26 >2197 262197 262197 262197 262197 262197 262197 262197 262197 ? >> > >> >/kc >> >-- >> >Ken Chase - math at sizone.org Guelph Canada >> From cscora at apnic.net Fri Dec 22 18:02:48 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Dec 2017 04:02:48 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171222180248.C27C8C517@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Dec, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 676712 Prefixes after maximum aggregation (per Origin AS): 263365 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 327650 Total ASes present in the Internet Routing Table: 59421 Prefixes per ASN: 11.39 Origin-only ASes present in the Internet Routing Table: 51300 Origin ASes announcing only one prefix: 22596 Transit ASes present in the Internet Routing Table: 8121 Transit-only ASes present in the Internet Routing Table: 251 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 79 Number of instances of unregistered ASNs: 79 Number of 32-bit ASNs allocated by the RIRs: 20993 Number of 32-bit ASNs visible in the Routing Table: 16811 Prefixes from 32-bit ASNs in the Routing Table: 69214 Number of bogon 32-bit ASNs visible in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 329 Number of addresses announced to Internet: 2859271842 Equivalent to 170 /8s, 109 /16s and 6 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 224135 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 185943 Total APNIC prefixes after maximum aggregation: 53409 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 185047 Unique aggregates announced from the APNIC address blocks: 77442 APNIC Region origin ASes present in the Internet Routing Table: 8547 APNIC Prefixes per ASN: 21.65 APNIC Region origin ASes announcing only one prefix: 2408 APNIC Region transit ASes present in the Internet Routing Table: 1245 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3421 Number of APNIC addresses announced to Internet: 770053922 Equivalent to 45 /8s, 230 /16s and 23 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202379 Total ARIN prefixes after maximum aggregation: 97452 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203716 Unique aggregates announced from the ARIN address blocks: 95500 ARIN Region origin ASes present in the Internet Routing Table: 18029 ARIN Prefixes per ASN: 11.30 ARIN Region origin ASes announcing only one prefix: 6674 ARIN Region transit ASes present in the Internet Routing Table: 1779 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2281 Number of ARIN addresses announced to Internet: 1106986784 Equivalent to 65 /8s, 251 /16s and 71 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 182847 Total RIPE prefixes after maximum aggregation: 89132 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 178751 Unique aggregates announced from the RIPE address blocks: 107603 RIPE Region origin ASes present in the Internet Routing Table: 24765 RIPE Prefixes per ASN: 7.22 RIPE Region origin ASes announcing only one prefix: 11320 RIPE Region transit ASes present in the Internet Routing Table: 3518 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6513 Number of RIPE addresses announced to Internet: 713948800 Equivalent to 42 /8s, 141 /16s and 254 /24s 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, 64396-64495 196608-207259 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: 87520 Total LACNIC prefixes after maximum aggregation: 19386 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 88799 Unique aggregates announced from the LACNIC address blocks: 39619 LACNIC Region origin ASes present in the Internet Routing Table: 6686 LACNIC Prefixes per ASN: 13.28 LACNIC Region origin ASes announcing only one prefix: 1824 LACNIC Region transit ASes present in the Internet Routing Table: 1240 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4209 Number of LACNIC addresses announced to Internet: 172723424 Equivalent to 10 /8s, 75 /16s and 140 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17942 Total AfriNIC prefixes after maximum aggregation: 3926 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 20070 Unique aggregates announced from the AfriNIC address blocks: 7218 AfriNIC Region origin ASes present in the Internet Routing Table: 1113 AfriNIC Prefixes per ASN: 18.03 AfriNIC Region origin ASes announcing only one prefix: 369 AfriNIC Region transit ASes present in the Internet Routing Table: 218 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 387 Number of AfriNIC addresses announced to Internet: 95150080 Equivalent to 5 /8s, 171 /16s and 224 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5425 4194 86 ERX-CERNET-BKB China Education and Rese 7545 3271 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2839 11130 762 KIXS-AS-KR Korea Telecom, KR 17974 2782 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2765 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2561 1530 154 VNPT-AS-VN VNPT Corp, VN 7552 2429 1158 56 VIETEL-AS-AP Viettel Group, VN 9394 2168 4923 26 CTTNET China TieTong Telecommunications 9808 2112 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2086 417 211 TATACOMM-AS TATA Communications formerl 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 6327 3341 1323 86 SHAW - Shaw Communications Inc., CA 22773 3307 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2169 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2066 2324 465 CHARTER-NET-HKY-NC - Charter Communicat 16509 1985 4081 581 AMAZON-02 - Amazon.com, Inc., US 6389 1960 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1943 5063 648 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1865 332 247 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1700 233 579 CABLEONE - CABLE ONE, INC., US 7018 1670 20197 1242 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3519 186 23 ALJAWWALSTC-AS, SA 20940 2857 848 2060 AKAMAI-ASN1, US 8551 2480 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2082 1809 683 ROSTELECOM-AS, RU 34984 2043 331 452 TELLCOM-AS, TR 12479 1975 1068 127 UNI2-AS, ES 9121 1932 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1225 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 3651 3467 600 Uninet S.A. de C.V., MX 10620 3578 539 261 Telmex Colombia S.A., CO 11830 2630 370 66 Instituto Costarricense de Electricidad 6503 1617 437 53 Axtel, S.A.B. de C.V., MX 7303 1498 1022 194 Telecom Argentina S.A., AR 6147 1193 377 27 Telefonica del Peru S.A.A., PE 28573 1022 2259 189 CLARO S.A., BR 3816 1015 509 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 920 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1196 398 48 LINKdotNET-AS, EG 37611 779 91 8 Afrihost, ZA 36903 737 370 135 MT-MPLS, MA 36992 678 1383 31 ETISALAT-MISR, EG 8452 526 1730 18 TE-AS TE-AS, EG 24835 515 850 15 RAYA-AS, EG 29571 444 36 13 CITelecom-AS, CI 37492 435 367 77 ORANGE-, TN 37342 356 32 1 MOVITEL, MZ 15399 349 35 7 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5425 4194 86 ERX-CERNET-BKB China Education and Rese 8151 3651 3467 600 Uninet S.A. de C.V., MX 10620 3578 539 261 Telmex Colombia S.A., CO 39891 3519 186 23 ALJAWWALSTC-AS, SA 6327 3341 1323 86 SHAW - Shaw Communications Inc., CA 22773 3307 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3271 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 20940 2857 848 2060 AKAMAI-ASN1, US 4766 2839 11130 762 KIXS-AS-KR Korea Telecom, KR 17974 2782 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3519 3496 ALJAWWALSTC-AS, SA 10620 3578 3317 Telmex Colombia S.A., CO 6327 3341 3255 SHAW - Shaw Communications Inc., CA 22773 3307 3161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3651 3051 Uninet S.A. de C.V., MX 7545 3271 2882 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2782 2705 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2630 2564 Instituto Costarricense de Electricidad y Telec 8551 2480 2438 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 45899 2561 2407 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64609 PRIVATE 94.245.126.0/24 6584 MICROSOFT-GP-AS - Microsoft Co 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:12 /10:37 /11:99 /12:279 /13:557 /14:1089 /15:1897 /16:13408 /17:7789 /18:13677 /19:25255 /20:38926 /21:44300 /22:82564 /23:66626 /24:377942 /25:836 /26:605 /27:661 /28:36 /29:21 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3133 3341 SHAW - Shaw Communications Inc., CA 39891 2946 3519 ALJAWWALSTC-AS, SA 22773 2552 3307 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2063 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 1976 2630 Instituto Costarricense de Electricidad y Telec 8551 1944 2480 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1632 1865 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1576 3578 Telmex Colombia S.A., CO 11492 1498 1700 CABLEONE - CABLE ONE, INC., US 9121 1408 1932 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1573 2:826 4:18 5:2640 6:39 8:1094 9:1 12:1854 13:196 14:1759 15:28 16:3 17:185 18:76 20:53 21:12 23:2481 24:1922 25:2 27:2354 31:1963 32:87 35:22 36:455 37:2466 38:1465 39:171 40:101 41:3032 42:535 43:1918 44:89 45:3458 46:2911 47:191 49:1370 50:1052 51:47 52:918 54:355 55:6 56:7 57:43 58:1574 59:1005 60:380 61:1989 62:1761 63:1828 64:4640 65:2242 66:4484 67:2307 68:1192 69:3163 70:1132 71:587 72:2114 74:2695 75:392 76:423 77:1551 78:1608 79:1929 80:1464 81:1418 82:1068 83:764 84:1005 85:1980 86:492 87:1214 88:914 89:2316 90:174 91:6278 92:1032 93:2349 94:2384 95:2708 96:667 97:356 98:961 99:107 100:153 101:1532 102:10 103:16522 104:3197 105:215 106:520 107:1786 108:820 109:2898 110:1540 111:1730 112:1284 113:1389 114:1123 115:1600 116:1663 117:1637 118:2208 119:1651 120:910 121:1059 122:2414 123:1873 124:1484 125:1838 128:959 129:580 130:435 131:1636 132:593 133:193 134:987 135:221 136:449 137:458 138:1984 139:555 140:388 141:681 142:769 143:937 144:793 145:195 146:1146 147:684 148:1487 149:646 150:720 151:1002 152:754 153:306 154:973 155:745 156:744 157:741 158:597 159:1641 160:847 161:734 162:2546 163:533 164:967 165:1478 166:398 167:1349 168:3134 169:789 170:3618 171:402 172:1017 173:1917 174:842 175:771 176:1867 177:3940 178:2496 179:1142 180:2247 181:2137 182:2408 183:1034 184:894 185:11869 186:3454 187:2326 188:2646 189:1941 190:8216 191:1347 192:9720 193:5860 194:4778 195:3992 196:2319 197:1438 198:5535 199:5889 200:7252 201:4895 202:10394 203:9930 204:4560 205:2874 206:3043 207:3108 208:3998 209:3933 210:3989 211:2131 212:2918 213:2615 214:859 215:65 216:5727 217:2112 218:911 219:628 220:1734 221:980 222:743 223:1226 End of report From mike at sentex.net Fri Dec 22 19:05:31 2017 From: mike at sentex.net (Mike Tancsa) Date: Fri, 22 Dec 2017 14:05:31 -0500 Subject: AS PATH limits In-Reply-To: <20171222174659.GK15700@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <20171222174659.GK15700@sizone.org> Message-ID: <7b48c545-3774-026b-b319-819e2cb44cf9@sentex.net> On 12/22/2017 12:46 PM, Ken Chase wrote: > quagga 0.99.22.4, yes i need to upgrade, as my other > router on 0.99.23.1 seems ok. now coordinating with > customers to get it upgraded is a different issue. Will that version of quagga not support a filter list? e.g neighbor 38.xx.yy.zz filter-list maxas-limit65 in ip as-path access-list maxas-limit65 deny ^([{},0-9]+ ){65} ip as-path access-list maxas-limit65 permit .* ---Mike > > /kc > > > On Fri, Dec 22, 2017 at 05:40:28PM +0000, Nick Hilliard said: > >What router software version are you running that barfs on long as-paths? > > > >Nick > > > >Ken Chase wrote: > >> And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the > >> router that fed us the long route, so I cant tell what it was (since we never > >> consumed it before barfing). > >> > >> Let's hope for no more over holiday season... > >> > >> /kc > >> > >> > >> On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said: > >> > It is happening AGAIN. > >> > > >> >And of course it started on a friday aft 15 min before quittin' time in EDT: > >> > > >> >Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 > >> > > >> >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > >262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262 > >197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 26 > >2197 262197 262197 262197 262197 262197 262197 262197 262197 ? > >> > > >> >/kc > >> >-- > >> >Ken Chase - math at sizone.org Guelph Canada > >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From bill at herrin.us Fri Dec 22 19:30:06 2017 From: bill at herrin.us (William Herrin) Date: Fri, 22 Dec 2017 14:30:06 -0500 Subject: AS PATH limits In-Reply-To: <5A3D438C.3000600@foobar.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> Message-ID: On Fri, Dec 22, 2017 at 12:40 PM, Nick Hilliard wrote: > What router software version are you running that barfs on long as-paths? > Hi Nick, Versions of quagga up until the very most recent release corrupt the transmission of routes with very long AS paths. They add up the packet length wrong. The neighbors of any router brand then barf on the malformed data and terminate the BGP session. Your peer running quagga must either upgrade or filter long AS paths or you will receive corrupt data and terminate the BGP session. There's nothing that -you- can do about it. The AS path lengths we're talking about are unreasonable. They indicate a high probability of misconfiguration at the origin. There's no legitimate cause for them to exist on the pubic Internet at all. It would be reasonable to treat them like when peers offer /32 prefixes and just say no. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nick at foobar.org Fri Dec 22 22:45:07 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Dec 2017 22:45:07 +0000 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> Message-ID: <5A3D8AF3.1090409@foobar.org> William Herrin wrote: > The AS path lengths we're talking about are unreasonable. "unreasonable" is a peculiar word to use here :-) It's the internet and you can't expect other people not to do silly things from time to time. This is a known problem and it isn't even the first time it's been discussed on nanog-l. If you've been hit with a known service-affecting problem that can easily recur without warning and which will be service affecting if it hits again, common sense suggests that it would be a good idea to upgrade to a version of code which isn't affected. Nick From nick at foobar.org Fri Dec 22 22:48:27 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Dec 2017 22:48:27 +0000 Subject: AS PATH limits In-Reply-To: <20171222174659.GK15700@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <20171222174659.GK15700@sizone.org> Message-ID: <5A3D8BBB.7060608@foobar.org> Ken Chase wrote: > quagga 0.99.22.4, yes i need to upgrade, as my other > router on 0.99.23.1 seems ok. All unpatched versions of quagga between 0.99.2 and 1.2.2 are affected. Nick From bill at herrin.us Fri Dec 22 22:50:36 2017 From: bill at herrin.us (William Herrin) Date: Fri, 22 Dec 2017 17:50:36 -0500 Subject: AS PATH limits In-Reply-To: <5A3D8AF3.1090409@foobar.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> Message-ID: On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote: > William Herrin wrote: > > The AS path lengths we're talking about are unreasonable. > > "unreasonable" is a peculiar word to use here :-) > > It's the internet and you can't expect other people not to do silly > things from time to time. This is a known problem and it isn't even the > first time it's been discussed on nanog-l. > > If you've been hit with a known service-affecting problem that can > easily recur without warning and which will be service affecting if it > hits again, common sense suggests that it would be a good idea to > upgrade to a version of code which isn't affected. Well, that's a brilliant platitude, but what do you do when it breaks over and over until the other guy upgrades? -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From surfer at mauigateway.com Fri Dec 22 22:57:39 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 22 Dec 2017 14:57:39 -0800 Subject: AS PATH limits Message-ID: <20171222145739.2D183095@m0117565.ppops.net> --- bill at herrin.us wrote: From: William Herrin Well, that's a brilliant platitude, but what do you do when it breaks over and over until the other guy upgrades? --------------------------------------------------- Filter that network out of your tables until it's fixed? :) scott From math at sizone.org Fri Dec 22 23:04:16 2017 From: math at sizone.org (Ken Chase) Date: Fri, 22 Dec 2017 18:04:16 -0500 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> Message-ID: <20171222230416.GE21694@sizone.org> Push harder on upgrading. "Dec 30" is my earliest window I got from my customer after previously pushing with previous events (didnt help that Cogent said "yeah we agree these are silly, we'll be filtering more aggressively" -- this time it snuck in from the less busy side of our network). It's not even going to be service impacting, if we do everything correctly, but *who knows for sure* :) Course more long path events occurring ARE service impacting more than the risk during upgrade, so go figure. Customers! Cant live with em, cant afford to live without em! Nonetheless, I do think that backbones should be filtering ridiculous AS paths just as a matter of course. Everyone fix their own stuff, and everyone help the next guy downstream by stomping on sillyness. Generally been an internet mindset that I've seen since even before the great renaming... /kc On Fri, Dec 22, 2017 at 05:50:36PM -0500, William Herrin said: >On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote: > >> William Herrin wrote: >> > The AS path lengths we're talking about are unreasonable. >> >> "unreasonable" is a peculiar word to use here :-) >> >> It's the internet and you can't expect other people not to do silly >> things from time to time. This is a known problem and it isn't even the >> first time it's been discussed on nanog-l. >> >> If you've been hit with a known service-affecting problem that can >> easily recur without warning and which will be service affecting if it >> hits again, common sense suggests that it would be a good idea to >> upgrade to a version of code which isn't affected. > > >Well, that's a brilliant platitude, but what do you do when it breaks over >and over until the other guy upgrades? > >-Bill > > > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: /kc -- Ken Chase - math at sizone.org Guelph Canada From nick at foobar.org Fri Dec 22 23:11:44 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Dec 2017 23:11:44 +0000 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> Message-ID: <5A3D9130.5050204@foobar.org> William Herrin wrote: > On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote: > If you've been hit with a known service-affecting problem that can > easily recur without warning and which will be service affecting if it > hits again, common sense suggests that it would be a good idea to > upgrade to a version of code which isn't affected. > > Well, that's a brilliant platitude, but what do you do when it breaks > over and over until the other guy upgrades? I dunno, maybe shake our fists and rage a bit about the existence of service affecting bugs? It's not like we haven't all been in this position at one stage or another. The point was, though, that there's been several months since this bug was discussed on nanog-l way back in balmy september, and given the fact that it can completely wipe out connectivity without warning for those affected, it would have been a good idea to deal with the problem in an orderly way at the time rather than letting it interfere with eggnog and seasonal good cheer, at one of the times of year where chunks of the world are busy taking well-deserved holidays. On which point, seasonal cheers to all. Nick From nanog at jima.us Fri Dec 22 23:20:42 2017 From: nanog at jima.us (Jima) Date: Fri, 22 Dec 2017 16:20:42 -0700 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <5EDA47D5-A458-44D0-A130-158FD0422AA1@beckman.org> <368248B8-DDBA-4DDA-9246-C7E0D54C59CE@isc.org> <7406A46A-270B-45DD-993A-EE628EDE51DF@isc.org> Message-ID: On 2017-12-21 08:58, Christopher Morrow wrote: > On Thu, Dec 21, 2017 at 10:16 AM, Jason Iannone > wrote: > >> M&A plays into this too. By my calculations, CenturyLink controls at >> least 17 million /48s. How many sites does CenturyLink provide >> service to? I'm gonna go out on a limb and say it's not 17 million. >> > > there are less than 17m households served by centurylink's residential > product? really? > each of those could be considered a site and then get a /48. Speaking non-hypothetically, there's some shoddy network address management at play there. I can state for a fact that there's at least one /48 (and I imagine many more) in Jason's list that hasn't been valid for over three years. The IPv4 side of that circuit (a /25) is also still SWIP'd -- not that it's meaningfully usable in the DFZ. Therein lies a (minor, I hope) flaw in Job Snijders' proposal to use ARIN OriginAS data for determining routing authorization: ISPs have to not suck at cleaning up SWIP entries for dormant circuits. I (as a customer) tried to get my employer's entries removed three months ago, but no one cared enough to follow up. (Also, I doubt the vast majority of CenturyLink's residential customer base a) has non-tunneled IPv6 or b) receives a /48.) If anyone from AS209 wants to clean up those SWIPs, they're welcome to ping me off-list. :-) - Jima From math at sizone.org Fri Dec 22 23:27:08 2017 From: math at sizone.org (Ken Chase) Date: Fri, 22 Dec 2017 18:27:08 -0500 Subject: AS PATH limits In-Reply-To: <5A3D9130.5050204@foobar.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> <5A3D9130.5050204@foobar.org> Message-ID: <20171222232708.GG21694@sizone.org> Ive found some other stuff that's totally busted, but screw those who havent patched their systems. We should not help them at all as knowlegeable stewards of big chunks of bandwidth, we should just write stuff about how silly they are instead: https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf read the first table on page 3 and then explain the philosophy of not caring about this as a general issue affecting the entire internet. That's not, to date, been the attitude I've seen in here or elsewhere amongst admins, and I dont see why we should start now. (And I'd fix it _right now_, but it's at my major customer's discretion. I've explained the risks, he's taken them to heart. He too is an actual seasoned admin (with quagga experience), but turned off his AS least year and got out of the game. He has his reasons for waiting a bit longer.) /kc On Fri, Dec 22, 2017 at 11:11:44PM +0000, Nick Hilliard said: >William Herrin wrote: >> On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote: >> If you've been hit with a known service-affecting problem that can >> easily recur without warning and which will be service affecting if it >> hits again, common sense suggests that it would be a good idea to >> upgrade to a version of code which isn't affected. >> >> Well, that's a brilliant platitude, but what do you do when it breaks >> over and over until the other guy upgrades? > >I dunno, maybe shake our fists and rage a bit about the existence of >service affecting bugs? It's not like we haven't all been in this >position at one stage or another. > >The point was, though, that there's been several months since this bug >was discussed on nanog-l way back in balmy september, and given the fact >that it can completely wipe out connectivity without warning for those >affected, it would have been a good idea to deal with the problem in an >orderly way at the time rather than letting it interfere with eggnog and >seasonal good cheer, at one of the times of year where chunks of the >world are busy taking well-deserved holidays. > >On which point, seasonal cheers to all. > >Nick > -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From bill at herrin.us Fri Dec 22 23:50:50 2017 From: bill at herrin.us (William Herrin) Date: Fri, 22 Dec 2017 18:50:50 -0500 Subject: AS PATH limits In-Reply-To: <20171222145739.2D183095@m0117565.ppops.net> References: <20171222145739.2D183095@m0117565.ppops.net> Message-ID: On Fri, Dec 22, 2017 at 5:57 PM, Scott Weeks wrote: > Well, that's a brilliant platitude, but what do you do > when it breaks over and over until the other guy upgrades? > --------------------------------------------------- > > > Filter that network out of your tables until it's fixed? :) Good luck with that since the BGP session collapses in the process of receiving that corrupted data. That's the bug. The other guy's router could filter the prefix but if he doesn't he fouls the BGP session to everybody he tries to peer it to. Regards. Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nick at foobar.org Sat Dec 23 00:00:55 2017 From: nick at foobar.org (Nick Hilliard) Date: Sat, 23 Dec 2017 00:00:55 +0000 Subject: AS PATH limits In-Reply-To: <20171222232708.GG21694@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> <5A3D9130.5050204@foobar.org> <20171222232708.GG21694@sizone.org> Message-ID: <5A3D9CB7.60102@foobar.org> Ken Chase wrote: > (And I'd fix it _right now_, but it's at my major customer's > discretion. ok, so this is a customer management problem. If this is the only customer on that router, then ok, if they want to continue putting themselves at risk of service loss, I guess that would be their concern. If there's anyone else connected to this router, then you would probably want to consider moving them off it, because you seem to have said that you may not have full control of your business assets. If this is the case, it isn't a good situation to be in and will lead to issues like this turning into serious longer term problems. > read the first table on page 3 and then explain the philosophy of > not caring about this as a general issue affecting the entire > internet. That's not, to date, been the attitude I've seen in here or > elsewhere amongst admins, and I dont see why we should start now. Globally, there are 59000 ASNs announcing a total of 670k ipv4 prefixes and 45k ipv6 routes. If any one of those prefixes is announced anywhere in the world with an oddball as-path, then this puts vulnerable versions of quagga at risk of service loss. This isn't about sympathy or caring or not caring or anything else, but the uncomfortable fact that with a pool this large, mistakes are going to happen from time to time, whether we like it or not. It's as-path length this time, but on previous occasions it's been attribute size, or incorrect attribute combos or, well, a small catalog of other problems that have caused bgp session failure globally over the years. It's each of our responsibility to ensure that our systems are resistant to problems like this, not other peoples' responsibility to ensure that our networks don't get hit by third party misconfigs. Nick From baldur.norddahl at gmail.com Sat Dec 23 15:21:56 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 23 Dec 2017 16:21:56 +0100 Subject: AS PATH limits In-Reply-To: <5A3D9CB7.60102@foobar.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> <20171222154457.GF6349@sizone.org> <5A3D438C.3000600@foobar.org> <5A3D8AF3.1090409@foobar.org> <5A3D9130.5050204@foobar.org> <20171222232708.GG21694@sizone.org> <5A3D9CB7.60102@foobar.org> Message-ID: Den 23. dec. 2017 01.02 skrev "Nick Hilliard" : This isn't about sympathy or caring or not caring or anything else, but the uncomfortable fact that with a pool this large, mistakes are going to happen from time to time, whether we like it or not. It is not even a mistake but just some uninformed guy thinking I really want this to be a path of last resort, so I will write a real large number in this field. From Sam at SanDiegoBroadband.com Tue Dec 26 18:12:43 2017 From: Sam at SanDiegoBroadband.com (Sam Norris) Date: Tue, 26 Dec 2017 10:12:43 -0800 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> Message-ID: <002701d37e75$21705640$645102c0$@SanDiegoBroadband.com> Anyone figure this out? I need to get our prefixes updated as well as they are detecting our customers in the wrong city. Sam > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > lists at silverlakeinternet.com > Sent: Wednesday, December 20, 2017 1:28 PM > To: Mike Hammett > Cc: nanog at nanog.org > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > > I could use a contact for all of these as well. I have been trying to > get my subnet unblocked with all of these providers and have reached out > in many ways to all of them over the past few months, but never get a > response. > > Thank you, > Brett A Mansfield > > On 2017-12-15 19:57, Mike Hammett wrote: > > Bump for Hulu. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Michael Crapse" > > To: nanog at nanog.org > > Sent: Wednesday, December 6, 2017 3:38:20 PM > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others > > > > I am a local WISP. And my customers have trouble reaching Hulu, Disney > > now, > > and previously netflix and amazon prime(both resolved). > > I have emailed, mailed, and called both HULU and Disney now to get my > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) > > from > > their services. They have replied saying it takes 3-5 days to resolve > > the > > issue, that was several weeks ago. Can i get contact from those two > > services that can help my customers reach their services, thank you. > > > > > > Thank you for the help. > > -Michael From michael at wi-fiber.io Tue Dec 26 19:41:57 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 26 Dec 2017 12:41:57 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <002701d37e75$21705640$645102c0$@SanDiegoBroadband.com> References: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> <002701d37e75$21705640$645102c0$@SanDiegoBroadband.com> Message-ID: I would like to know, Is there any legal recourse we can take against such a company consistently ignoring whitelist requests? Currently, the only way my customers can connect to hulu without getting a vpn error is by using a vpn. On my end, i have just started NATing all requests to HULU through the few good IPs that I have. On 26 December 2017 at 11:12, Sam Norris wrote: > Anyone figure this out? I need to get our prefixes updated as well as > they are > detecting our customers in the wrong city. > > Sam > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > > lists at silverlakeinternet.com > > Sent: Wednesday, December 20, 2017 1:28 PM > > To: Mike Hammett > > Cc: nanog at nanog.org > > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > > > > I could use a contact for all of these as well. I have been trying to > > get my subnet unblocked with all of these providers and have reached out > > in many ways to all of them over the past few months, but never get a > > response. > > > > Thank you, > > Brett A Mansfield > > > > On 2017-12-15 19:57, Mike Hammett wrote: > > > Bump for Hulu. > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > > > > Midwest Internet Exchange > > > > > > The Brothers WISP > > > > > > ----- Original Message ----- > > > > > > From: "Michael Crapse" > > > To: nanog at nanog.org > > > Sent: Wednesday, December 6, 2017 3:38:20 PM > > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others > > > > > > I am a local WISP. And my customers have trouble reaching Hulu, Disney > > > now, > > > and previously netflix and amazon prime(both resolved). > > > I have emailed, mailed, and called both HULU and Disney now to get my > > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) > > > from > > > their services. They have replied saying it takes 3-5 days to resolve > > > the > > > issue, that was several weeks ago. Can i get contact from those two > > > services that can help my customers reach their services, thank you. > > > > > > > > > Thank you for the help. > > > -Michael > > From dmburgess at linktechs.net Tue Dec 26 21:31:38 2017 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 26 Dec 2017 21:31:38 +0000 Subject: mailchimp contact Message-ID: <99827676adc242d7a3c7ee3bd979184c@linktechs.net> Would a MailChimp contact pelase hit me off-list :) Dennis Burgess - Network Solution Engineer - Consultant MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE For Wireless Hardware/Routers visit www.linktechs.net Radio Frequency Coverages: www.towercoverage.com Office: 314-735-0270 E-Mail: dmburgess at linktechs.net From marka at isc.org Tue Dec 26 21:49:57 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Dec 2017 08:49:57 +1100 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> <002701d37e75$21705640$645102c0$@SanDiegoBroadband.com> Message-ID: Talk to your lawyers. They should be able to advise you if there is legal remedy or not and if so what the chances of success are and some estimate of the costs of pursuing action. Mark -- Mark Andrews > On 27 Dec 2017, at 06:41, Michael Crapse wrote: > > I would like to know, Is there any legal recourse we can take against such > a company consistently ignoring whitelist requests? > Currently, the only way my customers can connect to hulu without getting a > vpn error is by using a vpn. On my end, i have just started NATing all > requests to HULU through the few good IPs that I have. > >> On 26 December 2017 at 11:12, Sam Norris wrote: >> >> Anyone figure this out? I need to get our prefixes updated as well as >> they are >> detecting our customers in the wrong city. >> >> Sam >> >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of >>> lists at silverlakeinternet.com >>> Sent: Wednesday, December 20, 2017 1:28 PM >>> To: Mike Hammett >>> Cc: nanog at nanog.org >>> Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others >>> >>> I could use a contact for all of these as well. I have been trying to >>> get my subnet unblocked with all of these providers and have reached out >>> in many ways to all of them over the past few months, but never get a >>> response. >>> >>> Thank you, >>> Brett A Mansfield >>> >>>> On 2017-12-15 19:57, Mike Hammett wrote: >>>> Bump for Hulu. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> >>>> Midwest Internet Exchange >>>> >>>> The Brothers WISP >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Michael Crapse" >>>> To: nanog at nanog.org >>>> Sent: Wednesday, December 6, 2017 3:38:20 PM >>>> Subject: Geolocation: IPv4 Subnet blocked by HULU, and others >>>> >>>> I am a local WISP. And my customers have trouble reaching Hulu, Disney >>>> now, >>>> and previously netflix and amazon prime(both resolved). >>>> I have emailed, mailed, and called both HULU and Disney now to get my >>>> 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) >>>> from >>>> their services. They have replied saying it takes 3-5 days to resolve >>>> the >>>> issue, that was several weeks ago. Can i get contact from those two >>>> services that can help my customers reach their services, thank you. >>>> >>>> >>>> Thank you for the help. >>>> -Michael >> >> From johnl at iecc.com Tue Dec 26 23:24:26 2017 From: johnl at iecc.com (John Levine) Date: 26 Dec 2017 18:24:26 -0500 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: Message-ID: <20171226232426.EC603188A177@ary.local> In article you write: >I would like to know, Is there any legal recourse we can take against such >a company consistently ignoring whitelist requests? Is there some reason you believe that Hulu has a legal duty to provide old TV shows to your users? There are laws about discriminating against protected classes like racial or religious minorities but I am fairly sure that "random subscribers of some ISP in Utah" is not such a class." Also, many people will tell you that waving lawyers at a big company very rarely ends well. It is unlikely that Hulu actually doesn't want your users' business and far more likely that there is a bug somewhere in updating IP masks or the like. When you did experiments to see where the big geolocation companies think your networks are (Maxmind, Google, etc.) what did you find? R's, John From kmedcalf at dessus.com Wed Dec 27 01:54:26 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 26 Dec 2017 18:54:26 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: Message-ID: <5163e042afb26144b215995bc2e769ab@mail.dessus.com> No, because you have no cause of action known to law. You are not a customer of Hulu and have no right of action. However, your "users" could sue you for failing to provide proper service or perhaps otherwise cause you to suffer damages. In the former case you could file a defense and cross-claim against Hulu claiming that it is their problem, and that not only are they responsible for the claims made against you, they are also liable for your costs and so on and so forth. In the latter case where you suffer damages as a result of Hulu's actions (or inactions) resulting in damage to you, you could sue them on the basis of tortuous interference for their actions. Of course, Hulu will simply claim that you are negligent and just in case file a third party claim against whomever is providing them with false information and thus tortuously interfering with their business. Over the course of the following several years nothing will be done to correct the issue, your customers will abandon you and go elsewhere, and in the end no one will get anywhere except the lawyers who will now be able to afford to buy a few more yachts each. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael >Crapse >Sent: Tuesday, 26 December, 2017 12:42 >To: Sam Norris >Cc: NANOG list >Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > >I would like to know, Is there any legal recourse we can take against >such >a company consistently ignoring whitelist requests? >Currently, the only way my customers can connect to hulu without >getting a >vpn error is by using a vpn. On my end, i have just started NATing >all >requests to HULU through the few good IPs that I have. > >On 26 December 2017 at 11:12, Sam Norris >wrote: > >> Anyone figure this out? I need to get our prefixes updated as well >as >> they are >> detecting our customers in the wrong city. >> >> Sam >> >> >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of >> > lists at silverlakeinternet.com >> > Sent: Wednesday, December 20, 2017 1:28 PM >> > To: Mike Hammett >> > Cc: nanog at nanog.org >> > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others >> > >> > I could use a contact for all of these as well. I have been >trying to >> > get my subnet unblocked with all of these providers and have >reached out >> > in many ways to all of them over the past few months, but never >get a >> > response. >> > >> > Thank you, >> > Brett A Mansfield >> > >> > On 2017-12-15 19:57, Mike Hammett wrote: >> > > Bump for Hulu. >> > > >> > > >> > > >> > > >> > > ----- >> > > Mike Hammett >> > > Intelligent Computing Solutions >> > > >> > > Midwest Internet Exchange >> > > >> > > The Brothers WISP >> > > >> > > ----- Original Message ----- >> > > >> > > From: "Michael Crapse" >> > > To: nanog at nanog.org >> > > Sent: Wednesday, December 6, 2017 3:38:20 PM >> > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others >> > > >> > > I am a local WISP. And my customers have trouble reaching Hulu, >Disney >> > > now, >> > > and previously netflix and amazon prime(both resolved). >> > > I have emailed, mailed, and called both HULU and Disney now to >get my >> > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer >so) >> > > from >> > > their services. They have replied saying it takes 3-5 days to >resolve >> > > the >> > > issue, that was several weeks ago. Can i get contact from those >two >> > > services that can help my customers reach their services, thank >you. >> > > >> > > >> > > Thank you for the help. >> > > -Michael >> >> From michael at wi-fiber.io Wed Dec 27 02:03:27 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 26 Dec 2017 19:03:27 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <5163e042afb26144b215995bc2e769ab@mail.dessus.com> References: <5163e042afb26144b215995bc2e769ab@mail.dessus.com> Message-ID: I was being playful with the whole "law" thing. I doubt the users would be able to sue me due to title 2 roll backs. "Net Neutrality" allows ISPs to block any service they deem fit, right? So the first step wouldn't even get past discovery to get to court. Anyhow, it would be sufficiently beneficial if we just had a single contact within hulu. It would be even better if hulu came into the 21st century and supported IPv6 like any other modern service. For others who need this resolved for hulu, these are the subnets I NATed/VPNed to get it working. 8.28.124.0/23 23.0.0.0/8 184.84.0.0/14 199.60.116.0/24 199.127.192.0/22 199.200.48.0/22 208.91.156.0/22 208.98.171.96/27 Michael On 26 December 2017 at 18:54, Keith Medcalf wrote: > > No, because you have no cause of action known to law. You are not a > customer of Hulu and have no right of action. > > However, your "users" could sue you for failing to provide proper service > or perhaps otherwise cause you to suffer damages. > > In the former case you could file a defense and cross-claim against Hulu > claiming that it is their problem, and that not only are they responsible > for the claims made against you, they are also liable for your costs and so > on and so forth. > > In the latter case where you suffer damages as a result of Hulu's actions > (or inactions) resulting in damage to you, you could sue them on the basis > of tortuous interference for their actions. > > Of course, Hulu will simply claim that you are negligent and just in case > file a third party claim against whomever is providing them with false > information and thus tortuously interfering with their business. > > Over the course of the following several years nothing will be done to > correct the issue, your customers will abandon you and go elsewhere, and in > the end no one will get anywhere except the lawyers who will now be able to > afford to buy a few more yachts each. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael > >Crapse > >Sent: Tuesday, 26 December, 2017 12:42 > >To: Sam Norris > >Cc: NANOG list > >Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > > > >I would like to know, Is there any legal recourse we can take against > >such > >a company consistently ignoring whitelist requests? > >Currently, the only way my customers can connect to hulu without > >getting a > >vpn error is by using a vpn. On my end, i have just started NATing > >all > >requests to HULU through the few good IPs that I have. > > > >On 26 December 2017 at 11:12, Sam Norris > >wrote: > > > >> Anyone figure this out? I need to get our prefixes updated as well > >as > >> they are > >> detecting our customers in the wrong city. > >> > >> Sam > >> > >> > >> > -----Original Message----- > >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > >> > lists at silverlakeinternet.com > >> > Sent: Wednesday, December 20, 2017 1:28 PM > >> > To: Mike Hammett > >> > Cc: nanog at nanog.org > >> > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > >> > > >> > I could use a contact for all of these as well. I have been > >trying to > >> > get my subnet unblocked with all of these providers and have > >reached out > >> > in many ways to all of them over the past few months, but never > >get a > >> > response. > >> > > >> > Thank you, > >> > Brett A Mansfield > >> > > >> > On 2017-12-15 19:57, Mike Hammett wrote: > >> > > Bump for Hulu. > >> > > > >> > > > >> > > > >> > > > >> > > ----- > >> > > Mike Hammett > >> > > Intelligent Computing Solutions > >> > > > >> > > Midwest Internet Exchange > >> > > > >> > > The Brothers WISP > >> > > > >> > > ----- Original Message ----- > >> > > > >> > > From: "Michael Crapse" > >> > > To: nanog at nanog.org > >> > > Sent: Wednesday, December 6, 2017 3:38:20 PM > >> > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others > >> > > > >> > > I am a local WISP. And my customers have trouble reaching Hulu, > >Disney > >> > > now, > >> > > and previously netflix and amazon prime(both resolved). > >> > > I have emailed, mailed, and called both HULU and Disney now to > >get my > >> > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer > >so) > >> > > from > >> > > their services. They have replied saying it takes 3-5 days to > >resolve > >> > > the > >> > > issue, that was several weeks ago. Can i get contact from those > >two > >> > > services that can help my customers reach their services, thank > >you. > >> > > > >> > > > >> > > Thank you for the help. > >> > > -Michael > >> > >> > > > > From nanog at ics-il.net Wed Dec 27 15:53:11 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 27 Dec 2017 09:53:11 -0600 (CST) Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <5163e042afb26144b215995bc2e769ab@mail.dessus.com> Message-ID: <1372824491.7984.1514389986370.JavaMail.mhammett@ThunderFuck> "Net Neutrality" - where only one party in the flow of bits could *possibly* be negligent, malicious, etc. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Michael Crapse" To: "Keith Medcalf" Cc: nanog at nanog.org Sent: Tuesday, December 26, 2017 8:03:27 PM Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others I was being playful with the whole "law" thing. I doubt the users would be able to sue me due to title 2 roll backs. "Net Neutrality" allows ISPs to block any service they deem fit, right? So the first step wouldn't even get past discovery to get to court. Anyhow, it would be sufficiently beneficial if we just had a single contact within hulu. It would be even better if hulu came into the 21st century and supported IPv6 like any other modern service. For others who need this resolved for hulu, these are the subnets I NATed/VPNed to get it working. 8.28.124.0/23 23.0.0.0/8 184.84.0.0/14 199.60.116.0/24 199.127.192.0/22 199.200.48.0/22 208.91.156.0/22 208.98.171.96/27 Michael On 26 December 2017 at 18:54, Keith Medcalf wrote: > > No, because you have no cause of action known to law. You are not a > customer of Hulu and have no right of action. > > However, your "users" could sue you for failing to provide proper service > or perhaps otherwise cause you to suffer damages. > > In the former case you could file a defense and cross-claim against Hulu > claiming that it is their problem, and that not only are they responsible > for the claims made against you, they are also liable for your costs and so > on and so forth. > > In the latter case where you suffer damages as a result of Hulu's actions > (or inactions) resulting in damage to you, you could sue them on the basis > of tortuous interference for their actions. > > Of course, Hulu will simply claim that you are negligent and just in case > file a third party claim against whomever is providing them with false > information and thus tortuously interfering with their business. > > Over the course of the following several years nothing will be done to > correct the issue, your customers will abandon you and go elsewhere, and in > the end no one will get anywhere except the lawyers who will now be able to > afford to buy a few more yachts each. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael > >Crapse > >Sent: Tuesday, 26 December, 2017 12:42 > >To: Sam Norris > >Cc: NANOG list > >Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > > > >I would like to know, Is there any legal recourse we can take against > >such > >a company consistently ignoring whitelist requests? > >Currently, the only way my customers can connect to hulu without > >getting a > >vpn error is by using a vpn. On my end, i have just started NATing > >all > >requests to HULU through the few good IPs that I have. > > > >On 26 December 2017 at 11:12, Sam Norris > >wrote: > > > >> Anyone figure this out? I need to get our prefixes updated as well > >as > >> they are > >> detecting our customers in the wrong city. > >> > >> Sam > >> > >> > >> > -----Original Message----- > >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > >> > lists at silverlakeinternet.com > >> > Sent: Wednesday, December 20, 2017 1:28 PM > >> > To: Mike Hammett > >> > Cc: nanog at nanog.org > >> > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > >> > > >> > I could use a contact for all of these as well. I have been > >trying to > >> > get my subnet unblocked with all of these providers and have > >reached out > >> > in many ways to all of them over the past few months, but never > >get a > >> > response. > >> > > >> > Thank you, > >> > Brett A Mansfield > >> > > >> > On 2017-12-15 19:57, Mike Hammett wrote: > >> > > Bump for Hulu. > >> > > > >> > > > >> > > > >> > > > >> > > ----- > >> > > Mike Hammett > >> > > Intelligent Computing Solutions > >> > > > >> > > Midwest Internet Exchange > >> > > > >> > > The Brothers WISP > >> > > > >> > > ----- Original Message ----- > >> > > > >> > > From: "Michael Crapse" > >> > > To: nanog at nanog.org > >> > > Sent: Wednesday, December 6, 2017 3:38:20 PM > >> > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and others > >> > > > >> > > I am a local WISP. And my customers have trouble reaching Hulu, > >Disney > >> > > now, > >> > > and previously netflix and amazon prime(both resolved). > >> > > I have emailed, mailed, and called both HULU and Disney now to > >get my > >> > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer > >so) > >> > > from > >> > > their services. They have replied saying it takes 3-5 days to > >resolve > >> > > the > >> > > issue, that was several weeks ago. Can i get contact from those > >two > >> > > services that can help my customers reach their services, thank > >you. > >> > > > >> > > > >> > > Thank you for the help. > >> > > -Michael > >> > >> > > > > From kmedcalf at dessus.com Wed Dec 27 17:54:56 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 27 Dec 2017 10:54:56 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: Message-ID: <7ceb8e3eecb76647bf4d420eeba91ede@mail.dessus.com> Title II is not particularly relevant. It merely permits a claim of the form "Carriage must be provided without discrimination to everyone who pays the fee for carriage. I have paid the fee for carriage, but I am suffering discrimination in the provision of carriage as prohibited by Title II parts such and so". In other words, it merely provides a lazy way for lazy lawyers to make lazy claims without having to think about what they are doing. Since they get another new yacht whether they win or lose, it does not really matter to most of them if they do a bang up job or a shoddy one. In any case, it is a stupid claim. You are not discriminating in carriage, even if Title II were still in force. You are providing non-discriminatory carriage and some other third party is tortuously interfering with a contract. In any case, the entire result would turn on what you do in defense. If you are a schmuck then you simply move for summary judgement on the basis that you are providing carriage and that it is another party that is fracked up, and you, through the goodness of your kind heart, tried to solve the issue on behalf of the complainant, to no effect. Then the complainant has to launch another lawsuit against the correct parties. This could go on for quite a while before managing to hit the correct party -- more likely it would never get anywhere at all. Alternatively, you could make the same defense and cross-claim against all the parties who should have been in the original action. The originating claim needs to be brought against all the possible bad actors simultaneously and the claims plead properly. This would require a lawyer that can think -- something very rare. It would be somewhat expensive and delicate, but it would have certain success. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: Michael Crapse [mailto:michael at wi-fiber.io] >Sent: Tuesday, 26 December, 2017 19:03 >To: Keith Medcalf >Cc: nanog at nanog.org >Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others > >I was being playful with the whole "law" thing. >I doubt the users would be able to sue me due to title 2 roll backs. >"Net Neutrality" allows ISPs to block any service they deem fit, >right? So the first step wouldn't even get past discovery to get to >court. Anyhow, it would be sufficiently beneficial if we just had a >single contact within hulu. It would be even better if hulu came into >the 21st century and supported IPv6 like any other modern service. >For others who need this resolved for hulu, these are the subnets I >NATed/VPNed to get it working. >8.28.124.0/23 >23.0.0.0/8 > >184.84.0.0/14 > >199.60.116.0/24 >199.127.192.0/22 >199.200.48.0/22 >208.91.156.0/22 >208.98.171.96/27 > > >Michael > >On 26 December 2017 at 18:54, Keith Medcalf >wrote: > > > > No, because you have no cause of action known to law. You are >not a customer of Hulu and have no right of action. > > However, your "users" could sue you for failing to provide >proper service or perhaps otherwise cause you to suffer damages. > > In the former case you could file a defense and cross-claim >against Hulu claiming that it is their problem, and that not only are >they responsible for the claims made against you, they are also >liable for your costs and so on and so forth. > > In the latter case where you suffer damages as a result of >Hulu's actions (or inactions) resulting in damage to you, you could >sue them on the basis of tortuous interference for their actions. > > Of course, Hulu will simply claim that you are negligent and >just in case file a third party claim against whomever is providing >them with false information and thus tortuously interfering with >their business. > > Over the course of the following several years nothing will be >done to correct the issue, your customers will abandon you and go >elsewhere, and in the end no one will get anywhere except the lawyers >who will now be able to afford to buy a few more yachts each. > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org bounces at nanog.org> ] On Behalf Of Michael > >Crapse > >Sent: Tuesday, 26 December, 2017 12:42 > >To: Sam Norris > >Cc: NANOG list > >Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and >others > > > >I would like to know, Is there any legal recourse we can take >against > >such > >a company consistently ignoring whitelist requests? > >Currently, the only way my customers can connect to hulu >without > >getting a > >vpn error is by using a vpn. On my end, i have just started >NATing > >all > >requests to HULU through the few good IPs that I have. > > > >On 26 December 2017 at 11:12, Sam Norris > > >wrote: > > > >> Anyone figure this out? I need to get our prefixes updated >as well > >as > >> they are > >> detecting our customers in the wrong city. > >> > >> Sam > >> > >> > >> > -----Original Message----- > >> > From: NANOG [mailto:nanog-bounces at nanog.org bounces at nanog.org> ] On Behalf Of > >> > lists at silverlakeinternet.com > >> > Sent: Wednesday, December 20, 2017 1:28 PM > >> > To: Mike Hammett > >> > Cc: nanog at nanog.org > >> > Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and >others > >> > > >> > I could use a contact for all of these as well. I have >been > >trying to > >> > get my subnet unblocked with all of these providers and >have > >reached out > >> > in many ways to all of them over the past few months, but >never > >get a > >> > response. > >> > > >> > Thank you, > >> > Brett A Mansfield > >> > > >> > On 2017-12-15 19:57, Mike Hammett wrote: > >> > > Bump for Hulu. > >> > > > >> > > > >> > > > >> > > > >> > > ----- > >> > > Mike Hammett > >> > > Intelligent Computing Solutions > >> > > > >> > > Midwest Internet Exchange > >> > > > >> > > The Brothers WISP > >> > > > >> > > ----- Original Message ----- > >> > > > >> > > From: "Michael Crapse" > >> > > To: nanog at nanog.org > >> > > Sent: Wednesday, December 6, 2017 3:38:20 PM > >> > > Subject: Geolocation: IPv4 Subnet blocked by HULU, and >others > >> > > > >> > > I am a local WISP. And my customers have trouble reaching >Hulu, > >Disney > >> > > now, > >> > > and previously netflix and amazon prime(both resolved). > >> > > I have emailed, mailed, and called both HULU and Disney >now to > >get my > >> > > 196.53.96.0/22 subnet unblacklisted as a VPN provider(no >longer > >so) > >> > > from > >> > > their services. They have replied saying it takes 3-5 >days to > >resolve > >> > > the > >> > > issue, that was several weeks ago. Can i get contact from >those > >two > >> > > services that can help my customers reach their services, >thank > >you. > >> > > > >> > > > >> > > Thank you for the help. > >> > > -Michael > >> > >> > > > > > From gtaylor at tnetconsulting.net Wed Dec 27 20:50:24 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 27 Dec 2017 13:50:24 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <20171226232426.EC603188A177@ary.local> References: <20171226232426.EC603188A177@ary.local> Message-ID: set Devil's advocate mode = on On 12/26/2017 04:24 PM, John Levine wrote: > Is there some reason you believe that Hulu has a legal duty to provide > old TV shows to your users? Doesn't Hulu (et al) have an obligation to provide service to their paying customers? Does this obligation extend to providing service independent of the carrier that paying customers uses? Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) don't they have an obligation to confirm that their exclusions are accurate? Further, to correct problems if their data is shown to be inaccurate? > There are laws about discriminating against > protected classes like racial or religious minorities but I am fairly > sure that "random subscribers of some ISP in Utah" is not such a class." It's not a law, but it is a service agreement between Hulu and their customers. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From jared at puck.nether.net Wed Dec 27 21:10:30 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Dec 2017 16:10:30 -0500 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <20171226232426.EC603188A177@ary.local> Message-ID: <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> > On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG wrote: > > set Devil's advocate mode = on Polluted IP space concern = ON > On 12/26/2017 04:24 PM, John Levine wrote: >> Is there some reason you believe that Hulu has a legal duty to provide old TV shows to your users? > > Doesn't Hulu (et al) have an obligation to provide service to their paying customers? > > Does this obligation extend to providing service independent of the carrier that paying customers uses? > > Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) don't they have an obligation to confirm that their exclusions are accurate? Further, to correct problems if their data is shown to be inaccurate? I have a suspicion that these folks acquired IP space that was previously marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN provider IP space. If you look at some of the blocks I’ve seen, they have some interesting history/registration that seems to appear that way. I’ve pointed folks at Hulu at this thread and an encouraging them to follow-up. If you acquired IP space from a broker, you should follow up with them about the geolocation issues, and you should know what it was used for in the past. If you are using a CDN to serve content, make sure you can serve over v6 and can also do geolocation over IPv6. Finding the IP space used to geolocate generally isn’t difficult. I had previously found some of these myself. >> There are laws about discriminating against protected classes like racial or religious minorities but I am fairly sure that "random subscribers of some ISP in Utah" is not such a class." > > It's not a law, but it is a service agreement between Hulu and their customers. It’s also that Hulu is owned by content owners that can decide to be strict about their content rights. I’m not a fan of geoblocking and vote with my wallet to not give Hulu money. While I understand your customers may, the lack of a fix is also a market signal. - Jared From bill at herrin.us Wed Dec 27 22:35:56 2017 From: bill at herrin.us (William Herrin) Date: Wed, 27 Dec 2017 17:35:56 -0500 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <770202405.2528.1513393032079.JavaMail.mhammett@ThunderFuck> <002701d37e75$21705640$645102c0$@SanDiegoBroadband.com> Message-ID: On Tue, Dec 26, 2017 at 2:41 PM, Michael Crapse wrote: > I would like to know, Is there any legal recourse we can take against such > a company consistently ignoring whitelist requests? > Hi Michael, There is not, however that does not mean a letter from your lawyer to their lawyer would fail to bear fruit. Internally, queries from the legal team tend to get a priority. Perhaps a polite letter to the effect that you have exhausted your options outside of legal channels and would appreciate a prompt response. Hulu doesn't actually want to block legitimate customers, so all you really need is for the right person at Hulu to receive a swift kick in the tail from someone they can't ignore. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at jima.us Wed Dec 27 22:38:42 2017 From: nanog at jima.us (Jima) Date: Wed, 27 Dec 2017 15:38:42 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> Message-ID: <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> On 2017-12-27 14:10, Jared Mauch wrote: > On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG wrote: >> Doesn't Hulu (et al) have an obligation to provide service to their paying customers? >> >> Does this obligation extend to providing service independent of the carrier that paying customers uses? >> >> Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) don't they have an obligation to confirm that their exclusions are accurate? Further, to correct problems if their data is shown to be inaccurate? > > I have a suspicion that these folks acquired IP space that was previously marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN provider IP space. I was sitting on this, but what the heck. I personally am curious as to what bug and/or feature allowed a random WISP in Utah (or the parent-ish ISP in New Jersey) to have IP space allocated from AfriNIC. One might consider Hulu et al not so at-fault with that fact in consideration. - Jima From bill at herrin.us Wed Dec 27 22:50:26 2017 From: bill at herrin.us (William Herrin) Date: Wed, 27 Dec 2017 17:50:26 -0500 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> Message-ID: On Wed, Dec 27, 2017 at 5:38 PM, Jima wrote: > On 2017-12-27 14:10, Jared Mauch wrote: > >> On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG >> wrote: >> >>> Doesn't Hulu (et al) have an obligation to provide service to their >>> paying customers? >>> >>> Does this obligation extend to providing service independent of the >>> carrier that paying customers uses? >>> >>> Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) >>> don't they have an obligation to confirm that their exclusions are >>> accurate? Further, to correct problems if their data is shown to be >>> inaccurate? >>> >> >> I have a suspicion that these folks acquired IP space that was previously >> marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN >> provider IP space. >> > > I was sitting on this, but what the heck. > > I personally am curious as to what bug and/or feature allowed a random > WISP in Utah (or the parent-ish ISP in New Jersey) to have IP space > allocated from AfriNIC. > > One might consider Hulu et al not so at-fault with that fact in > consideration. Hi Jima, Net 196/8 is part of the swamp. Just speculating, but perhaps the original registration of 196.53.96.0/22 pre-dated the reassignment of 196/8 to AfriNIC? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From laszlo at heliacal.net Wed Dec 27 22:53:38 2017 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 27 Dec 2017 22:53:38 +0000 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> Message-ID: On 2017-12-27 22:38, Jima wrote: > On 2017-12-27 14:10, Jared Mauch wrote: >> On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG >> wrote: >>> Doesn't Hulu (et al) have an obligation to provide service to their >>> paying customers? >>> >>> Does this obligation extend to providing service independent of the >>> carrier that paying customers uses? >>> >>> Or if Hulu choose to exclude known problem carriers (i.e. VPN >>> providers) don't they have an obligation to confirm that their >>> exclusions are accurate?  Further, to correct problems if their data >>> is shown to be inaccurate? >> >> I have a suspicion that these folks acquired IP space that was >> previously marked as part of a VPN provider, or Hulu is detecting it >> wrongly as VPN provider IP space. > > I was sitting on this, but what the heck. > > I personally am curious as to what bug and/or feature allowed a random > WISP in Utah (or the parent-ish ISP in New Jersey) to have IP space > allocated from AfriNIC. > > One might consider Hulu et al not so at-fault with that fact in > consideration. > > - Jima Addresses aren't an identity nor are they tied to a physical location, so this is pretty irrelevant.  What Hulu should be doing is asking the user where they're located, instead of trying to tell them.  This thread happens here a couple times a week and the frequency of it will increase as addresses are recycled.  Clearly there is a lot of collateral damage from using GeoIP, but it mostly works on the big national ISPs so they still make money.  The WISPs and other small ISPs are an acceptable amount of loss, I guess.  The problem is that this is Hulu's fault but the pain is felt by everyone else except them, so they have no reason to want to stop doing this. -Laszlo From marka at isc.org Wed Dec 27 23:06:23 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Dec 2017 10:06:23 +1100 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> Message-ID: <9DF53415-6657-4064-B016-9B6F54FEDAF3@isc.org> > On 28 Dec 2017, at 9:38 am, Jima wrote: > > On 2017-12-27 14:10, Jared Mauch wrote: >> On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG wrote: >>> Doesn't Hulu (et al) have an obligation to provide service to their paying customers? >>> >>> Does this obligation extend to providing service independent of the carrier that paying customers uses? >>> >>> Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) don't they have an obligation to confirm that their exclusions are accurate? Further, to correct problems if their data is shown to be inaccurate? >> I have a suspicion that these folks acquired IP space that was previously marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN provider IP space. > > I was sitting on this, but what the heck. > > I personally am curious as to what bug and/or feature allowed a random WISP in Utah (or the parent-ish ISP in New Jersey) to have IP space allocated from AfriNIC. > > One might consider Hulu et al not so at-fault with that fact in consideration. > > - Jima If you need IPv4 address space you get it where you can. There are lots of addresses used outside of the original RIR service regions. This will occur more and more often. What it does require is the State AG to come into bat for the customer to make HULU correct their business practices as that are obviously broken. You should be able to buy you internet service from anyone in the state and it should work equally well subject to bandwidth limitations. This is a consumer rights issue and it needs to be driven that way. inetnum: 196.53.96.0 - 196.53.99.255 netname: LogicWeb descr: Wi-Fiber, Inc. descr: 775 S Main St. descr: Logan, UT 84321 country: US admin-c: CA12-AFRINIC tech-c: CA12-AFRINIC status: ASSIGNED PA mnt-by: LOGICWEB-MNT source: AFRINIC # Filtered parent: 196.52.0.0 - 196.55.255.255 person: Chad Abizeid address: LogicWeb Inc. address: 4509 Steeplechase Dr. address: Easton, PA 18040 address: USA phone: +1 866 611 1556 org: ORG-LWI1-AFRINIC nic-hdl: CA12-AFRINIC mnt-by: LOGICWEB-MNT source: AFRINIC # Filtered -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at jima.us Wed Dec 27 23:11:02 2017 From: nanog at jima.us (Jima) Date: Wed, 27 Dec 2017 16:11:02 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> Message-ID: <038fd2a6-b272-0119-7df5-123845b891ec@jima.us> On 2017-12-27 15:50, William Herrin wrote: > Net 196/8 is part of the swamp. Just speculating, but perhaps the > original registration of 196.53.96.0/22 > pre-dated the reassignment of 196/8 to AfriNIC? Maybe? This snippet from WHOIS kind of nags at me, though: inetnum: 196.52.0.0 - 196.55.255.255 netname: LogicWeb-Inc descr: LogicWeb Inc. descr: 3003 Woodbridge Ave descr: Edison, NJ 08837 country: ZA Why South Africa if it's a legacy block? It looks like that stems from delegated-afrinic-extended, though: afrinic|ZA|ipv4|196.52.0.0|262144|19951009|allocated|F36E02F6 To your point, there are 42 entries dated 1995 in 196/8 -- 37 of them marked as ZA -- so maybe you're right that it's a relic of a bygone era. That relic might explain the uphill battle the OP has experienced, though -- Hulu (et al) might be using the RIRs' own data to populate their ACLs. And who can blame them? From my understanding, the video content owners often have restrictive requirements in their licensing agreements, which is also why Hulu can't just ask the users their locations (per Laszlo's email). Weird corner cases abound, but it sounds like someone dropped the ball on getting this corrected. Tsk. - Jima From lists at silverlakeinternet.com Wed Dec 27 23:17:20 2017 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Wed, 27 Dec 2017 16:17:20 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <9DF53415-6657-4064-B016-9B6F54FEDAF3@isc.org> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> <9DF53415-6657-4064-B016-9B6F54FEDAF3@isc.org> Message-ID: <7C8A6946-B200-408B-9438-D9FB76F538C0@silverlakeinternet.com> I had some of that subnet from logicweb. Once I realized it was Afrinic I switched. Now I have the same issue with another subnet from ARIN. 104.153.151.0/24 is all blocked still and I cannot get anyone from any of the companies to respond or unblock them. Thank you, Brett A Mansfield > On Dec 27, 2017, at 4:06 PM, Mark Andrews wrote: > > >> On 28 Dec 2017, at 9:38 am, Jima wrote: >> >> On 2017-12-27 14:10, Jared Mauch wrote: >>>> On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG wrote: >>>> Doesn't Hulu (et al) have an obligation to provide service to their paying customers? >>>> >>>> Does this obligation extend to providing service independent of the carrier that paying customers uses? >>>> >>>> Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) don't they have an obligation to confirm that their exclusions are accurate? Further, to correct problems if their data is shown to be inaccurate? >>> I have a suspicion that these folks acquired IP space that was previously marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN provider IP space. >> >> I was sitting on this, but what the heck. >> >> I personally am curious as to what bug and/or feature allowed a random WISP in Utah (or the parent-ish ISP in New Jersey) to have IP space allocated from AfriNIC. >> >> One might consider Hulu et al not so at-fault with that fact in consideration. >> >> - Jima > > If you need IPv4 address space you get it where you can. There are lots of addresses used outside of the original RIR service regions. This will occur more and more often. > > What it does require is the State AG to come into bat for the customer to make HULU correct their business practices as that are obviously broken. You should be able to buy you internet service from anyone in the state and it should work equally well subject to bandwidth limitations. This is a consumer rights issue and it needs to be driven that way. > > inetnum: 196.53.96.0 - 196.53.99.255 > netname: LogicWeb > descr: Wi-Fiber, Inc. > descr: 775 S Main St. > descr: Logan, UT 84321 > country: US > admin-c: CA12-AFRINIC > tech-c: CA12-AFRINIC > status: ASSIGNED PA > mnt-by: LOGICWEB-MNT > source: AFRINIC # Filtered > parent: 196.52.0.0 - 196.55.255.255 > > person: Chad Abizeid > address: LogicWeb Inc. > address: 4509 Steeplechase Dr. > address: Easton, PA 18040 > address: USA > phone: +1 866 611 1556 > org: ORG-LWI1-AFRINIC > nic-hdl: CA12-AFRINIC > mnt-by: LOGICWEB-MNT > source: AFRINIC # Filtered > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From brock at bmwl.co Wed Dec 27 23:29:33 2017 From: brock at bmwl.co (Brock Tice) Date: Wed, 27 Dec 2017 16:29:33 -0700 Subject: Geolocation: IPv4 Subnet blocked by HULU, and others In-Reply-To: <038fd2a6-b272-0119-7df5-123845b891ec@jima.us> References: <20171226232426.EC603188A177@ary.local> <3AE1F13A-DFB2-4030-85E7-A9B7DB3964AE@puck.nether.net> <9b4753f9-7f30-f7c5-a7b8-fee65616bc68@jima.us> <038fd2a6-b272-0119-7df5-123845b891ec@jima.us> Message-ID: On 12/27/2017 04:11 PM, Jima wrote: > On 2017-12-27 15:50, William Herrin wrote: >> Net 196/8 is part of the swamp. Just speculating, but perhaps the >> original registration of 196.53.96.0/22 >> pre-dated the reassignment of 196/8 to AfriNIC? > > Maybe? This snippet from WHOIS kind of nags at me, though: > > inetnum:        196.52.0.0 - 196.55.255.255 > netname:        LogicWeb-Inc > descr:          LogicWeb Inc. > descr:          3003 Woodbridge Ave > descr:          Edison, NJ 08837 > country:        ZA > > Why South Africa if it's a legacy block? It looks like that stems from > delegated-afrinic-extended, though: > > afrinic|ZA|ipv4|196.52.0.0|262144|19951009|allocated|F36E02F6 We are leasing a /24 from that block as well, it's caused us similar issues but they are mostly resolved now. Luckily we've now deployed our first ipv6 customers with 464xlat and it's working well, so I hope to be able to stop leasing that subnet in 2018. It's hard for small ISPs that can't afford to buy IPv4 blocks, now that ARIN is not handing them out. We're lucky we got a /23, if we'd started a few years later we'd have nothing. --Brock From brock at bmwl.co Thu Dec 28 00:45:27 2017 From: brock at bmwl.co (Brock Tice) Date: Wed, 27 Dec 2017 17:45:27 -0700 Subject: Implementing 464XLAT at a small WISP Message-ID: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> We recently deployed our first half-dozen IPv6-only customers after 6+ months of testing, using 464XLAT. It took me ages to sort all this out, so I hope someone finds this helpful. Feedback very much welcome. https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ From marka at isc.org Thu Dec 28 01:49:00 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Dec 2017 12:49:00 +1100 Subject: Implementing 464XLAT at a small WISP In-Reply-To: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> References: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> Message-ID: <90DB3FD3-AC97-4784-9D7B-789AADE8B800@isc.org> > On 28 Dec 2017, at 11:45 am, Brock Tice wrote: > > We recently deployed our first half-dozen IPv6-only customers after 6+ months of testing, using 464XLAT. > > It took me ages to sort all this out, so I hope someone finds this helpful. Feedback very much welcome. > > https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ If all you want to do is 464XLAT you don’t need a nameserver that supports DNS64. Just add a ipv4only.arpa zone with the appropriate AAAA records to your recursive servers. The following provides the 464XLAT translation with the well known NAT64 prefix. ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. NS . ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.171 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jordi.palet at consulintel.es Thu Dec 28 09:11:51 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Dec 2017 10:11:51 +0100 Subject: Implementing 464XLAT at a small WISP In-Reply-To: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> References: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> Message-ID: Nice ;-) I’ve been doing this for some time already … and have trials with several customers (tens of thousands of customers). Note that most of the routers that support LEDE (quite a big list), will work by default with a standard stable release. You mention it, but we use something like for the offload: ethtool --offload eth0 gro off lro off ethtool --offload eth1 gro off lro off Also, for the DNS64, I use exclude. It can be improved also to avoid including (in the exclusion) the prefixes for transition mechanisms, such as 2001::/32, 2002::/16, etc. dns64 64:ff9b::/96 { clients { any; }; mapped { any; }; exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; }; break-dnssec no; }; I’ve an ID on this: https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/ I’m working in the next few days in a review of this, so any inputs are welcome! Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Brock Tice Responder a: Fecha: jueves, 28 de diciembre de 2017, 1:48 Para: Asunto: Implementing 464XLAT at a small WISP We recently deployed our first half-dozen IPv6-only customers after 6+ months of testing, using 464XLAT. It took me ages to sort all this out, so I hope someone finds this helpful. Feedback very much welcome. https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Thu Dec 28 10:43:43 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Dec 2017 11:43:43 +0100 Subject: Implementing 464XLAT at a small WISP In-Reply-To: References: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> Message-ID: I’ve customers with have 1Gbit FTTH link using LEDE with NAT. Depending on the hardware (I’m talking about Chinese made routers with cost less than 50 USD) they easily reach 9xx Mbits. It may depend on the chip set, as some LEDE implementations take advantage of hardware NAT. I’ve tested it myself with iperf, simulating a WAN link to traverse the router in a 2 LAN lab environment. The tests have been done using both, native IPv4 and CLAT (so having only IPv6 in the WAN link). Regular LEDE stable firmware, in most of the devices, don’t support by default hardware NAT, so you can in those cases, reach 500-600 Mbits, again, depending on specific hardware. So, I don’t think number of users is an issue. Not sure if that’s responding your question … Regards, Jordi -----Mensaje original----- De: Loganaden Velvindron Responder a: Fecha: jueves, 28 de diciembre de 2017, 10:52 Para: CC: Asunto: Re: Implementing 464XLAT at a small WISP On Thu, Dec 28, 2017 at 1:11 PM, JORDI PALET MARTINEZ wrote: > Nice ;-) > > I’ve been doing this for some time already … and have trials with several customers (tens of thousands of customers). > > Note that most of the routers that support LEDE (quite a big list), will work by default with a standard stable release. > I'm curious about the limits in terms of number of users from running OpenWRT/LEDE on this kind of gear. Afaik, LEDE or OpenWRT do not have customer drivers that push a lot of traffic. Often the linux driver running on the default firmware is developed out of the free. https://pappp.net/?p=1525 > You mention it, but we use something like for the offload: > ethtool --offload eth0 gro off lro off > ethtool --offload eth1 gro off lro off > > Also, for the DNS64, I use exclude. It can be improved also to avoid including (in the exclusion) the prefixes for transition mechanisms, such as 2001::/32, 2002::/16, etc. > > dns64 64:ff9b::/96 { > clients { any; }; > mapped { any; }; > exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; }; > break-dnssec no; > }; > > I’ve an ID on this: > > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/ > > > I’m working in the next few days in a review of this, so any inputs are welcome! > > Regards, > Jordi > > -----Mensaje original----- > De: NANOG en nombre de Brock Tice > Responder a: > Fecha: jueves, 28 de diciembre de 2017, 1:48 > Para: > Asunto: Implementing 464XLAT at a small WISP > > We recently deployed our first half-dozen IPv6-only customers after 6+ > months of testing, using 464XLAT. > > It took me ages to sort all this out, so I hope someone finds this > helpful. Feedback very much welcome. > > https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Thu Dec 28 11:11:47 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Dec 2017 12:11:47 +0100 Subject: Implementing 464XLAT at a small WISP In-Reply-To: References: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> Message-ID: <285B38E1-3E6B-48DC-ABBE-3E5036EFD8C8@consulintel.es> In many ocassions you have MUCH better support from the OpenSource community than from vendors …. Look at Ubiquity and Mikrotik, supporting a very reduced set of transitions mechanisms. I’ve many WISP that have big troubles to keep growing because that, and you know what, at the end they reflash that “nice” hardware with LEDE, and done! Regards, Jordi -----Mensaje original----- De: Loganaden Velvindron Responder a: Fecha: jueves, 28 de diciembre de 2017, 12:04 Para: CC: Asunto: Re: Implementing 464XLAT at a small WISP On Thu, Dec 28, 2017 at 2:43 PM, JORDI PALET MARTINEZ wrote: > I’ve customers with have 1Gbit FTTH link using LEDE with NAT. > > Depending on the hardware (I’m talking about Chinese made routers with cost less than 50 USD) they easily reach 9xx Mbits. It may depend on the chip set, as some LEDE implementations take advantage of hardware NAT. > > I’ve tested it myself with iperf, simulating a WAN link to traverse the router in a 2 LAN lab environment. The tests have been done using both, native IPv4 and CLAT (so having only IPv6 in the WAN link). > > Regular LEDE stable firmware, in most of the devices, don’t support by default hardware NAT, so you can in those cases, reach 500-600 Mbits, again, depending on specific hardware. > > So, I don’t think number of users is an issue. > > Not sure if that’s responding your question … > Thanks for sharing. It's interesting to see enterprise customers adopting OpenWRT/LEDE despite no official support from CPE vendors for 3rd party firmware on their products. > Regards, > Jordi > > -----Mensaje original----- > De: Loganaden Velvindron > Responder a: > Fecha: jueves, 28 de diciembre de 2017, 10:52 > Para: > CC: > Asunto: Re: Implementing 464XLAT at a small WISP > > On Thu, Dec 28, 2017 at 1:11 PM, JORDI PALET MARTINEZ > wrote: > > Nice ;-) > > > > I’ve been doing this for some time already … and have trials with several customers (tens of thousands of customers). > > > > Note that most of the routers that support LEDE (quite a big list), will work by default with a standard stable release. > > > > I'm curious about the limits in terms of number of users from running > OpenWRT/LEDE on this kind of gear. Afaik, LEDE or OpenWRT do not have > customer drivers that push a lot of traffic. Often the linux driver > running on the default firmware is developed out of the free. > https://pappp.net/?p=1525 > > > > You mention it, but we use something like for the offload: > > ethtool --offload eth0 gro off lro off > > ethtool --offload eth1 gro off lro off > > > > Also, for the DNS64, I use exclude. It can be improved also to avoid including (in the exclusion) the prefixes for transition mechanisms, such as 2001::/32, 2002::/16, etc. > > > > dns64 64:ff9b::/96 { > > clients { any; }; > > mapped { any; }; > > exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; }; > > break-dnssec no; > > }; > > > > I’ve an ID on this: > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/ > > > > > > I’m working in the next few days in a review of this, so any inputs are welcome! > > > > Regards, > > Jordi > > > > -----Mensaje original----- > > De: NANOG en nombre de Brock Tice > > Responder a: > > Fecha: jueves, 28 de diciembre de 2017, 1:48 > > Para: > > Asunto: Implementing 464XLAT at a small WISP > > > > We recently deployed our first half-dozen IPv6-only customers after 6+ > > months of testing, using 464XLAT. > > > > It took me ages to sort all this out, so I hope someone finds this > > helpful. Feedback very much welcome. > > > > https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From brock at bmwl.co Thu Dec 28 11:19:33 2017 From: brock at bmwl.co (Brock Tice) Date: Thu, 28 Dec 2017 04:19:33 -0700 Subject: Implementing 464XLAT at a small WISP In-Reply-To: <285B38E1-3E6B-48DC-ABBE-3E5036EFD8C8@consulintel.es> References: <1f427475-bf48-bdb7-a1fb-40070f83d5c8@bmwl.co> <285B38E1-3E6B-48DC-ABBE-3E5036EFD8C8@consulintel.es> Message-ID: On 2017-12-28 04:11, JORDI PALET MARTINEZ wrote: > Thanks for sharing. It's interesting to see enterprise customers > adopting OpenWRT/LEDE despite no official support from CPE vendors for > 3rd party firmware on their products. One reason we are using Linksys so far is their nominal support for "open source" on their routers. I started testing with the WRT 1900ACS, which is a bit expensive for us to be handing out to everyone. We will be using those for customers on higher-speed plans. Honestly, given the number of bugs we've dealt with from our other vendors, and the lack of ability to fix (or even find) them ourselves, I'm at least as comfortable with OpenWRT/LEDE as I am with, say AirOS or RouterOS deployed in our network. From octalnanog at alvarezp.org Thu Dec 28 17:23:00 2017 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Thu, 28 Dec 2017 11:23:00 -0600 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> Message-ID: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> On 12/20/2017 12:23 PM, Mike wrote: > On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > Call this the 'shavings', in IPv4 for example, when you assign a P2P > link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > due to ping-pong and just so many technical manuals and other advices, > you are told to "just use a /64' for your point to points. Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it. Best regards, Octavio. From owen at delong.com Thu Dec 28 17:39:54 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 09:39:54 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: > On Dec 28, 2017, at 09:23 , Octavio Alvarez wrote: > > On 12/20/2017 12:23 PM, Mike wrote: >> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >> Call this the 'shavings', in IPv4 for example, when you assign a P2P >> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >> due to ping-pong and just so many technical manuals and other advices, >> you are told to "just use a /64' for your point to points. > > Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the > exception would be if a router does not support it. > > Best regards, > Octavio. Best practice used most places is to assign a /64 and put a /127 on the interfaces. Owen From michael at wi-fiber.io Thu Dec 28 17:55:20 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 28 Dec 2017 10:55:20 -0700 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. If that was ipv4 you could recreate the entire internet with that many addresses. On 28 December 2017 at 10:39, Owen DeLong wrote: > > > On Dec 28, 2017, at 09:23 , Octavio Alvarez > wrote: > > > > On 12/20/2017 12:23 PM, Mike wrote: > >> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > >> Call this the 'shavings', in IPv4 for example, when you assign a P2P > >> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > >> due to ping-pong and just so many technical manuals and other advices, > >> you are told to "just use a /64' for your point to points. > > > > Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the > > exception would be if a router does not support it. > > > > Best regards, > > Octavio. > > Best practice used most places is to assign a /64 and put a /127 on the > interfaces. > > Owen > > > From jordi.palet at consulintel.es Thu Dec 28 18:10:54 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Dec 2017 19:10:54 +0100 Subject: Waste will kill ipv6 too In-Reply-To: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: Not really. RFC6164 is meant to make sure routers support /127, but doesn’t mandate or say that you must use that. This is another perspective: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Octavio Alvarez Responder a: Fecha: jueves, 28 de diciembre de 2017, 18:25 Para: Mike , Asunto: Re: Waste will kill ipv6 too On 12/20/2017 12:23 PM, Mike wrote: > On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > Call this the 'shavings', in IPv4 for example, when you assign a P2P > link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > due to ping-pong and just so many technical manuals and other advices, > you are told to "just use a /64' for your point to points. Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it. Best regards, Octavio. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From laszlo at heliacal.net Thu Dec 28 18:12:34 2017 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 28 Dec 2017 18:12:34 +0000 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: On 2017-12-28 17:55, Michael Crapse wrote: > Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. > If that was ipv4 you could recreate the entire internet with that many > addresses. After all these years people still don't understand IPv6 and that's why we're back to having to do NAT again, even though we now have a practically endless supply of integers.  If we could have all agreed to just do /64+/48 to every edge host/router, no questions asked, we'd never have to talk about this again.  Playing tetris with addresses had to be done with IPv4 but it's not even remotely a concern with IPv6 - the idea of waste and sizing networks is a chore that doesn't need to be thought about anymore.  As you say, if you have a /64, you could run the entire internet with it, if you really wanted to do the kinds of hacks we've been doing with v4, but the idea is that you don't need to do any of that. -Laszlo > > On 28 December 2017 at 10:39, Owen DeLong wrote: > >>> On Dec 28, 2017, at 09:23 , Octavio Alvarez >> wrote: >>> On 12/20/2017 12:23 PM, Mike wrote: >>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>> due to ping-pong and just so many technical manuals and other advices, >>>> you are told to "just use a /64' for your point to points. >>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>> exception would be if a router does not support it. >>> >>> Best regards, >>> Octavio. >> Best practice used most places is to assign a /64 and put a /127 on the >> interfaces. >> >> Owen >> >> >> From octalnanog at alvarezp.org Thu Dec 28 18:29:00 2017 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Thu, 28 Dec 2017 12:29:00 -0600 Subject: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too) In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: On 12/28/2017 11:39 AM, Owen DeLong wrote: > >> On Dec 28, 2017, at 09:23 , Octavio Alvarez wrote: >> >> On 12/20/2017 12:23 PM, Mike wrote: >>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>> due to ping-pong and just so many technical manuals and other advices, >>> you are told to "just use a /64' for your point to points. >> >> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >> exception would be if a router does not support it. >> > Best practice used most places is to assign a /64 and put a /127 on the interfaces. > Thanks for the info. Is this documented somewhere? Is there a disadvantage in letting many P2P links use different /127 networks within the same /64? Best regards, Octavio. From jordi.palet at consulintel.es Thu Dec 28 18:34:40 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Dec 2017 19:34:40 +0100 Subject: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too) In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: This may be useful: https://www.ripe.net/publications/docs/ripe-690/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Octavio Alvarez Responder a: Fecha: jueves, 28 de diciembre de 2017, 19:31 Para: Owen DeLong CC: Asunto: Re: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too) On 12/28/2017 11:39 AM, Owen DeLong wrote: > >> On Dec 28, 2017, at 09:23 , Octavio Alvarez wrote: >> >> On 12/20/2017 12:23 PM, Mike wrote: >>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>> due to ping-pong and just so many technical manuals and other advices, >>> you are told to "just use a /64' for your point to points. >> >> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >> exception would be if a router does not support it. >> > Best practice used most places is to assign a /64 and put a /127 on the interfaces. > Thanks for the info. Is this documented somewhere? Is there a disadvantage in letting many P2P links use different /127 networks within the same /64? Best regards, Octavio. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From james.cutler at consultant.com Thu Dec 28 18:45:54 2017 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 28 Dec 2017 12:45:54 -0600 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: <028EDD74-F598-41CB-A9DB-9950C8BAAA32@consultant.com> [Deliberate top post] All this fear about “waste” killing IPv6 is unwarranted. It is about time to look at the business aspect of wasting human resources fiddling with micro-optimization. We seem to have have two choices: A. Keep arguing and complicating management of the IPv6 Internet and wasting human resources ==> more cost. B. Deploy IPv6 to end users using the RA/DHCP-PD and the like with the simplest possible templates, e.g., /64+/48 to every edge host/router, no questions asked, thus requiring fewer human resources ==> less cost. Some major networks have long since adopted choice B. The pace of technology change makes likely that "Waste will kill ipv6 too” will be a moot issue by any of the time estimates discussed previously. Any prudent business will choose “B”. Any other choice from this list would be a waste of time and money. See also “Human Use of Human Beings” by Norbert Weiner. Cutler > On Dec 28, 2017, at 12:12 PM, Laszlo Hanyecz wrote: > > > > On 2017-12-28 17:55, Michael Crapse wrote: >> Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. >> If that was ipv4 you could recreate the entire internet with that many >> addresses. > > After all these years people still don't understand IPv6 and that's why we're back to having to do NAT again, even though we now have a practically endless supply of integers. If we could have all agreed to just do /64+/48 to every edge host/router, no questions asked, we'd never have to talk about this again. Playing tetris with addresses had to be done with IPv4 but it's not even remotely a concern with IPv6 - the idea of waste and sizing networks is a chore that doesn't need to be thought about anymore. As you say, if you have a /64, you could run the entire internet with it, if you really wanted to do the kinds of hacks we've been doing with v4, but the idea is that you don't need to do any of that. > > -Laszlo > >> >> On 28 December 2017 at 10:39, Owen DeLong wrote: >> >>>> On Dec 28, 2017, at 09:23 , Octavio Alvarez >>> wrote: >>>> On 12/20/2017 12:23 PM, Mike wrote: >>>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>>> due to ping-pong and just so many technical manuals and other advices, >>>>> you are told to "just use a /64' for your point to points. >>>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>>> exception would be if a router does not support it. >>>> >>>> Best regards, >>>> Octavio. >>> Best practice used most places is to assign a /64 and put a /127 on the >>> interfaces. >>> >>> Owen >>> >>> >>> > From bzs at theworld.com Thu Dec 28 19:14:06 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 28 Dec 2017 14:14:06 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: <23109.17022.495829.617613@gargle.gargle.HOWL> Just an interjection but the problem with this "waste" issue often comes down to those who see 128 bits of address vs those who see 2^128 addresses. It's not like there were ever anything close to 4 billion (2^32) usable addresses with IPv4. We have entire /8s which are sparsely populated so even if they're 24M addrs that's of no use to everyone else. Plus other dedicated uses like multicast. So the problem is segmentation of that 128 bits which makes it look a lot scarier because 128 is easy to think about, policy-wise, while 2^128 isn't. My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) And some scheme to store those addresses in the packet header, possibly IPv4 backwards compatible (I know, I know, but here we are!) And we'd've been all set, up to 256 bytes (2K bits) of address. If wishes were horses...but I think what I'm saying here will be said again and again. Too many people answering every concern with "do you have any idea how many addresses 2^N is?!?!" while drowning out "do you have any idea how small that N is? -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mel at beckman.org Thu Dec 28 19:23:29 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 28 Dec 2017 19:23:29 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <23109.17022.495829.617613@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org>, <23109.17022.495829.617613@gargle.gargle.HOWL> Message-ID: <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org> IPng was discussed to death and found not workable. The history is there for you to read. In the meantime, it's not helpful claiming IPng until you understand that background. -mel > On Dec 28, 2017, at 11:15 AM, "bzs at theworld.com" wrote: > > > Just an interjection but the problem with this "waste" issue often > comes down to those who see 128 bits of address vs those who see 2^128 > addresses. It's not like there were ever anything close to 4 billion > (2^32) usable addresses with IPv4. > > We have entire /8s which are sparsely populated so even if they're 24M > addrs that's of no use to everyone else. Plus other dedicated uses > like multicast. > > So the problem is segmentation of that 128 bits which makes it look a > lot scarier because 128 is easy to think about, policy-wise, while > 2^128 isn't. > > My wild guess is if we'd just waited a little bit longer to formalize > IPng we'd've more seriously considered variable length addressing with > a byte indicating how many octets in the address even if only 2 > lengths were immediately implemented (4 and 16.) And some scheme to > store those addresses in the packet header, possibly IPv4 backwards > compatible (I know, I know, but here we are!) > > And we'd've been all set, up to 256 bytes (2K bits) of address. > > If wishes were horses...but I think what I'm saying here will be said > again and again. > > Too many people answering every concern with "do you have any idea how > many addresses 2^N is?!?!" while drowning out "do you have any idea > how small that N is? > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From kmedcalf at dessus.com Thu Dec 28 19:28:14 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 28 Dec 2017 12:28:14 -0700 Subject: Waste will kill ipv6 too In-Reply-To: <028EDD74-F598-41CB-A9DB-9950C8BAAA32@consultant.com> Message-ID: >It is about time to look at the business aspect of wasting human >resources fiddling with micro-optimization. We seem to have have two >choices: >A. Keep arguing and complicating management of the IPv6 Internet and >wasting human resources ==> more cost. >From a business management (and consultant) perspective this is the correct choice, of course. It means that the workforce size will increase and that the Executives in charge will have more underthings doing more (albeit useless) busy-work. Since most of it will be being done by non-skilled employee's the cost will be rather low -- and everytime you get some employee who can fathom what is going on, just get rid of them. >From a management (and consultant) perspective this is absolutely marvellous -- the bigger the empire the more the pay and the higher the bonuses and pension. And they will be happily retired before the shit hits the fan. >B. Deploy IPv6 to end users using the RA/DHCP-PD and the like with >the simplest possible templates, e.g., /64+/48 to every edge >host/router, no questions asked, thus requiring fewer human >resources ==> less cost. This requires fewer underthings to keep things running -- though those underthings will have to have a higher wattage each. This means smaller empires and lower pay and bonuses for the Executives and the Consultants. This is not good for the bonus, the salary, or the retirement pension. There is no monetary benefit in leaving behind "something that just works". --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From bzs at theworld.com Thu Dec 28 19:34:27 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 28 Dec 2017 14:34:27 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org> Message-ID: <23109.18243.121783.791328@gargle.gargle.HOWL> On December 28, 2017 at 19:23 mel at beckman.org (Mel Beckman) wrote: > IPng was discussed to death and found not workable. The history is there for you to read. In the meantime, it's not helpful claiming IPng until you understand that background. By "IPng" I only meant whatever would follow IPv4, IP next generation, not any specific proposal which may've called itself "ipng". But more importantly the difference between thinking in terms of 128 bits vs 2^128 addresses which seem to be conflated in these discussions, repeatedly. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mel at beckman.org Thu Dec 28 19:47:17 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 28 Dec 2017 19:47:17 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <23109.18243.121783.791328@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org>, <23109.18243.121783.791328@gargle.gargle.HOWL> Message-ID: <289A080C-5F9D-4C54-9570-13ADF7C4C80F@beckman.org> the difference between thinking in terms of 128 bits vs 2^128 addresses which seem to be conflated in these discussions I think you're wrong. Show me where anyone made a case in this thread at all for 2^128 addresses mitigating the problem. Everyone has been discussing structured assignments with 128 bits, and several people here have proven to a mathematical certainty that no technology here today nor on the horizon can exhaust this address space undertake the current allocation rules, *INCLUDING* using /64s for point-to-point circuit. -mel On Dec 28, 2017, at 11:34 AM, "bzs at theworld.com" > wrote: On December 28, 2017 at 19:23 mel at beckman.org (Mel Beckman) wrote: IPng was discussed to death and found not workable. The history is there for you to read. In the meantime, it's not helpful claiming IPng until you understand that background. By "IPng" I only meant whatever would follow IPv4, IP next generation, not any specific proposal which may've called itself "ipng". But more importantly the difference between thinking in terms of 128 bits vs 2^128 addresses which seem to be conflated in these discussions, repeatedly. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Thu Dec 28 20:04:53 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 28 Dec 2017 15:04:53 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <289A080C-5F9D-4C54-9570-13ADF7C4C80F@beckman.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org> <23109.18243.121783.791328@gargle.gargle.HOWL> <289A080C-5F9D-4C54-9570-13ADF7C4C80F@beckman.org> Message-ID: <23109.20069.148555.899534@gargle.gargle.HOWL> On December 28, 2017 at 19:47 mel at beckman.org (Mel Beckman) wrote: > the difference between thinking in terms of 128 > bits vs 2^128 addresses which seem to be conflated in these discussions > > > I think you're wrong. Show me where anyone made a case in this thread at all > for 2^128 addresses mitigating the problem. Everyone has been discussing > structured assignments with 128 bits, and several people here have proven to a > mathematical certainty that no technology here today nor on the horizon can > exhaust this address space undertake the current allocation rules, *INCLUDING* > using /64s for point-to-point circuit. I think you just did with that paragraph, at least a little. Allocation rules change over time, or they are "abused" (for some value of "abused") typically via very sparsely populated block allocations. Is the ITU still lobbying for their own large block allocations for resale/redistribution? That is, to become in effect an RIR (albeit global not regional)? Or if not currently might they again? https://www.linx.net/public-affairs/itu-wants-to-control-ip-address-allocation The article is a few years old but it's been in the air. But we shall know in the fullness of time. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mel at beckman.org Thu Dec 28 21:17:19 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 28 Dec 2017 21:17:19 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <23109.20069.148555.899534@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <071125CA-849A-4D8D-AB45-BD7DAB54E912@beckman.org> <23109.18243.121783.791328@gargle.gargle.HOWL> <289A080C-5F9D-4C54-9570-13ADF7C4C80F@beckman.org>, <23109.20069.148555.899534@gargle.gargle.HOWL> Message-ID: Barry, The absence of data is not data :) -mel beckman > On Dec 28, 2017, at 12:05 PM, "bzs at theworld.com" wrote: > > >> On December 28, 2017 at 19:47 mel at beckman.org (Mel Beckman) wrote: >> the difference between thinking in terms of 128 >> bits vs 2^128 addresses which seem to be conflated in these discussions >> >> >> I think you're wrong. Show me where anyone made a case in this thread at all >> for 2^128 addresses mitigating the problem. Everyone has been discussing >> structured assignments with 128 bits, and several people here have proven to a >> mathematical certainty that no technology here today nor on the horizon can >> exhaust this address space undertake the current allocation rules, *INCLUDING* >> using /64s for point-to-point circuit. > > I think you just did with that paragraph, at least a little. > > Allocation rules change over time, or they are "abused" (for some > value of "abused") typically via very sparsely populated block > allocations. > > Is the ITU still lobbying for their own large block allocations for > resale/redistribution? That is, to become in effect an RIR (albeit > global not regional)? Or if not currently might they again? > > https://www.linx.net/public-affairs/itu-wants-to-control-ip-address-allocation > > The article is a few years old but it's been in the air. > > But we shall know in the fullness of time. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Thu Dec 28 21:31:20 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 13:31:20 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <23109.17022.495829.617613@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> Message-ID: <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> > On Dec 28, 2017, at 11:14 , bzs at theworld.com wrote: > > > Just an interjection but the problem with this "waste" issue often > comes down to those who see 128 bits of address vs those who see 2^128 > addresses. It's not like there were ever anything close to 4 billion > (2^32) usable addresses with IPv4. Part of this is correct (the last sentence). There were closer to 3.2 billion usable IPv4 unicast addresses. > We have entire /8s which are sparsely populated so even if they're 24M > addrs that's of no use to everyone else. Plus other dedicated uses > like multicast. Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that matters much to your argument. > So the problem is segmentation of that 128 bits which makes it look a > lot scarier because 128 is easy to think about, policy-wise, while > 2^128 isn’t. Sure, but that’s intended in the design of IPv6. There’s really no need to think beyond 2^64 because the intent is that a /64 is a single subnet no matter how many or how few machines you want to put on it. Before anyone rolls out the argument about the waste of a /64 for a point to point link with two hosts on it, please consider that the relative difference in waste between a /64 with 10,000 hosts on it and a /64 with 2 hosts on it is less than the rounding error in claiming that a /64 is roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > My wild guess is if we'd just waited a little bit longer to formalize > IPng we'd've more seriously considered variable length addressing with > a byte indicating how many octets in the address even if only 2 > lengths were immediately implemented (4 and 16.) And some scheme to > store those addresses in the packet header, possibly IPv4 backwards > compatible (I know, I know, but here we are!) Unlikely. Variable length addressing in fast switching hardware is “difficult” at best. Further, if you only use an octet (which is what I presume you meant by byte) to set the length of the variable length address, you have a fixed maximum length address of somewhere between 255 and 256 inclusive unless you create other reserved values for that byte and depending on whether you interpret 0 to be 256 or invalid. I think that 256 octet addressing would be pretty unworkable in modern hardware, so you’d have to find some way of defining and then over time changing what the maximum allowed value in that field could be. Now you’ve got all kinds of tables and datastructures in all kinds of software that either need to pre-configure for the maximum size or somehow dynamically allocate memory on the fly for each session and possibly more frequently than that. You don’t have to dig very deep into the implementation details of variable length addressing to see that there’s still, even today, 20 years after the decision was made, it’s not a particularly useful answer. > And we'd've been all set, up to 256 bytes (2K bits) of address. Not really. There’s a lot of implementation detail in there and I don’t think you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms). > If wishes were horses...but I think what I'm saying here will be said > again and again. Not likely… At least not by anyone with credibility. > Too many people answering every concern with "do you have any idea how > many addresses 2^N is?!?!" while drowning out "do you have any idea > how small that N is? We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime. Owen From owen at delong.com Thu Dec 28 21:32:41 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 13:32:41 -0800 Subject: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too) In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: <4B5670A3-CE4A-4C01-B175-BFD2793DEF25@delong.com> > On Dec 28, 2017, at 10:34 , JORDI PALET MARTINEZ wrote: > > This may be useful: > > https://www.ripe.net/publications/docs/ripe-690/ > > Regards, > Jordi > > -----Mensaje original----- > De: NANOG en nombre de Octavio Alvarez > Responder a: > Fecha: jueves, 28 de diciembre de 2017, 19:31 > Para: Owen DeLong > CC: > Asunto: Re: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too) > > On 12/28/2017 11:39 AM, Owen DeLong wrote: >> >>> On Dec 28, 2017, at 09:23 , Octavio Alvarez wrote: >>> >>> On 12/20/2017 12:23 PM, Mike wrote: >>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>> due to ping-pong and just so many technical manuals and other advices, >>>> you are told to "just use a /64' for your point to points. >>> >>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>> exception would be if a router does not support it. >>> >> Best practice used most places is to assign a /64 and put a /127 on the interfaces. >> > > Thanks for the info. Is this documented somewhere? Is there a > disadvantage in letting many P2P links use different /127 networks > within the same /64? Primarily human factors. Owen > > Best regards, > Octavio. > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > From owen at delong.com Thu Dec 28 21:35:08 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 13:35:08 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> Message-ID: <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Sigh… Let’s stop with the IPv4-think. Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer. Owen > On Dec 28, 2017, at 09:55 , Michael Crapse wrote: > > Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. > If that was ipv4 you could recreate the entire internet with that many addresses. > > On 28 December 2017 at 10:39, Owen DeLong > wrote: > > > On Dec 28, 2017, at 09:23 , Octavio Alvarez > wrote: > > > > On 12/20/2017 12:23 PM, Mike wrote: > >> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > >> Call this the 'shavings', in IPv4 for example, when you assign a P2P > >> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > >> due to ping-pong and just so many technical manuals and other advices, > >> you are told to "just use a /64' for your point to points. > > > > Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the > > exception would be if a router does not support it. > > > > Best regards, > > Octavio. > > Best practice used most places is to assign a /64 and put a /127 on the interfaces. > > Owen > > > From marka at isc.org Thu Dec 28 22:22:45 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 09:22:45 +1100 Subject: Waste will kill ipv6 too In-Reply-To: <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: And /48 was chosen as the site size so that we didn’t have to think about that either. It’s large enough to cover almost all sites with additional /48s to be provided if you run out of /64s. Nothing in the last 20+ years has lead me to believe that these decisions were wrong. In fact NOT following these rules has consequences for everybody else as you can’t policy filter at the /48 boundary without collateral damage. I would recommend that all ISP’s using longer prefixes for customer assignment shorten them to /48s. Mark > On 29 Dec 2017, at 8:35 am, Owen DeLong wrote: > > Sigh… Let’s stop with the IPv4-think. > > Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total > address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer. > > Owen > >> On Dec 28, 2017, at 09:55 , Michael Crapse wrote: >> >> Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. >> If that was ipv4 you could recreate the entire internet with that many addresses. >> >> On 28 December 2017 at 10:39, Owen DeLong > wrote: >> >>> On Dec 28, 2017, at 09:23 , Octavio Alvarez > wrote: >>> >>> On 12/20/2017 12:23 PM, Mike wrote: >>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>> due to ping-pong and just so many technical manuals and other advices, >>>> you are told to "just use a /64' for your point to points. >>> >>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>> exception would be if a router does not support it. >>> >>> Best regards, >>> Octavio. >> >> Best practice used most places is to assign a /64 and put a /127 on the interfaces. >> >> Owen >> >> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bellman at nsc.liu.se Thu Dec 28 22:31:25 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Thu, 28 Dec 2017 23:31:25 +0100 Subject: Waste will kill ipv6 too In-Reply-To: <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> Message-ID: <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> On 2017-12-28 22:31, Owen DeLong wrote: > Sure, but that’s intended in the design of IPv6. There’s really no need > to think beyond 2^64 because the intent is that a /64 is a single subnet > no matter how many or how few machines you want to put on it. > Before anyone rolls out the argument about the waste of a /64 for a point > to point link with two hosts on it, please consider that the relative > difference in waste between a /64 with 10,000 hosts on it and a /64 with > 2 hosts on it is less than the rounding error in claiming that a /64 is > roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. [...] > We may, someday, wish we had gone to some value of N larger than 128, > but I seriously doubt it will occur in my lifetime. My problem with the IPv6 addressing scheme is not the waste of 64 bits for the interface identifier, but the lack of bits for the subnet id. 16 bits (as you normally get a /48) is not much for a semi-large organi- zation, and will force many to have a dense address plan, handing out just one or a few subnets at a time, resulting in a patch-work of allocations. 24 bits for subnet id would be more usable. Consider e.g. a university or company campus. There are probably at least 16 departments, so I would like to use 8 bits as department id. Several departments are likely to have offices on more than one floor, or in more than one building, so I would like to let them have 4 bits to specify location, and then 8 bits to specify office/workplace within each location. And allow them to hand out 16 subnets per workplace. That adds up to 24 bits. So a /40 would be nice, not a /48. Similarly, an ISP that wants a structured address plan, e.g. to encode prefecture, city and part of city in the address, will quickly use up bits in the customer id part of the address. /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From james.cutler at consultant.com Thu Dec 28 22:44:46 2017 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 28 Dec 2017 16:44:46 -0600 Subject: Waste will kill ipv6 too In-Reply-To: <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> Message-ID: <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> On Dec 28, 2017, at 4:31 PM, Thomas Bellman wrote: > > On 2017-12-28 22:31, Owen DeLong wrote: > >> Sure, but that’s intended in the design of IPv6. There’s really no need >> to think beyond 2^64 because the intent is that a /64 is a single subnet >> no matter how many or how few machines you want to put on it. > >> Before anyone rolls out the argument about the waste of a /64 for a point >> to point link with two hosts on it, please consider that the relative >> difference in waste between a /64 with 10,000 hosts on it and a /64 with >> 2 hosts on it is less than the rounding error in claiming that a /64 is >> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > > [...] > >> We may, someday, wish we had gone to some value of N larger than 128, >> but I seriously doubt it will occur in my lifetime. > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever. So, you really have no problem with a default /48 site allocation, just with the fact you must do actual work to justify whatever request you make for a network with many sites, or large sites, or both. It should be obvious that this is actually less work than continually fiddling with “dense address plans”. This is why IPv6 should be less costly to deploy and maintain, using standard templates, than IPv4 ever dreamed of being. Please let it be so, > > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. > > Similarly, an ISP that wants a structured address plan, e.g. to encode > prefecture, city and part of city in the address, will quickly use up > bits in the customer id part of the address. > > > /Bellman > From lyndon at orthanc.ca Thu Dec 28 22:50:54 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 14:50:54 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> Message-ID: <3AFA4141-2A6A-4C8B-A306-2AC1C918B03F@orthanc.ca> > On Dec 28, 2017, at 2:31 PM, Thomas Bellman wrote: > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. If you need (and can justify) more than a site /48, you can easily get that. > > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. IPv6 prefixes are not databases. Coding this sort of thing into your address space is silly. You can (and should) track this info externally. It's pretty simple to do this using easily parsable text files. If you encode policy into your address space like this, sooner or later you will find yourself painted into a corner you can't get out of. Instead, carve up the 16bits of subnet space by allocating network bits from left-to-right. This gives you the ability to slice your subnet space into variable-length allocations. When you allocate in the subnet space, do so by bisecting the current network prefix. That gives you room to grow your /64s into something larger, while keeping the routing simple. This is the same thing we've been doing to carve up IPv4 space for years: number hosts right to left, number networks left to right. For IPv6, just s;hosts;/64s;. --lyndon From marka at isc.org Thu Dec 28 22:52:59 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 09:52:59 +1100 Subject: Waste will kill ipv6 too In-Reply-To: <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> Message-ID: > On 29 Dec 2017, at 9:31 am, Thomas Bellman wrote: > > On 2017-12-28 22:31, Owen DeLong wrote: > >> Sure, but that’s intended in the design of IPv6. There’s really no need >> to think beyond 2^64 because the intent is that a /64 is a single subnet >> no matter how many or how few machines you want to put on it. > >> Before anyone rolls out the argument about the waste of a /64 for a point >> to point link with two hosts on it, please consider that the relative >> difference in waste between a /64 with 10,000 hosts on it and a /64 with >> 2 hosts on it is less than the rounding error in claiming that a /64 is >> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > > [...] > >> We may, someday, wish we had gone to some value of N larger than 128, >> but I seriously doubt it will occur in my lifetime. > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. What’s wrong with a dense allocation? That’s what we have routers for. Thats why we have a protocol for prefix delegation. You can do on demand subnet allocation without involving humans. > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. Stop with the IPv4 think. This is all driven by humans allocating addresses. Use the features of IPv6. You have on demand prefix allocation. you have ULA addresses where every student can have their own /48 play space by randomly selecting a ULA /48 prefix. > Similarly, an ISP that wants a structured address plan, e.g. to encode > prefecture, city and part of city in the address, will quickly use up > bits in the customer id part of the address. > > > /Bellman > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From james.cutler at consultant.com Thu Dec 28 23:01:04 2017 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 28 Dec 2017 17:01:04 -0600 Subject: Waste will kill ipv6 too In-Reply-To: <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> Message-ID: On Dec 28, 2017, at 4:31 PM, Thomas Bellman > wrote: > Similarly, an ISP that wants a structured address plan, e.g. to encode > prefecture, city and part of city in the address, will quickly use up > bits in the customer id part of the address. Telephone numbers are a prime example of a type of “structured address plan”. Or, at least, they were. Now we have number portability. The main structural boundary is a country code. Region codes in the US (Area codes) apply across several networks. In some countries, the region code is [landline|cellular] and still applies across several vendors. This is an example of overloading a token with non-functional meanings better left to a well maintained database. If one insists on overloading an IP address with extra meanings, not common with any other deployment, the end result may well be confusion rather than ease of management. From brock at bmwl.co Thu Dec 28 23:28:55 2017 From: brock at bmwl.co (Brock Tice) Date: Thu, 28 Dec 2017 16:28:55 -0700 Subject: Waste will kill ipv6 too In-Reply-To: <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> Message-ID: <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> On 12/28/2017 03:44 PM, James R Cutler wrote: > There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever. We are currently handing out /52s to customers. Based on a reasonable sparse allocation scheme that would account for future growth that seemed like the best option. I can't really see how /52 is too small for a residential customer. I know originally it was supposed to be /48 but after doing a bit of reading I think many people have admitted there is room for nuance. Do you think I could go to ARIN and say, well, we haven't used hardly any of this but based on such-and-such allocation scheme, it would be much better if you gave us a /32 instead of a /36? Also, does anyone know whether ARIN is using sparse allocation, such that if we go back later and ask for more they will just increase the size of our allocation starting from the same point? --Brock From bzs at theworld.com Thu Dec 28 23:35:09 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 28 Dec 2017 18:35:09 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> Message-ID: <23109.32685.103313.666072@gargle.gargle.HOWL> On December 28, 2017 at 13:31 owen at delong.com (Owen DeLong) wrote: > > > On Dec 28, 2017, at 11:14 , bzs at theworld.com wrote: > > > > > > Just an interjection but the problem with this "waste" issue often > > comes down to those who see 128 bits of address vs those who see 2^128 > > addresses. It's not like there were ever anything close to 4 billion > > (2^32) usable addresses with IPv4. > > Part of this is correct (the last sentence). There were closer to 3.2 billion > usable IPv4 unicast addresses. Maybe "usable" doesn't quite express the problem. If someone grabs a /8 and makes little use of it (as happened I believe several times) the issue wasn't only usable but available to anyone but the /8 holder. Whatever, not sure where that goes other than noting that address space allocations are often sparsely utilized. > > > We have entire /8s which are sparsely populated so even if they're 24M > > addrs that's of no use to everyone else. Plus other dedicated uses > > like multicast. > > Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that > matters much to your argument. Oops, right, 24 bits, 16M. > > > So the problem is segmentation of that 128 bits which makes it look a > > lot scarier because 128 is easy to think about, policy-wise, while > > 2^128 isn’t. > > Sure, but that’s intended in the design of IPv6. There’s really no need > to think beyond 2^64 because the intent is that a /64 is a single subnet > no matter how many or how few machines you want to put on it. > > Before anyone rolls out the argument about the waste of a /64 for a point > to point link with two hosts on it, please consider that the relative > difference in waste between a /64 with 10,000 hosts on it and a /64 with > 2 hosts on it is less than the rounding error in claiming that a /64 is > roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. My worry is when pieces of those /64s get allocated for some specific use or non-allocation. For example hey, ITU, here's half our /64s, it's only fair...and their allocations aren't generally available (e.g., only to national-level providers as is their mission.) So the problem isn't for someone who holds a /64 any more than people who are ok w/ whatever IPv4 space they currently hold. It's how one manages to run out of new /64s to allocate, just as we have with, say, IPv4 /16s. If you have one or more /16s and that's enough space for your operation then not a problem. If you need a /16 (again IPv4) right now, that's likely a problem. That's where 128 bits starts to feel smaller and 2^128 addresses a little superfluous if you can't get /bits. > > > My wild guess is if we'd just waited a little bit longer to formalize > > IPng we'd've more seriously considered variable length addressing with > > a byte indicating how many octets in the address even if only 2 > > lengths were immediately implemented (4 and 16.) And some scheme to > > store those addresses in the packet header, possibly IPv4 backwards > > compatible (I know, I know, but here we are!) > > Unlikely. Variable length addressing in fast switching hardware is “difficult” > at best. Further, if you only use an octet (which is what I presume you meant > by byte) to set the length of the variable length address, you have a fixed > maximum length address of somewhere between 255 and 256 inclusive unless you > create other reserved values for that byte and depending on whether you interpret > 0 to be 256 or invalid. I was thinking 256 (255, 254 probably at most) octets of address, not bits. One could effect sub-octet (e.g., 63 bits) addresses in other ways when needed, as we do now, inside a 128 bit (anything larger than 63) address field. > > I think that 256 octet addressing would be pretty unworkable in modern hardware, > so you’d have to find some way of defining and then over time changing what the > maximum allowed value in that field could be. Yes, it would be space to grow. For now we might say that a core router is only obliged to route 4 or 16 octets. But if the day came when we needed 32 octets it wouldn't require a packet redesign, only throwing some "switch" that says ok we're now routing 4/16/32 octet addresses for example. Probably a single router command or two on a capable router. > > Now you’ve got all kinds of tables and datastructures in all kinds of software > that either need to pre-configure for the maximum size or somehow dynamically > allocate memory on the fly for each session and possibly more frequently than > that. That's life in the fast lane! What can I say, the other choice is we run out of address space. One would hope there would be some lead-in time to any expansion, probably years of warning that it's coming. Or we have to implement IPvN (N > 6) with new packet designs which is almost certainly even more painful. At least that variable length field would be a warning that one day it might be larger than 16 octets and it won't take 20+ years next time. > > You don’t have to dig very deep into the implementation details of variable > length addressing to see that there’s still, even today, 20 years after the > decision was made, it’s not a particularly useful answer. It's only important if one tends to agree that the day may come in the foreseeable future when 16 octets is not sufficient. One only gets choices not ideals: a) run out of address space? b) Redesign the packet format entirely? c) Use a variable length address which might well be sufficient for 100 years? Each would have their trade-offs. > > > And we'd've been all set, up to 256 bytes (2K bits) of address. > > Not really. There’s a lot of implementation detail in there and I don’t think > you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM > and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms). Today's smart phones are roughly as powerful as ~20 year old multi-million dollar supercomputers. No one thought that would happen either. But as I said it comes down to choices. Running out of address space is not very attractive either as we have seen. > > > If wishes were horses...but I think what I'm saying here will be said > > again and again. > > Not likely… At least not by anyone with credibility. > > > Too many people answering every concern with "do you have any idea how > > many addresses 2^N is?!?!" while drowning out "do you have any idea > > how small that N is? > > We may, someday, wish we had gone to some value of N larger than 128, > but I seriously doubt it will occur in my lifetime. I'll hang onto that comment :-) > > Owen > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From laszlo at heliacal.net Fri Dec 29 00:09:37 2017 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 29 Dec 2017 00:09:37 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: On 2017-12-28 23:28, Brock Tice wrote: > On 12/28/2017 03:44 PM, James R Cutler wrote: >> There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever. > We are currently handing out /52s to customers. Based on a reasonable > sparse allocation scheme that would account for future growth that > seemed like the best option. > > I can't really see how /52 is too small for a residential customer. I > know originally it was supposed to be /48 but after doing a bit of > reading I think many people have admitted there is room for nuance. > > Do you think I could go to ARIN and say, well, we haven't used hardly > any of this but based on such-and-such allocation scheme, it would be > much better if you gave us a /32 instead of a /36? The minimum size is /32 and you can get a shorter prefix with justification. > Also, does anyone know whether ARIN is using sparse allocation, such > that if we go back later and ask for more they will just increase the > size of our allocation starting from the same point? > > --Brock > From jfbeam at gmail.com Fri Dec 29 00:24:44 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 28 Dec 2017 19:24:44 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong wrote: > Wasting 2^64 addresses was intentional because the original plan was for > a 64-bit total > address and the additional 64 bits was added to make universal 64-bit > subnets a no-brainer. Incorrect. The original 128 address space was split 80+48. That *LATER* became 64+64 to support EUI-64 (vs. 48bit ethernet MACs) A 64bit LAN is, and always will be, an infinitely stupid idea. The reason for that over-optimization in SLAAC never materialized -- the 8bit micro-controlers from the 80s will never run IPv6, so the ability to form your address in 4 lines of ASM is meaningless, even more so when IPSec was bolted on. (later marked optional, but was originally required) SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be 64bits. I've run LANs with longer prefixes for decades. And they work. (the original intent was to keep android devices from using IPv6, as there's no f'ing way to turn it off, or even see it anywhere.) Yes, there are various RFCs saying you need to use /64's, but they're all bunk. SLAAC is the only thing that REQUIRES a /64, and few modifications to your IPv6 source and privacy extensions function just fine with longer prefixes. (don't go nuts and use /120's, unless you like seeing address collisions; DAD is designed to handle that -- and does, but it can take a few rounds to find a free address. I've used /96 on a LAN with ~100 machines without issue.) Back to the main theme... artificially cutting the address space in half, just makes the point even stronger. IPv6 address space is, in fact, half as big as people think it is, because we've drawn a line at /64 -- and the catastrophic part is people *ARE* wiring that into hardware. Every example I've seen people bat around about just how big 2^128 is, ignores the reality of Real World Networking(tm). They ignore infrastructure. The ignore route table size. They ignore the sparse nature of hierarchical address assignment. In the "10B people === 10B /48's" example, that's a dense PI allocation scheme that will lead to a global routing table approaching 10B routes -- you can't aggregate a random selection of /48s -- with zero consideration for how those 10B networks will interconnect. The simple truth is, we're doing the exact same thing with IPv6 that we did with IPv4: "The address space is so mind alteringly large we'll never use even a fraction of it." *pause* "Umm, wait a minute, we're carving this turkey up alarmingly fast." Will we use up the entire thing? Of course we will; it's not, in fact, *infinite*, so we *will* eventually assign all of it. It's going to happen a lot faster than most people think, as we're so cavalier with handing out vast amounts of space for which most people will never use more than (a) one LAN, and (b) a few dozen addresses within that single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. (not that I'll be around to collect) But just like IPv4, some decades down the road, people will see how stupid our allocation scheme really is, and begin a new "classless" era for IPv6. The short of it is, we got here first, so we don't have to give a shit about being efficient or frugal. From jfbeam at gmail.com Fri Dec 29 00:24:46 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 28 Dec 2017 19:24:46 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <3AFA4141-2A6A-4C8B-A306-2AC1C918B03F@orthanc.ca> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <3AFA4141-2A6A-4C8B-A306-2AC1C918B03F@orthanc.ca> Message-ID: On Thu, 28 Dec 2017 17:50:54 -0500, Lyndon Nerenberg wrote: > IPv6 prefixes are not databases. Coding this sort of thing into your > address space is silly. And a 2^64 LAN, or ptp link, isn't? People have been doing this for decades. They did it before NAT! NAT just made it that much easier. This practice, no matter how silly, is not going to die. From bill at herrin.us Fri Dec 29 00:38:17 2017 From: bill at herrin.us (William Herrin) Date: Thu, 28 Dec 2017 19:38:17 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: On Thu, Dec 28, 2017 at 7:24 PM, Ricky Beam wrote: > Back to the main theme... artificially cutting the address space in half, > just makes the point even stronger. IPv6 address space is, in fact, half as > big as people think it is, because we've drawn a line at /64 Hi Ricky, Your math is a little off. Drawing the line at /64 doesn't cut the address space in half, it shrinks it by roughly 19 orders of magnitude. There are 10^38 IPv6 addresses but only 10^19 IPv6 /64 LANs. -- and the catastrophic part is people *ARE* wiring that into hardware. > Every example I've seen people bat around about just how big 2^128 is, > ignores the reality of Real World Networking(tm). They ignore > infrastructure. The ignore route table size. They ignore the sparse nature > of hierarchical address assignment. In the "10B people === 10B /48's" > example, that's a dense PI allocation scheme that will lead to a global > routing table approaching 10B routes -- you can't aggregate a random > selection of /48s -- with zero consideration for how those 10B networks > will interconnect. > > The simple truth is, we're doing the exact same thing with IPv6 that we > did with IPv4: "The address space is so mind alteringly large we'll never > use even a fraction of it." *pause* "Umm, wait a minute, we're carving this > turkey up alarmingly fast." Will we use up the entire thing? Of course we > will; it's not, in fact, *infinite*, so we *will* eventually assign all of > it. It's going to happen a lot faster than most people think, as we're so > cavalier with handing out vast amounts of space for which most people will > never use more than (a) one LAN, and (b) a few dozen addresses within that > single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. > (not that I'll be around to collect) But just like IPv4, some decades down > the road, people will see how stupid our allocation scheme really is, and > begin a new "classless" era for IPv6. The short of it is, we got here > first, so we don't have to give a shit about being efficient or frugal. > Yep. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Fri Dec 29 00:41:25 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 11:41:25 +1100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: <183ED1CD-8BB3-4BD9-847A-486574AD5B41@isc.org> > On 29 Dec 2017, at 11:24 am, Ricky Beam wrote: > > On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong wrote: >> Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total >> address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer. > > Incorrect. The original 128 address space was split 80+48. That *LATER* became 64+64 to support EUI-64 (vs. 48bit ethernet MACs) > > A 64bit LAN is, and always will be, an infinitely stupid idea. The reason for that over-optimization in SLAAC never materialized -- the 8bit micro-controlers from the 80s will never run IPv6, so the ability to form your address in 4 lines of ASM is meaningless, even more so when IPSec was bolted on. (later marked optional, but was originally required) > > SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be 64bits. I've run LANs with longer prefixes for decades. And they work. (the original intent was to keep android devices from using IPv6, as there's no f'ing way to turn it off, or even see it anywhere.) Yes, there are various RFCs saying you need to use /64's, but they're all bunk. SLAAC is the only thing that REQUIRES a /64, and few modifications to your IPv6 source and privacy extensions function just fine with longer prefixes. (don't go nuts and use /120's, unless you like seeing address collisions; DAD is designed to handle that -- and does, but it can take a few rounds to find a free address. I've used /96 on a LAN with ~100 machines without issue.) > > Back to the main theme... artificially cutting the address space in half, just makes the point even stronger. IPv6 address space is, in fact, half as big as people think it is, because we've drawn a line at /64 -- and the catastrophic part is people *ARE* wiring that into hardware. Every example I've seen people bat around about just how big 2^128 is, ignores the reality of Real World Networking(tm). They ignore infrastructure. The ignore route table size. They ignore the sparse nature of hierarchical address assignment. In the "10B people === 10B /48's" example, that's a dense PI allocation scheme that will lead to a global routing table approaching 10B routes -- you can't aggregate a random selection of /48s -- with zero consideration for how those 10B networks will interconnect. > > The simple truth is, we're doing the exact same thing with IPv6 that we did with IPv4: "The address space is so mind alteringly large we'll never use even a fraction of it." *pause* "Umm, wait a minute, we're carving this turkey up alarmingly fast." Will we use up the entire thing? Of course we will; it's not, in fact, *infinite*, so we *will* eventually assign all of it. It's going to happen a lot faster than most people think, as we're so cavalier with handing out vast amounts of space for which most people will never use more than (a) one LAN, and (b) a few dozen addresses within that single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. (not that I'll be around to collect) But just like IPv4, some decades down the road, people will see how stupid our allocation scheme really is, and begin a new "classless" era for IPv6. The short of it is, we got here first, so we don't have to give a shit about being efficient or frugal. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lyndon at orthanc.ca Fri Dec 29 00:57:57 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 16:57:57 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: > On Dec 28, 2017, at 3:28 PM, Brock Tice wrote: > > We are currently handing out /52s to customers. Based on a reasonable > sparse allocation scheme that would account for future growth that > seemed like the best option. Could you detail the reasoning behind your allocation scheme? I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated? What data fed the model you used to come up with those numbers? I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers. I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with. > I can't really see how /52 is too small for a residential customer. I > know originally it was supposed to be /48 but after doing a bit of > reading I think many people have admitted there is room for nuance. What reading? Can you provide pointers to the documents you were reading? Again, I'm curious to understand how and why ISPs are making these decisions. Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't. An ISP's job is to shovel packets around. No more, no less. > Do you think I could go to ARIN and say, well, we haven't used hardly > any of this but based on such-and-such allocation scheme, it would be > much better if you gave us a /32 instead of a /36? Hardly used any of what? Are you talking about density of the customer hosts inside each of these /64 subnets? This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from. Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment? Can you imagine any practical switch fabric that could handle that? (I'd be curious to know the size of the largest - in the number of hosts sense - 10-Gig Ethernet LAN anyone has deployed.) The number of hosts per /64 will always be limited by the associated switch hardware. This will be true until the universe collapses, I suspect. > Also, does anyone know whether ARIN is using sparse allocation, such > that if we go back later and ask for more they will just increase the > size of our allocation starting from the same point? You could just ask them. But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.† But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers? You need to treat IPv6 addresses as being 64 bits long. Those extra 64 bits on the right are just noise – ignore them. Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network. That makes for a densely allocated /48 for each person on the planet. (Coincidence?) But when we get to the point of filling up that /3, we still have five more /3s to work with. Now think about scaling. If the population doubles, we're now down to four spare /3s. If that doubled population doubles the number of devices, we're down to two spare /3s. If the population doubles again, there will be no civilization left, let alone an Internet. Etc. So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes. Each node having its own /64 to address individual endpoints within whatever that 'node' represents. Just think, 2^64 port-443 HTTPS servers per "thing." Isn't this the utopia we've been seeking out? I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space. Not because we run out the numbers of bits allocated to hosts, or subnets, or ports; but because the current topology of routed networks won't fit with what we want or need to do in the future. (My prediction is that everything will move to adhoc meshes, with no control planes at all. But that's completely out of scope for this discussion.) --lyndon † https://www.arin.net/resources/ipv6_planning.html states that ISP allocations for > /32 block sizes is based on a /48 per customer site allocation policy. From lyndon at orthanc.ca Fri Dec 29 01:12:30 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 17:12:30 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: <4E552054-6789-4174-A992-F3A60DBB5A21@orthanc.ca> > On Dec 28, 2017, at 4:57 PM, Lyndon Nerenberg wrote: > > Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population) Of course, I screwed up the numbers (thanks Javier for pointing this out). 2^32 is closer to 2^33 for population, so adjust the netmasks accordingly. From owen at delong.com Fri Dec 29 01:23:29 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 17:23:29 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> Message-ID: <5F1305C0-2BCC-405E-B335-4C0DAF99F724@delong.com> > On Dec 28, 2017, at 14:31, Thomas Bellman wrote: > >> On 2017-12-28 22:31, Owen DeLong wrote: >> >> Sure, but that’s intended in the design of IPv6. There’s really no need >> to think beyond 2^64 because the intent is that a /64 is a single subnet >> no matter how many or how few machines you want to put on it. > >> Before anyone rolls out the argument about the waste of a /64 for a point >> to point link with two hosts on it, please consider that the relative >> difference in waste between a /64 with 10,000 hosts on it and a /64 with >> 2 hosts on it is less than the rounding error in claiming that a /64 is >> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > > [...] > >> We may, someday, wish we had gone to some value of N larger than 128, >> but I seriously doubt it will occur in my lifetime. > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. That’s absurd. The intent is a /48 per end SITE. Not per organization. According to ARIN policies, the definition of an end site is a single building or structure or a single tenant within a multi-tenant building or structure. With nibble boundary round-up in policy, an organization with more than one site can get at least 16 /48s. Further, a university could (technically) get a /48 for every dorm room. > > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. A campus is, by definition multiple end sites. > > Similarly, an ISP that wants a structured address plan, e.g. to encode > prefecture, city and part of city in the address, will quickly use up > bits in the customer id part of the address. > An ISP can qualify for up to a /12 in a single allocation. They get two levels of hierarchy at which they can aggregate and do a nibble-boundary round-up. As such, I’m not sure how many bits you want for that that you feel you can’t have. Remember, /32 is just the default no questions asked minimum v6 isp allocation. Not the maximum. I know of at least three isps that have /24s or more of ipv6 space. > > /Bellman > Owen From owen at delong.com Fri Dec 29 01:28:34 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 17:28:34 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: > On Dec 28, 2017, at 15:28, Brock Tice wrote: > >> On 12/28/2017 03:44 PM, James R Cutler wrote: >> There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever. > > We are currently handing out /52s to customers. Based on a reasonable > sparse allocation scheme that would account for future growth that > seemed like the best option. > > I can't really see how /52 is too small for a residential customer. I > know originally it was supposed to be /48 but after doing a bit of > reading I think many people have admitted there is room for nuance. > > Do you think I could go to ARIN and say, well, we haven't used hardly > any of this but based on such-and-such allocation scheme, it would be > much better if you gave us a /32 instead of a /36? Yes. In fact, having authored the policy that allows this, I know you can. > > Also, does anyone know whether ARIN is using sparse allocation, such > that if we go back later and ask for more they will just increase the > size of our allocation starting from the same point? Yes. They are. Likely you would have no trouble with this. Owen DeLong Member, ARIN AC Speaking only for myself > > --Brock From surfer at mauigateway.com Fri Dec 29 01:34:23 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 28 Dec 2017 17:34:23 -0800 Subject: Waste will kill ipv6 too Message-ID: <20171228173423.2D1E77CC@m0117457.ppops.net> :: Now think about scaling. Yes :: If the population doubles, we're now down to four spare /3s. :: If that doubled population doubles the number of devices, :: we're down to two spare /3s. If the population doubles :: again, there will be no civilization left, let alone an :: Internet. Etc. So realistically, the current address space :: allocation policies can handle a doubling of the planet's :: population, with each person having a quarter of a million :: addressable nodes. Each node having its own /64 to address :: individual endpoints within whatever that 'node' represents. Space: the final IP frontier These are the voyages of the range of IPv6 Its many-year mission: to explore strange new device implementations; to seek out new planet-covering nano-device applications and new ad-hoc networking technologies; to boldly go via DTN where no internet segment has gone before. :: Isn't this the utopia we've been seeking out? I like that one! :-) scott From michael at wi-fiber.io Fri Dec 29 01:46:12 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 28 Dec 2017 18:46:12 -0700 Subject: Waste will kill ipv6 too In-Reply-To: <20171228173423.2D1E77CC@m0117457.ppops.net> References: <20171228173423.2D1E77CC@m0117457.ppops.net> Message-ID: As a small local ISP, our upstream isn't willing to give us more than a /48, their statement "Here's a /48 that will give you unlimited addresses that you'll never run out of". Therefore we give businesses /60s and residentials /64. If only we could do as suggested here and give everyone a /48, hah. It would be awesome if we could get an AS number but as we're not multihomed, nor big enough to warrant ARIN paying us attention, we're at the mercy of our upstream who also unwilling to part with more than a single ipv4 /24 at a $300/mo surcharge, and forcing us into buying ipv4 subnets that have been randomly blacklisted on sites such as HULU, netflix, or others. I agree with the sentiment that we should have only 48 bits in the networking portion as that does allow a 48bit mac to exist. mac collisions happen so little, that it would make more sense for DAD to step in if it does occur. Most hardware addresses are changeable anyway and should probably be changed if on the same network. I am inexperienced enough to not understand any necessary usefulness of a /64 network mask over a /80. On 28 December 2017 at 18:34, Scott Weeks wrote: > > :: Now think about scaling. > > Yes > > > :: If the population doubles, we're now down to four spare /3s. > :: If that doubled population doubles the number of devices, > :: we're down to two spare /3s. If the population doubles > :: again, there will be no civilization left, let alone an > :: Internet. Etc. So realistically, the current address space > :: allocation policies can handle a doubling of the planet's > :: population, with each person having a quarter of a million > :: addressable nodes. Each node having its own /64 to address > :: individual endpoints within whatever that 'node' represents. > > Space: the final IP frontier > These are the voyages of the range of IPv6 > Its many-year mission: > to explore strange new device implementations; > to seek out new planet-covering nano-device applications and new ad-hoc > networking technologies; > to boldly go via DTN where no internet segment has gone before. > > > > :: Isn't this the utopia we've been seeking out? > > I like that one! :-) > > scott > From owen at delong.com Fri Dec 29 01:48:56 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 17:48:56 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <23109.32685.103313.666072@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <23109.32685.103313.666072@gargle.gargle.HOWL> Message-ID: >> > My worry is when pieces of those /64s get allocated for some specific > use or non-allocation. For example hey, ITU, here's half our /64s, > it's only fair...and their allocations aren't generally available > (e.g., only to national-level providers as is their mission.) Why would anyone give the ITU such an allocation? Worst I could imagine would be giving them a /3 same as IANA, but more likely IANA would issue them /12s like any other RIR. Even with that, since that would relieve the RIRs of responsibility for national providers, I think it still works out ok. > > So the problem isn't for someone who holds a /64 any more than people > who are ok w/ whatever IPv4 space they currently hold. > > It's how one manages to run out of new /64s to allocate, just as we > have with, say, IPv4 /16s. If you have one or more /16s and that's > enough space for your operation then not a problem. If you need a /16 > (again IPv4) right now, that's likely a problem. There’s quite a bit of difference between 65536 /16s and 18 quintillion /64s. > > That's where 128 bits starts to feel smaller and 2^128 addresses a > little superfluous if you can't get /bits. Again, even you haven’t presented a credible scenario in which we deplete the /64 inventory at IANA, let alone the inventory IETF holds in reserve that hasn’t been released to IANA. (IANA Holds most of a /3 of which they have issued a little more than 5 of the 512 /12s it contains, IETF is holding all of 5 and most of another 2 /3 blocks that haven’t been designated yet as unicast). > >> >>> My wild guess is if we'd just waited a little bit longer to formalize >>> IPng we'd've more seriously considered variable length addressing with >>> a byte indicating how many octets in the address even if only 2 >>> lengths were immediately implemented (4 and 16.) And some scheme to >>> store those addresses in the packet header, possibly IPv4 backwards >>> compatible (I know, I know, but here we are!) >> >> Unlikely. Variable length addressing in fast switching hardware is “difficult” >> at best. Further, if you only use an octet (which is what I presume you meant >> by byte) to set the length of the variable length address, you have a fixed >> maximum length address of somewhere between 255 and 256 inclusive unless you >> create other reserved values for that byte and depending on whether you interpret >> 0 to be 256 or invalid. > > I was thinking 256 (255, 254 probably at most) octets of address, not > bits. > > One could effect sub-octet (e.g., 63 bits) addresses in other ways > when needed, as we do now, inside a 128 bit (anything larger than 63) > address field. > >> >> I think that 256 octet addressing would be pretty unworkable in modern hardware, >> so you’d have to find some way of defining and then over time changing what the >> maximum allowed value in that field could be. > > Yes, it would be space to grow. For now we might say that a core > router is only obliged to route 4 or 16 octets. > > But if the day came when we needed 32 octets it wouldn't require a > packet redesign, only throwing some "switch" that says ok we're now > routing 4/16/32 octet addresses for example. > > Probably a single router command or two on a capable router. This reflects a gross misunderstanding of how fast switching hardware works today. > >> >> Now you’ve got all kinds of tables and datastructures in all kinds of software >> that either need to pre-configure for the maximum size or somehow dynamically >> allocate memory on the fly for each session and possibly more frequently than >> that. > > That's life in the fast lane! What can I say, the other choice is we > run out of address space. One would hope there would be some lead-in > time to any expansion, probably years of warning that it's coming. Well... I’m betting the first /3 lasts at least 50-100 years. If that’s true, the other 5+ should provide plenty of lead time for that so long as we get cracking once we exhaust the first /3. > > Or we have to implement IPvN (N > 6) with new packet designs which is > almost certainly even more painful. Meh. Not necessarily. It would, for example, be nice to have a destination ASN field in the packet header or some other provision for locator/ID split. > > At least that variable length field would be a warning that one day it > might be larger than 16 octets and it won't take 20+ years next time. That’s very optimistic to say the least. > >> >> You don’t have to dig very deep into the implementation details of variable >> length addressing to see that there’s still, even today, 20 years after the >> decision was made, it’s not a particularly useful answer. > > It's only important if one tends to agree that the day may come in the > foreseeable future when 16 octets is not sufficient. Nope. If you make variable part of the spec, then you require responsible manufacturers to implement variable even if it’s unlikely that the variable will change within the life of the hardware. > > One only gets choices not ideals: a) run out of address space? b) > Redesign the packet format entirely? c) Use a variable length address > which might well be sufficient for 100 years? If we run out of ipv6 addresses in less than 100 years, I will be very surprised. Can you provide a credible scenario under which that happens? > > Each would have their trade-offs. > >> >>> And we'd've been all set, up to 256 bytes (2K bits) of address. >> >> Not really. There’s a lot of implementation detail in there and I don’t think >> you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM >> and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms). > > Today's smart phones are roughly as powerful as ~20 year old > multi-million dollar supercomputers. No one thought that would happen > either. Not entirely true. > > But as I said it comes down to choices. Running out of address space > is not very attractive either as we have seen. Meh... I think actually running out will be an improvement over where we are today. Owen > >> >>> If wishes were horses...but I think what I'm saying here will be said >>> again and again. >> >> Not likely… At least not by anyone with credibility. >> >>> Too many people answering every concern with "do you have any idea how >>> many addresses 2^N is?!?!" while drowning out "do you have any idea >>> how small that N is? >> >> We may, someday, wish we had gone to some value of N larger than 128, >> but I seriously doubt it will occur in my lifetime. > > I'll hang onto that comment :-) > >> >> Owen >> > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From lyndon at orthanc.ca Fri Dec 29 01:55:00 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 17:55:00 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <20171228173423.2D1E77CC@m0117457.ppops.net> References: <20171228173423.2D1E77CC@m0117457.ppops.net> Message-ID: <88717F54-3B8C-42A1-826B-E976A4A6754D@orthanc.ca> > :: Isn't this the utopia we've been seeking out? > > I like that one! :-) Seriously. If we run out of networks while handing out /48s, by migrating everything to HTTPS we can claw back the 16 bit 'port' field in the IP header and reassign it as part of the 140-bit IPv6.1 address space. Mind you, the FCC will likely auction off those extra 16 bits to Amazon, so you'll need a Prime membership to use them. --lyndon From valdis.kletnieks at vt.edu Fri Dec 29 01:56:18 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 28 Dec 2017 20:56:18 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <23109.17022.495829.617613@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> Message-ID: <563.1514512578@turing-police.cc.vt.edu> On Thu, 28 Dec 2017 14:14:06 -0500, bzs at theworld.com said: > My wild guess is if we'd just waited a little bit longer to formalize > IPng we'd've more seriously considered variable length addressing with > a byte indicating how many octets in the address even if only 2 > lengths were immediately implemented (4 and 16.) Actually, that got heaved over the side fairly early in the IPng discussion, because nobody who was building silicon last century wanted to deal with arbitrary-length addresses. The IPv4 header had source and destination addresses on 4-byte boundaries for good reasons which still held true when we did the IPv6 headers. And "even if only 2 lengths were implemented" is a non-starter, because whenever you decide that 7 should be allowed too, you *still* have to do a forklift upgrade on all the stuff that's got 4/16 baked into the silicon. Variable length was only going to work if it was in there from the start - otherwise you never get the first user of 8-byte or 20-byte to interoperate (in other words, the same exact problem we have right now getting legacy IPv4 to talk to anybody who isn't also doing IPv4). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From owen at delong.com Fri Dec 29 02:05:33 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 18:05:33 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: > [snip... I hate slash, I hate android, blah balh] > > Back to the main theme... artificially cutting the address space in half, just makes the point even stronger. IPv6 address space is, in fact, half as big as people think it is, because we've drawn a line at /64 -- and the catastrophic part is people *ARE* Incorrect... If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. However, I have to wonder why you think we will burn through 18 quintillion /64s, even with the current scheme? Put another way, that’s roughly 281 trillion /48 end sites. > wiring that into hardware. Every example I've seen people bat around about just how big 2^128 is, ignores the reality of Real World Networking(tm). They ignore infrastructure. The ignore route table size. They ignore the sparse nature of hierarchical address assignment. In the "10B people === 10B /48's" example, that's a dense PI allocation scheme that will lead to a global routing table approaching 10B routes -- you can't aggregate a random selection of /48s -- with zero consideration for how those 10B networks will interconnect. Most of the time, I use the 10B people = 200B /48s, or less than 1/1000th of the total address space. (2.5x for sparse and infrastructure and 8x for provider free pools). The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. > > The simple truth is, we're doing the exact same thing with IPv6 that we did with IPv4: "The address space is so mind alteringly large we'll never use even a fraction of it." *pause* "Umm, wait a minute, we're carving this turkey up alarmingly fast." Will we use up the entire thing? Of course we will; it's not, in fact, *infinite*, so we *will* eventually assign all of it. It's going to happen a lot faster than most people think, as we're so cavalier with handing out vast amounts of space for which most people will never use more than (a) one LAN, and (b) a few dozen addresses within that single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. (not that I'll be around to collect) But just like IPv4, some decades down the road, people will see how stupid our allocation scheme really is, and begin a new "classless" era for IPv6. The short of it is, we got here first, so we don't have to give a shit about being efficient or frugal. Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. I’m not saying we won’t ever run out, but I am saying that nobody alive today is likely to see it. Owen From surfer at mauigateway.com Fri Dec 29 02:11:20 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 28 Dec 2017 18:11:20 -0800 Subject: Waste will kill ipv6 too Message-ID: <20171228181120.2D1E7749@m0117457.ppops.net> > :: Isn't this the utopia we've been seeking out? > > I like that one! :-) >> Seriously. All I was trying to say is there're going to be things not thought of yet that will chew up address space faster than ever before now that everyone believes it's essentially inexhaustible. And, I expect, sooner than imagined. scott From owen at delong.com Fri Dec 29 02:12:01 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Dec 2017 18:12:01 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <20171228173423.2D1E77CC@m0117457.ppops.net> Message-ID: <023140F4-47B0-4404-9843-3218C94427FE@delong.com> You should go directly to ARIN, get a proper ISP allocation the size you need and have your upstream route that. Owen > On Dec 28, 2017, at 17:46, Michael Crapse wrote: > > As a small local ISP, our upstream isn't willing to give us more than a > /48, their statement "Here's a /48 that will give you unlimited addresses > that you'll never run out of". Therefore we give businesses /60s and > residentials /64. If only we could do as suggested here and give everyone a > /48, hah. It would be awesome if we could get an AS number but as we're not > multihomed, nor big enough to warrant ARIN paying us attention, we're at > the mercy of our upstream who also unwilling to part with more than a > single ipv4 /24 at a $300/mo surcharge, and forcing us into buying ipv4 > subnets that have been randomly blacklisted on sites such as HULU, netflix, > or others. > > I agree with the sentiment that we should have only 48 bits in the > networking portion as that does allow a 48bit mac to exist. mac collisions > happen so little, that it would make more sense for DAD to step in if it > does occur. Most hardware addresses are changeable anyway and should > probably be changed if on the same network. I am inexperienced enough to > not understand any necessary usefulness of a /64 network mask over a /80. > >> On 28 December 2017 at 18:34, Scott Weeks wrote: >> >> >> :: Now think about scaling. >> >> Yes >> >> >> :: If the population doubles, we're now down to four spare /3s. >> :: If that doubled population doubles the number of devices, >> :: we're down to two spare /3s. If the population doubles >> :: again, there will be no civilization left, let alone an >> :: Internet. Etc. So realistically, the current address space >> :: allocation policies can handle a doubling of the planet's >> :: population, with each person having a quarter of a million >> :: addressable nodes. Each node having its own /64 to address >> :: individual endpoints within whatever that 'node' represents. >> >> Space: the final IP frontier >> These are the voyages of the range of IPv6 >> Its many-year mission: >> to explore strange new device implementations; >> to seek out new planet-covering nano-device applications and new ad-hoc >> networking technologies; >> to boldly go via DTN where no internet segment has gone before. >> >> >> >> :: Isn't this the utopia we've been seeking out? >> >> I like that one! :-) >> >> scott >> From lyndon at orthanc.ca Fri Dec 29 02:15:45 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 18:15:45 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <20171228181120.2D1E7749@m0117457.ppops.net> References: <20171228181120.2D1E7749@m0117457.ppops.net> Message-ID: <4DD0A6B6-EA50-4A04-A0E4-8948FEF2E754@orthanc.ca> > On Dec 28, 2017, at 6:11 PM, Scott Weeks wrote: > > All I was trying to say is there're going to be things > not thought of yet that will chew up address space > faster than ever before now that everyone believes it's > essentially inexhaustible. And, I expect, sooner than > imagined. If that's the case, it will be because there were few restrictions placed upon that address space. And if some genius comes up with something that burns through all the IPv6 address space, you can rest assured the market (and not the IETF) will come up with a replacement that extends things beyond 128 bits in a ripping big hurry. From bzs at theworld.com Fri Dec 29 02:26:24 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 28 Dec 2017 21:26:24 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <23109.32685.103313.666072@gargle.gargle.HOWL> Message-ID: <23109.42960.107414.652901@gargle.gargle.HOWL> On December 28, 2017 at 17:48 owen at delong.com (Owen DeLong) wrote: > >> > > My worry is when pieces of those /64s get allocated for some specific > > use or non-allocation. For example hey, ITU, here's half our /64s, > > it's only fair...and their allocations aren't generally available > > (e.g., only to national-level providers as is their mission.) > > Why would anyone give the ITU such an allocation? Worst I could imagine would be giving them a /3 same as IANA, but more likely IANA would issue them /12s like any other RIR. Even with that, since that would relieve the RIRs of responsibility for national providers, I think it still works out ok. Give? That makes it sound so voluntary, which likely it will be presented as. It's just an example of some not completely unlikely near-future scenario. It is true that if someone were to get a hypothetical ITU allocation they probably wouldn't need an RIR allocation so mostly zero-sum in that case. Unless policies developed (from ITU) which amounted to hoarding or very "wasteful" (by someone's definition) usage. > > > > > So the problem isn't for someone who holds a /64 any more than people > > who are ok w/ whatever IPv4 space they currently hold. > > > > It's how one manages to run out of new /64s to allocate, just as we > > have with, say, IPv4 /16s. If you have one or more /16s and that's > > enough space for your operation then not a problem. If you need a /16 > > (again IPv4) right now, that's likely a problem. > > There’s quite a bit of difference between 65536 /16s and 18 quintillion /64s. > > > > > > That's where 128 bits starts to feel smaller and 2^128 addresses a > > little superfluous if you can't get /bits. > > Again, even you haven’t presented a credible scenario in which we deplete the /64 inventory at IANA, let alone the inventory IETF holds in reserve that hasn’t been released to IANA. (IANA Holds most of a /3 of which they have issued a little more than 5 of the 512 /12s it contains, IETF is holding all of 5 and most of another 2 /3 blocks that haven’t been designated yet as unicast). This all started as more of a hypothetical, that 128 bits isn't all that huge other than when one starts talking about 2^128 (or 2^64, whatever.) I'll admit the POTS system has been very conservative about expanding their number space even as service became more ubiquitous, including the growth of mobile service which generally fits right into the POTS number schemes. (quoting the rest just for completeness, no more from me.) > > > > >> > >>> My wild guess is if we'd just waited a little bit longer to formalize > >>> IPng we'd've more seriously considered variable length addressing with > >>> a byte indicating how many octets in the address even if only 2 > >>> lengths were immediately implemented (4 and 16.) And some scheme to > >>> store those addresses in the packet header, possibly IPv4 backwards > >>> compatible (I know, I know, but here we are!) > >> > >> Unlikely. Variable length addressing in fast switching hardware is “difficult” > >> at best. Further, if you only use an octet (which is what I presume you meant > >> by byte) to set the length of the variable length address, you have a fixed > >> maximum length address of somewhere between 255 and 256 inclusive unless you > >> create other reserved values for that byte and depending on whether you interpret > >> 0 to be 256 or invalid. > > > > I was thinking 256 (255, 254 probably at most) octets of address, not > > bits. > > > > One could effect sub-octet (e.g., 63 bits) addresses in other ways > > when needed, as we do now, inside a 128 bit (anything larger than 63) > > address field. > > > >> > >> I think that 256 octet addressing would be pretty unworkable in modern hardware, > >> so you’d have to find some way of defining and then over time changing what the > >> maximum allowed value in that field could be. > > > > Yes, it would be space to grow. For now we might say that a core > > router is only obliged to route 4 or 16 octets. > > > > But if the day came when we needed 32 octets it wouldn't require a > > packet redesign, only throwing some "switch" that says ok we're now > > routing 4/16/32 octet addresses for example. > > > > Probably a single router command or two on a capable router. > > This reflects a gross misunderstanding of how fast switching hardware works today. > > > > >> > >> Now you’ve got all kinds of tables and datastructures in all kinds of software > >> that either need to pre-configure for the maximum size or somehow dynamically > >> allocate memory on the fly for each session and possibly more frequently than > >> that. > > > > That's life in the fast lane! What can I say, the other choice is we > > run out of address space. One would hope there would be some lead-in > > time to any expansion, probably years of warning that it's coming. > > Well... I’m betting the first /3 lasts at least 50-100 years. If that’s true, the other 5+ should provide plenty of lead time for that so long as we get cracking once we exhaust the first /3. > > > > > Or we have to implement IPvN (N > 6) with new packet designs which is > > almost certainly even more painful. > > Meh. Not necessarily. It would, for example, be nice to have a destination ASN field in the packet header or some other provision for locator/ID split. > > > > At least that variable length field would be a warning that one day it > > might be larger than 16 octets and it won't take 20+ years next time. > > That’s very optimistic to say the least. > > > > >> > >> You don’t have to dig very deep into the implementation details of variable > >> length addressing to see that there’s still, even today, 20 years after the > >> decision was made, it’s not a particularly useful answer. > > > > It's only important if one tends to agree that the day may come in the > > foreseeable future when 16 octets is not sufficient. > > Nope. If you make variable part of the spec, then you require responsible manufacturers to implement variable even if it’s unlikely that the variable will change within the life of the hardware. > > > > > One only gets choices not ideals: a) run out of address space? b) > > Redesign the packet format entirely? c) Use a variable length address > > which might well be sufficient for 100 years? > > If we run out of ipv6 addresses in less than 100 years, I will be very surprised. > > Can you provide a credible scenario under which that happens? > > > > > Each would have their trade-offs. > > > >> > >>> And we'd've been all set, up to 256 bytes (2K bits) of address. > >> > >> Not really. There’s a lot of implementation detail in there and I don’t think > >> you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM > >> and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms). > > > > Today's smart phones are roughly as powerful as ~20 year old > > multi-million dollar supercomputers. No one thought that would happen > > either. > > Not entirely true. > > > > But as I said it comes down to choices. Running out of address space > > is not very attractive either as we have seen. > > Meh... I think actually running out will be an improvement over where we are today. > > > Owen > > > > >> > >>> If wishes were horses...but I think what I'm saying here will be said > >>> again and again. > >> > >> Not likely… At least not by anyone with credibility. > >> > >>> Too many people answering every concern with "do you have any idea how > >>> many addresses 2^N is?!?!" while drowning out "do you have any idea > >>> how small that N is? > >> > >> We may, someday, wish we had gone to some value of N larger than 128, > >> but I seriously doubt it will occur in my lifetime. > > > > I'll hang onto that comment :-) > > > >> > >> Owen > >> > > > > -- > > -Barry Shein > > > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > > The World: Since 1989 | A Public Information Utility | *oo* > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From lyndon at orthanc.ca Fri Dec 29 02:41:52 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 18:41:52 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <4DD0A6B6-EA50-4A04-A0E4-8948FEF2E754@orthanc.ca> References: <20171228181120.2D1E7749@m0117457.ppops.net> <4DD0A6B6-EA50-4A04-A0E4-8948FEF2E754@orthanc.ca> Message-ID: <1E65ECC4-E788-4035-A329-396A779F5D7D@orthanc.ca> Peripherally, it's worth noting that, in far less time then we have not migrated from IPv4 to IPv6, the UK moved from 7-digit to 11-digit telephone numbers. If that's not embarrassing ... --lyndon From large.hadron.collider at gmx.com Fri Dec 29 02:51:50 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Thu, 28 Dec 2017 18:51:50 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <23109.32685.103313.666072@gargle.gargle.HOWL> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <23109.32685.103313.666072@gargle.gargle.HOWL> Message-ID: IPv6 space is being wasted. We know that much. No one needs more than 8 bits for site-local global addresses in the upper 64 (2/3xxx:xxxx:xxxx:xxxx::/64) of the address. I'm about to propose the most harebrained idea NANOG has ever seen. I feel like supersites are getting more addresses than they really need. For this purpose, an address is an upper 56, not a full 128-bit address (that's a device address, for this purpose...) A supersite is an ISP, or some other autonomous system fragment. The current system I've seen, where Sprint's address group appears to literally be 2600:0::/29... Sure that anticipates future growth of Sprint's network, but it doesn't take into account the needs of other supersites. My proposal is that all addresses be assigned in groups of /48s or even /52s (xxxx:xxxx:xxxx:yy00:) for supersites that don't anticipate much growth, and that supersites should have to forfeit all upper 56 or something addresses they haven't had one routable device address on for over 6 months. On 28/12/2017 15:35, bzs at theworld.com wrote: > On December 28, 2017 at 13:31 owen at delong.com (Owen DeLong) wrote: > > > > > On Dec 28, 2017, at 11:14 , bzs at theworld.com wrote: > > > > > > > > > Just an interjection but the problem with this "waste" issue often > > > comes down to those who see 128 bits of address vs those who see 2^128 > > > addresses. It's not like there were ever anything close to 4 billion > > > (2^32) usable addresses with IPv4. > > > > Part of this is correct (the last sentence). There were closer to 3.2 billion > > usable IPv4 unicast addresses. > > Maybe "usable" doesn't quite express the problem. If someone grabs a > /8 and makes little use of it (as happened I believe several times) > the issue wasn't only usable but available to anyone but the /8 > holder. > > Whatever, not sure where that goes other than noting that address > space allocations are often sparsely utilized. > > > > > > We have entire /8s which are sparsely populated so even if they're 24M > > > addrs that's of no use to everyone else. Plus other dedicated uses > > > like multicast. > > > > Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that > > matters much to your argument. > > Oops, right, 24 bits, 16M. > > > > > > So the problem is segmentation of that 128 bits which makes it look a > > > lot scarier because 128 is easy to think about, policy-wise, while > > > 2^128 isn’t. > > > > Sure, but that’s intended in the design of IPv6. There’s really no need > > to think beyond 2^64 because the intent is that a /64 is a single subnet > > no matter how many or how few machines you want to put on it. > > > > Before anyone rolls out the argument about the waste of a /64 for a point > > to point link with two hosts on it, please consider that the relative > > difference in waste between a /64 with 10,000 hosts on it and a /64 with > > 2 hosts on it is less than the rounding error in claiming that a /64 is > > roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > > My worry is when pieces of those /64s get allocated for some specific > use or non-allocation. For example hey, ITU, here's half our /64s, > it's only fair...and their allocations aren't generally available > (e.g., only to national-level providers as is their mission.) > > So the problem isn't for someone who holds a /64 any more than people > who are ok w/ whatever IPv4 space they currently hold. > > It's how one manages to run out of new /64s to allocate, just as we > have with, say, IPv4 /16s. If you have one or more /16s and that's > enough space for your operation then not a problem. If you need a /16 > (again IPv4) right now, that's likely a problem. > > That's where 128 bits starts to feel smaller and 2^128 addresses a > little superfluous if you can't get /bits. > > > > > > My wild guess is if we'd just waited a little bit longer to formalize > > > IPng we'd've more seriously considered variable length addressing with > > > a byte indicating how many octets in the address even if only 2 > > > lengths were immediately implemented (4 and 16.) And some scheme to > > > store those addresses in the packet header, possibly IPv4 backwards > > > compatible (I know, I know, but here we are!) > > > > Unlikely. Variable length addressing in fast switching hardware is “difficult” > > at best. Further, if you only use an octet (which is what I presume you meant > > by byte) to set the length of the variable length address, you have a fixed > > maximum length address of somewhere between 255 and 256 inclusive unless you > > create other reserved values for that byte and depending on whether you interpret > > 0 to be 256 or invalid. > > I was thinking 256 (255, 254 probably at most) octets of address, not > bits. > > One could effect sub-octet (e.g., 63 bits) addresses in other ways > when needed, as we do now, inside a 128 bit (anything larger than 63) > address field. > > > > > I think that 256 octet addressing would be pretty unworkable in modern hardware, > > so you’d have to find some way of defining and then over time changing what the > > maximum allowed value in that field could be. > > Yes, it would be space to grow. For now we might say that a core > router is only obliged to route 4 or 16 octets. > > But if the day came when we needed 32 octets it wouldn't require a > packet redesign, only throwing some "switch" that says ok we're now > routing 4/16/32 octet addresses for example. > > Probably a single router command or two on a capable router. > > > > > Now you’ve got all kinds of tables and datastructures in all kinds of software > > that either need to pre-configure for the maximum size or somehow dynamically > > allocate memory on the fly for each session and possibly more frequently than > > that. > > That's life in the fast lane! What can I say, the other choice is we > run out of address space. One would hope there would be some lead-in > time to any expansion, probably years of warning that it's coming. > > Or we have to implement IPvN (N > 6) with new packet designs which is > almost certainly even more painful. > > At least that variable length field would be a warning that one day it > might be larger than 16 octets and it won't take 20+ years next time. > > > > > You don’t have to dig very deep into the implementation details of variable > > length addressing to see that there’s still, even today, 20 years after the > > decision was made, it’s not a particularly useful answer. > > It's only important if one tends to agree that the day may come in the > foreseeable future when 16 octets is not sufficient. > > One only gets choices not ideals: a) run out of address space? b) > Redesign the packet format entirely? c) Use a variable length address > which might well be sufficient for 100 years? > > Each would have their trade-offs. > > > > > > And we'd've been all set, up to 256 bytes (2K bits) of address. > > > > Not really. There’s a lot of implementation detail in there and I don’t think > > you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM > > and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms). > > Today's smart phones are roughly as powerful as ~20 year old > multi-million dollar supercomputers. No one thought that would happen > either. > > But as I said it comes down to choices. Running out of address space > is not very attractive either as we have seen. > > > > > > If wishes were horses...but I think what I'm saying here will be said > > > again and again. > > > > Not likely… At least not by anyone with credibility. > > > > > Too many people answering every concern with "do you have any idea how > > > many addresses 2^N is?!?!" while drowning out "do you have any idea > > > how small that N is? > > > > We may, someday, wish we had gone to some value of N larger than 128, > > but I seriously doubt it will occur in my lifetime. > > I'll hang onto that comment :-) > > > > > Owen > > > From jfbeam at gmail.com Fri Dec 29 02:54:45 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 28 Dec 2017 21:54:45 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <4DD0A6B6-EA50-4A04-A0E4-8948FEF2E754@orthanc.ca> References: <20171228181120.2D1E7749@m0117457.ppops.net> <4DD0A6B6-EA50-4A04-A0E4-8948FEF2E754@orthanc.ca> Message-ID: On Thu, 28 Dec 2017 21:15:45 -0500, Lyndon Nerenberg wrote: >> On Dec 28, 2017, at 6:11 PM, Scott Weeks wrote: > If that's the case, it will be because there were few restrictions > placed upon that address space. > > And if some genius comes up with something that burns through all the > IPv6 address space, you can rest assured the market (and not the IETF) > will come up with a replacement that extends things beyond 128 bits in a > ripping big hurry. Like IPv6 came along in a "ripping big hurry"? It's been over 20 years, and I still don't have a commercial ISP providing me IPv6. And my home connection doesn't get v6 because the lame idiots at Earthlink never gave TWC any of the dozens of prefixes they own but don't announce. (and the twc link at work... (a) "not enabled on the headend", and (b) doesn't work through a Ubee) From jfbeam at gmail.com Fri Dec 29 02:54:46 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 28 Dec 2017 21:54:46 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong wrote: > If you want to make that argument, that we shouldn’t have SLAAC and we > should use /96 prefixes, that wouldn’t double the space, it would > multiply it by roughly 4 billion. I'm saying I should be able to use whatever size LAN I want. > The routing problem might be real if everyone goes to PI, but I think > that’s an unlikely scenario. Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. > Your definition of “amazingly fast is pretty odd... we’ve allocated tiny > fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, > unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast > space for distribution to the RIRs. Of that /3, IANA has delegated a > little more than 5 /12s to RIRs. That’s the total of 20 years worth of > turkey carving and constitutes well under 1/8th of the address space. > Issued. By that measure, we’ve got well over 160 years to worry about > runout. After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) From kmedcalf at dessus.com Fri Dec 29 03:03:46 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 28 Dec 2017 20:03:46 -0700 Subject: Waste will kill ipv6 too In-Reply-To: Message-ID: <09bd28258cf5334c81accdcf2aa990d6@mail.dessus.com> >> If you want to make that argument, that we shouldn’t have SLAAC and >> we should use /96 prefixes, that wouldn’t double the space, it would >> multiply it by roughly 4 billion. > I'm saying I should be able to use whatever size LAN I want. You are totally free to do that if you please, no one is stopping you. Good luck finding hardware that will accomodate your wants. (As an old hag once said, you cannot get everything you wish for). --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From marka at isc.org Fri Dec 29 03:06:14 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 14:06:14 +1100 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: > On 29 Dec 2017, at 1:54 pm, Ricky Beam wrote: > > On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong wrote: >> If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. > > I'm saying I should be able to use whatever size LAN I want. Go ahead and do it. No one is stopping you. Just don’t force it on other including your customers. >> The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. > > Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. It already happens and it isn’t just geeks that have such home networks. People do daisy chain routers today and have been for years. HOMENET routers will auto configure if you just plug them together. >> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. > > After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lyndon at orthanc.ca Fri Dec 29 03:07:43 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 19:07:43 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: <684F860D-ACB3-46B1-8E39-5666D65F4649@orthanc.ca> > On Dec 28, 2017, at 6:54 PM, Ricky Beam wrote: > > Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. Again, you are assuming you know how people will use networks forever. Stop overthinking things, and just concentrate on just routing the packets. Your ONLY concern as a network operator is the number of routing table entries you need to carry. The size of my netmask (giggity) is irrelevant. Ship me a 48, 52, 64, 120, doesn't matter. It's a single RTE as far as you are concerned. (Again, unless you can't $afford renting the extra address space from ARIN. In which case you don't have a network infrastructure problem ...) From brock at bmwl.co Fri Dec 29 03:26:46 2017 From: brock at bmwl.co (Brock Tice) Date: Thu, 28 Dec 2017 20:26:46 -0700 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: Hi Lyndon, thanks for taking the time to address my questions. Responses below. On 2017-12-28 17:57, Lyndon Nerenberg wrote: >> On Dec 28, 2017, at 3:28 PM, Brock Tice wrote: >> We are currently handing out /52s to customers. Based on a reasonable >> sparse allocation scheme that would account for future growth that >> seemed like the best option. > Could you detail the reasoning behind your allocation scheme? I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated? What data fed the model you used to come up with those numbers? I am going to address a bunch of these together below. > I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers. I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with. > >> I can't really see how /52 is too small for a residential customer. I >> know originally it was supposed to be /48 but after doing a bit of >> reading I think many people have admitted there is room for nuance. > What reading? Can you provide pointers to the documents you were reading? Again, I'm curious to understand how and why ISPs are making these decisions. > > Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't. An ISP's job is to shovel packets around. No more, no less. I think with a little more nuance, an ISP's job is to manage resources properly in order to shovel packets around as well as possible. In this case, IP address space. >> Do you think I could go to ARIN and say, well, we haven't used hardly >> any of this but based on such-and-such allocation scheme, it would be >> much better if you gave us a /32 instead of a /36? > Hardly used any of what? Are you talking about density of the customer hosts inside each of these /64 subnets? This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from. No, see below. I'm talking about the fact that we've got a sparse allocation scheme and even within that most of the subnets we've allocated for towers don't have towers attached to them. They certainly could in the next decade, though. > Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment? No >> Also, does anyone know whether ARIN is using sparse allocation, such >> that if we go back later and ask for more they will just increase the >> size of our allocation starting from the same point? > You could just ask them. But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.† > > But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers? I'm just wondering if I'm likely to have to renumber just to go to a more generous allocation scheme. I guess better now than in 5 years if so. > You need to treat IPv6 addresses as being 64 bits long. Those extra 64 bits on the right are just noise – ignore them. Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network. That makes for a densely allocated /48 for each person on the planet. (Coincidence?) But when we get to the point of filling up that /3, we still have five more /3s to work with. OK addressing all of the rest of this here. I'm admittedly no expert on IPv6, I've been forced to learn it in a hurry. I did read most of "Migrating to IPv6" by Marc Blanchet and "IPv6 Address Planning" by Tom Coffeen. I believe I read quite a few things about deciding on subnet sizing there. >From those books I basically learned to think in /64s (generally one per router interface). I'm not very concerned with the number of hosts in a /64 for obvious reasons. Most of our customers only have 2-5 devices. I know this is not the case in most of America but we are quite rural and for many people they've never had better than 1.5Mbps DSL until we install service at their location. Most of them have no idea what a subnet is. Let us say that over the next ten years they get quite savvy and decide to isolate their wireless clients, some public servers, their IoT devices, and their security cameras. We have given them a /52 which contains 4096 /64s. So, most likely, they will use one of those for their LAN and be done. In case they decide to make several VLANs or whatever they have used 4 /64s and they have 4092 left. Well, maybe, you say, they want to do something more hierarchical. Ok, they have 16 /56s they can split into 16 /60s and they can split those into 16 /64s. So now for my customers that have expanded to like 10 devices they can give them their own /56 each. I will again say I am indeed no expert, I am happy to get feedback. Is there some kind of allocation scheme where a residential user or even a small or medium business will have any chance of using 4096 /64s? > Now think about scaling. If the population doubles, we're now down to four spare /3s. If that doubled population doubles the number of devices, we're down to two spare /3s. If the population doubles again, there will be no civilization left, let alone an Internet. Etc. So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes. Each node having its own /64 to address individual endpoints within whatever that 'node' represents. Just think, 2^64 port-443 HTTPS servers per "thing." Isn't this the utopia we've been seeking out? > > I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space. If the correct answer is just "ask for more space", which is the sense I'm getting, then I should probably just do that. I do really appreciate the feedback. --Brock From tony at wicks.co.nz Fri Dec 29 03:28:20 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 29 Dec 2017 16:28:20 +1300 Subject: Waste will kill ipv6 too In-Reply-To: <684F860D-ACB3-46B1-8E39-5666D65F4649@orthanc.ca> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <684F860D-ACB3-46B1-8E39-5666D65F4649@orthanc.ca> Message-ID: <001301d38055$1476ecb0$3d64c610$@wicks.co.nz> I think its time you all had a bit of a holiday break and stopped thinking of IP networking for a little while, Just saying....... From lyndon at orthanc.ca Fri Dec 29 03:32:24 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 19:32:24 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <001301d38055$1476ecb0$3d64c610$@wicks.co.nz> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <684F860D-ACB3-46B1-8E39-5666D65F4649@orthanc.ca> <001301d38055$1476ecb0$3d64c610$@wicks.co.nz> Message-ID: <82ADD776-1527-4E6E-B04B-AEDFEA145903@orthanc.ca> > On Dec 28, 2017, at 7:28 PM, Tony Wicks wrote: > > I think its time you all had a bit of a holiday break and stopped thinking > of IP networking for a little while, Just saying....... Nah. This is a useful conversation (and argument) to have. From chuckchurch at gmail.com Fri Dec 29 03:41:57 2017 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 28 Dec 2017 22:41:57 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: <000e01d38056$fb4014e0$f1c03ea0$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ricky Beam Sent: Thursday, December 28, 2017 9:55 PM To: Owen DeLong Cc: NANOG list Subject: Re: Waste will kill ipv6 too >Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. I couldn't agree more. We're spending so much time with new RFCs to handle all these prefix delegation ways in order to accommodate 'power users' who are used to chaining one NATing IPv4 router off of another one and having it sort of work. If we'd just put a stake in the ground and say residences can have one router and bridge everything below that we'd be further ahead. I just can't see 99.999% of users being interested in subnetting their homes and writing firewall rules so their light bulbs can't talking to their DVRs. Chuck From michael at wi-fiber.io Fri Dec 29 03:48:31 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 28 Dec 2017 20:48:31 -0700 Subject: Waste will kill ipv6 too In-Reply-To: <000e01d38056$fb4014e0$f1c03ea0$@gmail.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <000e01d38056$fb4014e0$f1c03ea0$@gmail.com> Message-ID: The lightbulb in this scenario has a severe security issue, and thus allows total control of any windows computer on the network because it's set to a private/trusted network. Also note, the lightbulb is publicly addressable and has a 8MHz processor incapable of firewalling itself.. On 28 December 2017 at 20:41, Chuck Church wrote: > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ricky Beam > Sent: Thursday, December 28, 2017 9:55 PM > To: Owen DeLong > Cc: NANOG list > Subject: Re: Waste will kill ipv6 too > > >Every scenario everyone has come up with is "unlikely". Home networks > with multiple LANs??? Never going to happen; people don't know how to set > them up, and there's little technical need for it. > > I couldn't agree more. We're spending so much time with new RFCs to > handle all these prefix delegation ways in order to accommodate 'power > users' who are used to chaining one NATing IPv4 router off of another one > and having it sort of work. If we'd just put a stake in the ground and say > residences can have one router and bridge everything below that we'd be > further ahead. I just can't see 99.999% of users being interested in > subnetting their homes and writing firewall rules so their light bulbs > can't talking to their DVRs. > > Chuck > > From lyndon at orthanc.ca Fri Dec 29 03:49:27 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 19:49:27 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: <15712C86-1173-46F1-872F-AA927DBB5EFC@orthanc.ca> > On Dec 28, 2017, at 7:26 PM, Brock Tice wrote: > > Most of our customers only have 2-5 devices. I know this is not the case > in most of America but we are quite rural and for many people they've > never had better than 1.5Mbps DSL until we install service at their > location. Most of them have no idea what a subnet is. Let us say that > over the next ten years they get quite savvy and decide to isolate their > wireless clients, some public servers, their IoT devices, and their > security cameras. We have given them a /52 which contains 4096 /64s. So, > most likely, they will use one of those for their LAN and be done. In > case they decide to make several VLANs or whatever they have used 4 /64s > and they have 4092 left. And that's where you're missing the IPv6 addressing concept. You are thinking of "devices." That's not how the v6 address space was planned out. Future address (subnet, really) consumption will be decided by the devices behind the CPE, not the number of devices behind the CPE. That's why there is such a huge address space allocation to each end point. What people do in the privacy of their own routing domain is their own business. As I mentioned in an earlier post to the list, think of IPv6 as a /64 address space; ignore the noise to the right. ARIN allots you a /48 for each of your customer end points. That means, as an ISP, you get a /32 right away. That covers 64K customer end points out of the gate. If you need a larger allocation, you can get that immediately. So there is no need to carve up end point /48s. And you don't want to. It just makes more work configuring your routers. Your monitoring software will assume /48 per CPE, so you'll have to explicitly configure that, etc. All you are doing is making work for yourself. And messing things up for your customers. --lyndon From valdis.kletnieks at vt.edu Fri Dec 29 03:50:48 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 28 Dec 2017 22:50:48 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: <13035.1514519448@turing-police.cc.vt.edu> On Thu, 28 Dec 2017 21:54:46 -0500, "Ricky Beam" said: > Every scenario everyone has come up with is "unlikely". Home networks with > multiple LANs??? Never going to happen; people don't know how to set them > up, and there's little technical need for it. And yet, my Lede-based router burned up 5 subnets easily. Oh, so you don't like that example because I'm not "people don't know how"? Comcast is passing out CPE that provides a subnet for the actual subscriber, and another one for *other* Comcast roaming customers. And somehow this works for a company the size of Comcast without the customers needing to know how to set them up. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Fri Dec 29 03:51:25 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 28 Dec 2017 22:51:25 -0500 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: <13135.1514519485@turing-police.cc.vt.edu> On Thu, 28 Dec 2017 20:26:46 -0700, Brock Tice said: > I will again say I am indeed no expert, I am happy to get feedback. Is > there some kind of allocation scheme where a residential user or even a > small or medium business will have any chance of using 4096 /64s? They won't burn 4096 consecutive addresses. They'll do what you said - your gear supplies their head-end router a /52. That then starts handing out a half-dozen or so /64s for hardware interfaces, and hands a DHCP-PD /56 to the expansion router at the other end of the house, which then hands out a half-dozen /64s for subnets at that end, and *it* then hands a /60 PD to the garage and barn routers, so they can each set up a half-dozen /64s. So yeah, they need a /52, even though we've only burned through 2 or 3 dozen /64s. But this is the way it's *supposed* to work - note that careful choice of subnet numbers for the PD and local subnets means that even if other stuff shows up and starts asking for a PD, there will be plenty left for them to use. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Fri Dec 29 03:59:15 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 28 Dec 2017 22:59:15 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <000e01d38056$fb4014e0$f1c03ea0$@gmail.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <000e01d38056$fb4014e0$f1c03ea0$@gmail.com> Message-ID: <13895.1514519955@turing-police.cc.vt.edu> On Thu, 28 Dec 2017 22:41:57 -0500, "Chuck Church" said: > If we'd just put a stake in the ground and say residences can have one > router and bridge everything below that we'd be further ahead. I just can't > see 99.999% of users being interested in subnetting their homes and writing > firewall rules so their light bulbs can't talking to their DVRs. So you'd rather write firewall rules so that people using your "guest" side of the *bridged* network stay out of the *other* side of the *bridged* network? (Hint: What does "bridged" mean for where packets go?) If you have the ability to set up multiple subnets, it's easy: Subnet 0 is wired local ports on the back of the router Subnet 1 is your local 2.4ghz wireless Subnet 2 is your local 5ghz Subnet 3 is your guest 2.4 Subnet 4 is your guest 5ghz. Subnets 0 1 and 2 can talk to each other, Subnets 3 and 4 can only talk to the outside world. Probably want a few more subnets for all the crapware that's shipping as part of the Internet of Pwned Things. Or you can try to do all this in one bridged subnet. Have fun with your nervous breakdown. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From lyndon at orthanc.ca Fri Dec 29 03:59:33 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 28 Dec 2017 19:59:33 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <13035.1514519448@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <13035.1514519448@turing-police.cc.vt.edu> Message-ID: <16BFCFD0-B4B1-4DE7-9CAC-20CCA4A3444E@orthanc.ca> > On Dec 28, 2017, at 7:50 PM, valdis.kletnieks at vt.edu wrote: > > Comcast is passing out CPE that provides a subnet for the actual subscriber, > and another one for *other* Comcast roaming customers. And somehow this > works for a company the size of Comcast without the customers needing to know > how to set them up. This sounds like the Shaw "Wifi to Go" routers they (Shaw) push out. Agree to make your Shaw internet connection "shared" and they drop in a hotspot that provides a 2nd wifi network that subscribers can connect to. In exchange for a discount on your local internet bill. (Separate subnet.) Of course, Shaw STILL doesn't do IPv6 ... ;-P From marka at isc.org Fri Dec 29 04:36:51 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 15:36:51 +1100 Subject: Waste will kill ipv6 too In-Reply-To: <13135.1514519485@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <13135.1514519485@turing-police.cc.vt.edu> Message-ID: <4B30C796-5861-46CF-BC39-83B35CB872D2@isc.org> > On 29 Dec 2017, at 2:51 pm, valdis.kletnieks at vt.edu wrote: > > On Thu, 28 Dec 2017 20:26:46 -0700, Brock Tice said: > >> I will again say I am indeed no expert, I am happy to get feedback. Is >> there some kind of allocation scheme where a residential user or even a >> small or medium business will have any chance of using 4096 /64s? > > They won't burn 4096 consecutive addresses. They'll do what you said - your > gear supplies their head-end router a /52. That then starts handing out a > half-dozen or so /64s for hardware interfaces, and hands a DHCP-PD /56 to the > expansion router at the other end of the house, which then hands out a > half-dozen /64s for subnets at that end, and *it* then hands a /60 PD to the > garage and barn routers, so they can each set up a half-dozen /64s. PD is designed so that a device (router) can request multiple PD requests upstream. The interior router just needs to make a upstream request on behalf of the downstream device and any prefixes it will be allocating itself. There is zero need to maintain a pool of prefixes to answer prefix requests. If you get back a bigger (e.g. /48 sized response) you just use those until they have all been handed out. > So yeah, they need a /52, even though we've only burned through 2 or 3 dozen > /64s. But this is the way it's *supposed* to work - note that careful choice of > subnet numbers for the PD and local subnets means that even if other stuff > shows up and starts asking for a PD, there will be plenty left for them to use. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ml-nanog at techcompute.net Fri Dec 29 04:49:49 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Thu, 28 Dec 2017 20:49:49 -0800 (PST) Subject: 1/2u 100g Metro-E Aggregation Switch Message-ID: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I am looking for something that has 4 100g ports for metro ethernet in a 1/2u form factor. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From ml-nanog at techcompute.net Fri Dec 29 04:52:06 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Thu, 28 Dec 2017 20:52:06 -0800 (PST) Subject: Cogent on-net corporate building Message-ID: <718791657.247755.1514523126917.JavaMail.zimbra@techcompute.net> Anyone a cogent customer in an on-net corporate building(Not a Cogent or Carrier Neutral Datacenter)? I have a few questions about setup. Off list responses are fine. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From lguillory at reservetele.com Fri Dec 29 05:13:18 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 29 Dec 2017 05:13:18 +0000 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> Message-ID: QFX5110-48S, 4x100 or 4x40 plus 48 SFP+ Sent from my iPad On Dec 28, 2017, at 10:50 PM, Lewis,Mitchell T. > wrote: Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I am looking for something that has 4 100g ports for metro ethernet in a 1/2u form factor. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] Luke Guillory Vice President – Technology and Innovation [cid:imaged86681.JPG at 423db806.4c87add4] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From valdis.kletnieks at vt.edu Fri Dec 29 05:21:56 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 29 Dec 2017 00:21:56 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <4B30C796-5861-46CF-BC39-83B35CB872D2@isc.org> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <13135.1514519485@turing-police.cc.vt.edu> <4B30C796-5861-46CF-BC39-83B35CB872D2@isc.org> Message-ID: <22723.1514524916@turing-police.cc.vt.edu> On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said: > PD is designed so that a device (router) can request multiple PD requests > upstream. The interior router just needs to make a upstream request on behalf > of the downstream device and any prefixes it will be allocating itself. OK, I obviously missed that part of the RFC, I was under the impression that a "middle" router would be carving out of its own PD, rather than relaying the downstream request upstream. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From marka at isc.org Fri Dec 29 05:34:00 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Dec 2017 16:34:00 +1100 Subject: Waste will kill ipv6 too In-Reply-To: <22723.1514524916@turing-police.cc.vt.edu> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <13135.1514519485@turing-police.cc.vt.edu> <4B30C796-5861-46CF-BC39-83B35CB872D2@isc.org> <22723.1514524916@turing-police.cc.vt.edu> Message-ID: > On 29 Dec 2017, at 4:21 pm, Valdis.Kletnieks at vt.edu wrote: > > On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said: >> PD is designed so that a device (router) can request multiple PD requests >> upstream. The interior router just needs to make a upstream request on behalf >> of the downstream device and any prefixes it will be allocating itself. > > OK, I obviously missed that part of the RFC, I was under the impression that a > "middle" router would be carving out of its own PD, rather than relaying the > downstream request upstream. Mostly this is because RFC describe what goes over the wire, not what happens internally to a node. There isn’t a RFC that says populate the DHCP DNS servers advertised downstream with those learnt by DHCP from upstream but CPE routers do this all the time. You could also just turn on DHCPv6 relay when you detect you are a interior router or have a check box next to the enable DHCP checkbox which says use relay mode. Device vendors need more and more spoon feeding these days. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sthaug at nethelp.no Fri Dec 29 10:27:41 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 29 Dec 2017 11:27:41 +0100 (CET) Subject: Waste will kill ipv6 too In-Reply-To: <563.1514512578@turing-police.cc.vt.edu> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> Message-ID: <20171229.112741.74689832.sthaug@nethelp.no> > > My wild guess is if we'd just waited a little bit longer to formalize > > IPng we'd've more seriously considered variable length addressing with > > a byte indicating how many octets in the address even if only 2 > > lengths were immediately implemented (4 and 16.) > > Actually, that got heaved over the side fairly early in the IPng discussion, > because nobody who was building silicon last century wanted to > deal with arbitrary-length addresses. The IPv4 header had source and > destination addresses on 4-byte boundaries for good reasons which > still held true when we did the IPv6 headers. It's rather interesting how parsing of variable length addresses was thought to be way too complicated - while parsing of IPv6 extension header chains of unknown length was okay. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mjo at dojo.mi.org Fri Dec 29 08:19:39 2017 From: mjo at dojo.mi.org (Mike O'Connor) Date: Fri, 29 Dec 2017 03:19:39 -0500 Subject: Foundry FastIron In-Reply-To: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> References: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> Message-ID: <20171229081939.rl7iifghz62pgmtk@dojo.mi.org> :A client of mine has some Foundry FastIron Edge X424HFs. : :Brocade and Extreme don't seem overly ambitious to help. Brocade EOL'ed those old FESX-4 switches themselves on 03/31/2011, with EOS in 2016. This was before Brocadecom spun off to Extreme. :Anyone have any documentation they can scrounge up? SFP compatibility list? The ones I see in there already look substantially like the ones I get from FiberStore, but that doesn't mean much. Can't help you there, sorry... :Do they still sell support on these? I'm largely just interested in newer firmware for them. I don't think they were updated since they left the factory and there are a few quirks I'm hoping they addressed at some point. Depending on your bother, check out the FESX424-L3U "Layer 3 Upgrade Kit". That particular software piece looks like it gets support for another few months, if I am to believe Brocade's website (which only has the FESX-6 EOL notice, not the older FESX-4 one). http://www.brocade.com/en/backend-content/pdf-page.html?/content/dam/common/documents/content-types/end-of-life-notice/brocade-fastiron-edge-x-6-end-of-life-notice.pdf -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Take me out... to the black. Tell 'em I ain't comin' back." -Firefly -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jjones at danrj.com Fri Dec 29 13:47:49 2017 From: jjones at danrj.com (Jerry Jones) Date: Fri, 29 Dec 2017 07:47:49 -0600 Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> Message-ID: Wait for the ACX5448 coming soon. On Dec 28, 2017, at 11:13 PM, Luke Guillory wrote: QFX5110-48S, 4x100 or 4x40 plus 48 SFP+ Sent from my iPad On Dec 28, 2017, at 10:50 PM, Lewis,Mitchell T. > wrote: Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I am looking for something that has 4 100g ports for metro ethernet in a 1/2u form factor. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] Luke Guillory Vice President – Technology and Innovation [cid:imaged86681.JPG at 423db806.4c87add4] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From swmike at swm.pp.se Fri Dec 29 14:54:52 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 29 Dec 2017 15:54:52 +0100 (CET) Subject: Waste will kill ipv6 too In-Reply-To: <20171229.112741.74689832.sthaug@nethelp.no> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> <20171229.112741.74689832.sthaug@nethelp.no> Message-ID: On Fri, 29 Dec 2017, sthaug at nethelp.no wrote: > It's rather interesting how parsing of variable length addresses was > thought to be way too complicated - while parsing of IPv6 extension > header chains of unknown length was okay. I think this can be explained by "routers don't need to parse extension headers, they're routers, they only act on L3". Some of the people around back in early/mid 1990ies involved in designing IPv6 is still around in IETF, you can always ask them. -- Mikael Abrahamsson email: swmike at swm.pp.se From bryan at shout.net Fri Dec 29 15:17:26 2017 From: bryan at shout.net (Bryan Holloway) Date: Fri, 29 Dec 2017 09:17:26 -0600 Subject: Wi-Fi Analyzer Message-ID: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Curious if the community has any recommendations and/or positive experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. Software/laptop-based solutions can be unwieldy in certain environments. However, given rave reviews, I'm open to the idea as long as it's Mac-compatible. Should be able to show detailed spectra, help locate sources of interference, have mapping capabilities, etc. Thanks! From olivier.benghozi at wifirst.fr Fri Dec 29 15:19:42 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Fri, 29 Dec 2017 16:19:42 +0100 Subject: Foundry FastIron In-Reply-To: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> References: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> Message-ID: By the way, Foundry/Brocade small/campus switches were sold by Broadcom to Ruckus, not to Extreme (who bought the bigger switch/routers). https://support.ruckuswireless.com/product_families/21-ruckus-icx-campus-switches https://support.ruckuswireless.com/product_families/23-_eol-fastiron-products Of course, as it is an end of life product in their shopping bag, I wouldn't expect much :) > On 29 dec. 2017 at 09:19, Mike O'Connor wrote : > >> A client of mine has some Foundry FastIron Edge X424HFs. >> >> Brocade and Extreme don't seem overly ambitious to help. >> > Brocade EOL'ed those old FESX-4 switches themselves on 03/31/2011, > with EOS in 2016. This was before Brocadecom spun off to Extreme. From ml-nanog at techcompute.net Fri Dec 29 15:20:41 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Fri, 29 Dec 2017 07:20:41 -0800 (PST) Subject: 1/2u 100g Metro-E Aggregation Switch In-Reply-To: References: <1484757956.247738.1514522989493.JavaMail.zimbra@techcompute.net> Message-ID: <1678802774.272368.1514560841025.JavaMail.zimbra@techcompute.net> Any further details on this? I haven't seen any press releases from Juniper. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Jerry Jones" To: "Luke Guillory" Cc: "Lewis,Mitchell T." , "NANOG" Sent: Friday, December 29, 2017 8:47:49 AM Subject: Re: 1/2u 100g Metro-E Aggregation Switch Wait for the ACX5448 coming soon. On Dec 28, 2017, at 11:13 PM, Luke Guillory wrote: QFX5110-48S, 4x100 or 4x40 plus 48 SFP+ Sent from my iPad On Dec 28, 2017, at 10:50 PM, Lewis,Mitchell T. > wrote: Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I am looking for something that has 4 100g ports for metro ethernet in a 1/2u form factor. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] Luke Guillory Vice President – Technology and Innovation [cid:imaged86681.JPG at 423db806.4c87add4] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From nick at foobar.org Fri Dec 29 15:23:07 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Dec 2017 15:23:07 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <20171229.112741.74689832.sthaug@nethelp.no> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> <20171229.112741.74689832.sthaug@nethelp.no> Message-ID: <5A465DDB.5010508@foobar.org> >>> My wild guess is if we'd just waited a little bit longer to formalize >>> IPng we'd've more seriously considered variable length addressing with >>> a byte indicating how many octets in the address even if only 2 >>> lengths were immediately implemented (4 and 16.) >> Actually, that got heaved over the side fairly early in the IPng discussion, >> because nobody who was building silicon last century wanted to >> deal with arbitrary-length addresses. The IPv4 header had source and >> destination addresses on 4-byte boundaries for good reasons which >> still held true when we did the IPv6 headers. > > It's rather interesting how parsing of variable length addresses was > thought to be way too complicated - while parsing of IPv6 extension > header chains of unknown length was okay. variable length addressing was thrown out at the time because the OSI model showed that it created a good deal of trouble for no overriding benefit. Processing variable length addresses was found to be as difficult as processing the longest length allowed. In practice, NSAP addresses were limited to 20 octets, but in theory they could be up to 255. IPv6 extension headers, on the other hand, weren't considered a major imposition at the time because almost all routers in the mid 1990s were cpu switched rather than handled on asics. Walking through TLVs is relatively straightforward to handle from an algorithmic point of view, but it creates pain when dealing with forwarding lookup engines because extension headers means inspecting more header data when calculating the next-hop when you're dealing with ECMP / LAGs. This is harder when dealing with hardware/offloaded lookup engines because more header information needs to be copied from the interface to the lookup engine, which has a cost. It's not insurmountable, just more expensive from a hardware point of view, which means that lots of cheaper kit doesn't do this well, or in some cases, at all. Nick From reichert at numachi.com Fri Dec 29 15:29:42 2017 From: reichert at numachi.com (Brian Reichert) Date: Fri, 29 Dec 2017 10:29:42 -0500 Subject: Wi-Fi Analyzer In-Reply-To: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: <20171229152942.GF459@numachi.com> On Fri, Dec 29, 2017 at 09:17:26AM -0600, Bryan Holloway wrote: > Curious if the community has any recommendations and/or positive > experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. > > Software/laptop-based solutions can be unwieldy in certain environments. > However, given rave reviews, I'm open to the idea as long as it's > Mac-compatible. > > Should be able to show detailed spectra, help locate sources of > interference, have mapping capabilities, etc. Depending on what problem you're trying to solve, on my Android phone I use a free app called 'Wifi Analyzer': http://wifianalyzer.mobi Shows me what station IDs are on what channels, handles 2.4g and 5G connections, etc. Doesn't provide mapping, just shows "from where I am right know, what channels have which stations as what strengths?" For a house, it's easy to walk around, to passively get a feel for Wifi placement/config. > Thanks! -- Brian Reichert BSD admin/developer at large From owen at delong.com Fri Dec 29 15:42:07 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Dec 2017 07:42:07 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> Message-ID: <0094C684-01FB-45DD-9638-4ABAAB4D6439@delong.com> > On Dec 28, 2017, at 18:54, Ricky Beam wrote: > >> On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong wrote: >> If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. > > I'm saying I should be able to use whatever size LAN I want. Sounds like you already are and nobody is telling you that you can’t. It’s a rather silly way to over-complicate your life, but if you want to be on the wrong side of a direcTV commercial, nobody’s trying to stop you. > >> The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. > > Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. Lots of home networks have multiple LANs today, so you’re patently wrong there already. > >> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. > > After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) Given that more than 50% of US mobile traffic is now IPv6, I find it hard to give credence to a claim of “not using”. It’s also north of 40% for US fixed wire line traffic. As I said, I don’t doubt that we may eventually run out. However, I doubt anyone alive today will still be alive when we do. Owen From alan.buxey at gmail.com Fri Dec 29 15:45:07 2017 From: alan.buxey at gmail.com (Alan Buxey) Date: Fri, 29 Dec 2017 15:45:07 +0000 Subject: Wi-Fi Analyzer In-Reply-To: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: Scout Aircheck G2 is quite nifty - but a lot of tools out there are only just a little bit above what you can do with a decent Android phone (one with 802.11a/b/g/n/ac chipset) and WiFiAnalyzer ! :) alan From owen at delong.com Fri Dec 29 15:56:26 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Dec 2017 07:56:26 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <20171229.112741.74689832.sthaug@nethelp.no> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> <20171229.112741.74689832.sthaug@nethelp.no> Message-ID: <8E8097FF-7930-43BD-B1EE-9BA67877E8AD@delong.com> On Dec 29, 2017, at 02:27, sthaug at nethelp.no wrote: >>> My wild guess is if we'd just waited a little bit longer to formalize >>> IPng we'd've more seriously considered variable length addressing with >>> a byte indicating how many octets in the address even if only 2 >>> lengths were immediately implemented (4 and 16.) >> >> Actually, that got heaved over the side fairly early in the IPng discussion, >> because nobody who was building silicon last century wanted to >> deal with arbitrary-length addresses. The IPv4 header had source and >> destination addresses on 4-byte boundaries for good reasons which >> still held true when we did the IPv6 headers. > > It's rather interesting how parsing of variable length addresses was > thought to be way too complicated - while parsing of IPv6 extension > header chains of unknown length was okay. Well... first, fast routers mostly don’t parse those chains. Second, to the extent they do, it’s the biggest legitimate complaint I’ve seen with the design of IPv6. Owen > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nick at foobar.org Fri Dec 29 16:15:28 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Dec 2017 16:15:28 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <8E8097FF-7930-43BD-B1EE-9BA67877E8AD@delong.com> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> <20171229.112741.74689832.sthaug@nethelp.no> <8E8097FF-7930-43BD-B1EE-9BA67877E8AD@delong.com> Message-ID: <5A466A20.6040103@foobar.org> Owen DeLong wrote: > fast routers mostly don’t parse those chains. ...unless they need to access the L4 header information in order to create useful hashes to load balance over LAG or ECMP bundles, or implement any sort of filtering, or RE / control plane policing. But outside these corner cases, definitely a minority requirement :-) Nick From labguy at gmail.com Fri Dec 29 16:43:15 2017 From: labguy at gmail.com (Troy Martin) Date: Fri, 29 Dec 2017 09:43:15 -0700 Subject: Wi-Fi Analyzer In-Reply-To: References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: <8D36ADAD-4361-4199-97BA-F1526905CB01@gmail.com> For OSX specific requirement, I suggest looking at “Wi-Fi Explorer Pro”. It scans for SSIDs, integrates with Metageek Wi-Spy for SpecA, connects to remote sensors. Eval for 10 days before needing pay. The developer (Adrian Granados) also makes a tool called “Wi-Fi signal” (menu bar display/status). There is another tool as well “Airtool” which makes packet captures ridiculously easy on OSX. For mapping Ekahau or Netapot which are OSX based. Alternatively - iBwave, Ekahau, Airmagnet and Tamosoft on windows. Kindest regards, -- Troy Martin > On Dec 29, 2017, at 8:45 AM, Alan Buxey wrote: > > Scout Aircheck G2 is quite nifty - but a lot of tools out there are > only just a little bit above what you can do with a decent Android > phone (one with 802.11a/b/g/n/ac chipset) and > WiFiAnalyzer ! :) > > alan From bill at herrin.us Fri Dec 29 17:43:02 2017 From: bill at herrin.us (William Herrin) Date: Fri, 29 Dec 2017 12:43:02 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <20171229.112741.74689832.sthaug@nethelp.no> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <563.1514512578@turing-police.cc.vt.edu> <20171229.112741.74689832.sthaug@nethelp.no> Message-ID: On Fri, Dec 29, 2017 at 5:27 AM, wrote: > It's rather interesting how parsing of variable length addresses was > thought to be way too complicated - while parsing of IPv6 extension > header chains of unknown length was okay. > IIRC, IPv6 extension headers are optional. The router does have to check if there are any hop-by-hop options but it doesn't need to examine more than the first extension header (and always the same byte offset) to determine if it has to look. More, it's allowed to reject the packet with a parameter problem rather than process the header. The originating and destination nodes have to pay attention to all extension headers, but then they always did have to process packets with information of variable lengths. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From cscora at apnic.net Fri Dec 29 18:03:01 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Dec 2017 04:03:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171229180301.7E854C509@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Dec, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 677557 Prefixes after maximum aggregation (per Origin AS): 263618 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 328121 Total ASes present in the Internet Routing Table: 59472 Prefixes per ASN: 11.39 Origin-only ASes present in the Internet Routing Table: 51332 Origin ASes announcing only one prefix: 22605 Transit ASes present in the Internet Routing Table: 8140 Transit-only ASes present in the Internet Routing Table: 256 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 88 Number of instances of unregistered ASNs: 89 Number of 32-bit ASNs allocated by the RIRs: 21049 Number of 32-bit ASNs visible in the Routing Table: 16874 Prefixes from 32-bit ASNs in the Routing Table: 69320 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 325 Number of addresses announced to Internet: 2859634018 Equivalent to 170 /8s, 114 /16s and 141 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 224347 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 186321 Total APNIC prefixes after maximum aggregation: 53408 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 185448 Unique aggregates announced from the APNIC address blocks: 77495 APNIC Region origin ASes present in the Internet Routing Table: 8557 APNIC Prefixes per ASN: 21.67 APNIC Region origin ASes announcing only one prefix: 2420 APNIC Region transit ASes present in the Internet Routing Table: 1250 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3442 Number of APNIC addresses announced to Internet: 770161954 Equivalent to 45 /8s, 231 /16s and 189 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202626 Total ARIN prefixes after maximum aggregation: 97583 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203867 Unique aggregates announced from the ARIN address blocks: 95602 ARIN Region origin ASes present in the Internet Routing Table: 18039 ARIN Prefixes per ASN: 11.30 ARIN Region origin ASes announcing only one prefix: 6678 ARIN Region transit ASes present in the Internet Routing Table: 1783 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2285 Number of ARIN addresses announced to Internet: 1107279136 Equivalent to 65 /8s, 255 /16s and 189 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 183142 Total RIPE prefixes after maximum aggregation: 89231 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 179113 Unique aggregates announced from the RIPE address blocks: 107861 RIPE Region origin ASes present in the Internet Routing Table: 24778 RIPE Prefixes per ASN: 7.23 RIPE Region origin ASes announcing only one prefix: 11313 RIPE Region transit ASes present in the Internet Routing Table: 3509 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6533 Number of RIPE addresses announced to Internet: 713927808 Equivalent to 42 /8s, 141 /16s and 172 /24s 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, 64396-64495 196608-207259 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: 87687 Total LACNIC prefixes after maximum aggregation: 19412 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 88978 Unique aggregates announced from the LACNIC address blocks: 39696 LACNIC Region origin ASes present in the Internet Routing Table: 6705 LACNIC Prefixes per ASN: 13.27 LACNIC Region origin ASes announcing only one prefix: 1829 LACNIC Region transit ASes present in the Internet Routing Table: 1248 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4232 Number of LACNIC addresses announced to Internet: 172587936 Equivalent to 10 /8s, 73 /16s and 123 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17691 Total AfriNIC prefixes after maximum aggregation: 3917 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 19826 Unique aggregates announced from the AfriNIC address blocks: 7199 AfriNIC Region origin ASes present in the Internet Routing Table: 1105 AfriNIC Prefixes per ASN: 17.94 AfriNIC Region origin ASes announcing only one prefix: 364 AfriNIC Region transit ASes present in the Internet Routing Table: 224 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 382 Number of AfriNIC addresses announced to Internet: 95270656 Equivalent to 5 /8s, 173 /16s and 183 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5423 4194 86 ERX-CERNET-BKB China Education and Rese 7545 3271 403 390 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2882 11133 767 KIXS-AS-KR Korea Telecom, KR 17974 2782 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2765 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2561 1538 149 VNPT-AS-VN VNPT Corp, VN 7552 2530 1159 46 VIETEL-AS-AP Viettel Group, VN 9394 2168 4923 26 CTTNET China TieTong Telecommunications 9808 2090 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2084 417 209 TATACOMM-AS TATA Communications formerl 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 6327 3341 1323 86 SHAW - Shaw Communications Inc., CA 22773 3307 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2169 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2066 2324 465 CHARTER-NET-HKY-NC - Charter Communicat 16509 1987 4081 583 AMAZON-02 - Amazon.com, Inc., US 6389 1960 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1944 5063 649 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1867 332 244 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1725 235 572 CABLEONE - CABLE ONE, INC., US 7018 1671 20197 1243 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2856 848 2059 AKAMAI-ASN1, US 8551 2284 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2092 1830 688 ROSTELECOM-AS, RU 34984 2004 330 468 TELLCOM-AS, TR 12479 1982 1068 127 UNI2-AS, ES 9121 1951 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 8402 1233 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1228 355 21 UKRTELNET, UA 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 8151 3749 3433 599 Uninet S.A. de C.V., MX 10620 3578 539 262 Telmex Colombia S.A., CO 11830 2631 370 66 Instituto Costarricense de Electricidad 6503 1617 437 53 Axtel, S.A.B. de C.V., MX 7303 1497 1022 194 Telecom Argentina S.A., AR 6147 1192 377 27 Telefonica del Peru S.A.A., PE 28573 1022 2259 189 CLARO S.A., BR 3816 1010 507 113 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 919 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1192 398 48 LINKdotNET-AS, EG 37611 780 91 8 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 657 1383 31 ETISALAT-MISR, EG 8452 520 1730 18 TE-AS TE-AS, EG 24835 449 786 17 RAYA-AS, EG 29571 443 36 13 CITelecom-AS, CI 37492 435 367 77 ORANGE-, TN 37342 356 32 1 MOVITEL, MZ 15399 342 35 7 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5423 4194 86 ERX-CERNET-BKB China Education and Rese 8151 3749 3433 599 Uninet S.A. de C.V., MX 10620 3578 539 262 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3341 1323 86 SHAW - Shaw Communications Inc., CA 22773 3307 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3271 403 390 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2882 11133 767 KIXS-AS-KR Korea Telecom, KR 20940 2856 848 2059 AKAMAI-ASN1, US 17974 2782 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3578 3316 Telmex Colombia S.A., CO 6327 3341 3255 SHAW - Shaw Communications Inc., CA 22773 3307 3161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3749 3150 Uninet S.A. de C.V., MX 7545 3271 2881 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2782 2705 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2631 2565 Instituto Costarricense de Electricidad y Telec 7552 2530 2484 VIETEL-AS-AP Viettel Group, VN 45899 2561 2412 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 204819 UNALLOCATED 82.195.160.0/22 1239 SPRINTLINK - Sprint, US 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64609 PRIVATE 94.245.126.0/24 6584 MICROSOFT-GP-AS - Microsoft Co 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:12 /10:37 /11:99 /12:279 /13:557 /14:1087 /15:1894 /16:13409 /17:7771 /18:13659 /19:25260 /20:38896 /21:44589 /22:82574 /23:66696 /24:378478 /25:840 /26:607 /27:661 /28:36 /29:20 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3133 3341 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2552 3307 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2063 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 1977 2631 Instituto Costarricense de Electricidad y Telec 8551 1748 2284 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1634 1867 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1577 3578 Telmex Colombia S.A., CO 11492 1521 1725 CABLEONE - CABLE ONE, INC., US 9121 1427 1951 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1572 2:820 4:18 5:2638 6:39 8:1094 9:1 12:1854 13:196 14:1758 15:28 16:3 17:185 18:76 20:53 21:12 23:2494 24:1924 25:2 27:2335 31:1966 32:87 35:22 36:460 37:2465 38:1461 39:223 40:101 41:2989 42:537 43:1917 44:91 45:3521 46:2978 47:192 49:1371 50:1052 51:47 52:921 54:355 55:6 56:7 57:42 58:1572 59:1002 60:372 61:1992 62:1767 63:1818 64:4648 65:2244 66:4486 67:2308 68:1192 69:3160 70:1132 71:587 72:2114 74:2697 75:392 76:423 77:1554 78:1616 79:1961 80:1475 81:1405 82:1070 83:778 84:1005 85:1977 86:569 87:1222 88:913 89:2311 90:175 91:6277 92:1124 93:2346 94:2432 95:2725 96:667 97:356 98:960 99:107 100:152 101:1531 102:10 103:16591 104:3208 105:211 106:520 107:1800 108:823 109:2717 110:1546 111:1718 112:1288 113:1391 114:1119 115:1598 116:1637 117:1664 118:2218 119:1656 120:912 121:1057 122:2414 123:1879 124:1482 125:1840 128:963 129:580 130:440 131:1630 132:596 133:194 134:997 135:221 136:449 137:457 138:1983 139:554 140:387 141:678 142:770 143:950 144:792 145:195 146:1147 147:687 148:1481 149:716 150:717 151:990 152:750 153:307 154:971 155:743 156:744 157:745 158:598 159:1649 160:849 161:735 162:2542 163:520 164:976 165:1487 166:398 167:1351 168:3112 169:787 170:3629 171:404 172:1020 173:1915 174:858 175:775 176:1859 177:3939 178:2485 179:1159 180:2232 181:2138 182:2402 183:1044 184:892 185:11951 186:3441 187:2340 188:2624 189:1940 190:8217 191:1341 192:9738 193:5861 194:4775 195:3987 196:2297 197:1426 198:5527 199:5885 200:7277 201:4903 202:10403 203:9947 204:4562 205:2872 206:3042 207:3107 208:3991 209:3939 210:4005 211:2128 212:2919 213:2624 214:859 215:66 216:5740 217:2111 218:910 219:626 220:1728 221:983 222:742 223:1229 End of report From rgolodner at infratection.com Fri Dec 29 19:01:47 2017 From: rgolodner at infratection.com (Richard) Date: Fri, 29 Dec 2017 13:01:47 -0600 Subject: Wi-Fi Analyzer In-Reply-To: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: <7d1f53f2-c04e-9ee1-e1ee-eacac6d02b27@infratection.com> Sorry for the top post, but I too end up going back to Wi Fi analyzer on my Android. I have found it covers all the basics which i need and am able to locate any difficulty I may be having. It works and you can carry it in your pocket instead of dragging a laptop around. Richard On 12/29/2017 09:17 AM, Bryan Holloway wrote: > Curious if the community has any recommendations and/or positive > experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. > > Software/laptop-based solutions can be unwieldy in certain > environments. However, given rave reviews, I'm open to the idea as > long as it's Mac-compatible. > > Should be able to show detailed spectra, help locate sources of > interference, have mapping capabilities, etc. > > Thanks! > > From afmug at zirkel.us Fri Dec 29 19:05:40 2017 From: afmug at zirkel.us (Sean Heskett) Date: Fri, 29 Dec 2017 19:05:40 +0000 Subject: Wi-Fi Analyzer In-Reply-To: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: iStumbler on the Mac -Sean On Fri, Dec 29, 2017 at 8:17 AM Bryan Holloway wrote: > Curious if the community has any recommendations and/or positive > experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. > > Software/laptop-based solutions can be unwieldy in certain environments. > However, given rave reviews, I'm open to the idea as long as it's > Mac-compatible. > > Should be able to show detailed spectra, help locate sources of > interference, have mapping capabilities, etc. > > Thanks! > From eric.kuhnke at gmail.com Fri Dec 29 19:16:39 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 29 Dec 2017 11:16:39 -0800 Subject: Wi-Fi Analyzer In-Reply-To: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: In addition to the other tools already recommended by previous posters, I recommend buying one of these: https://www.ubnt.com/airmax/nanobeam-ac-gen2/ It's a directional antenna/radio integrated unit and is intended as a point to point or point-to-multipoint WISP client radio. The one feature you can get from it very cheaply is a directional, 2x2 MIMO 5.x GHz band spectrum analyzer that sees things *which are not 802.11 or wifi based.* The airview spectrum analyzer tool built into it looks like this: https://www.google.com/search?q=ubiquiti+airview&num=100&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj0gtLI9q_YAhUC62MKHbZoAogQ_AUICygC&biw=1744&bih=994&dpr=1.1 Highly useful for tracking down a specific source of non-wifi 5 GHz band interference. There's all sorts of random consumer grade things people can buy and introduce into an environment which do not broadcast MAC addresses or SSIDs, and do not show up on purely 802.11(abgn/ac) based tools. It will of course also see hidden SSIDs and standard+non-standard 802.11abgn(ac) emitters. There are also 2.4 GHz versions of similar products which will let you find non-802.11 emitters in the 2300 to 2500 MHz band. At $79 a lot less expensive than a "real" spectrum analyzer. You can get DC PoE injectors for them which will connect to a Makita drill battery if you want to make it portable and wander around with a laptop. On Fri, Dec 29, 2017 at 7:17 AM, Bryan Holloway wrote: > Curious if the community has any recommendations and/or positive > experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. > > Software/laptop-based solutions can be unwieldy in certain environments. > However, given rave reviews, I'm open to the idea as long as it's > Mac-compatible. > > Should be able to show detailed spectra, help locate sources of > interference, have mapping capabilities, etc. > > Thanks! > From jlightfoot at gmail.com Sat Dec 30 00:51:51 2017 From: jlightfoot at gmail.com (John Lightfoot) Date: Fri, 29 Dec 2017 19:51:51 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <0094C684-01FB-45DD-9638-4ABAAB4D6439@delong.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <0094C684-01FB-45DD-9638-4ABAAB4D6439@delong.com> Message-ID: <3CF60518-FDA4-4169-9FD7-036998452BC4@gmail.com> Excuse the top post, but this seems to be an argument between people who understand big numbers and those who don't. IPv4 has 2^32 addresses, IPv6 has 2^128, which means 79 octillion people can each have their own internet. I think Owen is being modest when he says no one alive will be around for the exhaustion of IPv6, I think we're debating whether it will run out in a thousand years or a million. On 12/29/17, 10:44 AM, "NANOG on behalf of Owen DeLong" wrote: > On Dec 28, 2017, at 18:54, Ricky Beam wrote: > >> On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong wrote: >> If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. > > I'm saying I should be able to use whatever size LAN I want. Sounds like you already are and nobody is telling you that you can’t. It’s a rather silly way to over-complicate your life, but if you want to be on the wrong side of a direcTV commercial, nobody’s trying to stop you. > >> The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. > > Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. Lots of home networks have multiple LANs today, so you’re patently wrong there already. > >> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. > > After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) Given that more than 50% of US mobile traffic is now IPv6, I find it hard to give credence to a claim of “not using”. It’s also north of 40% for US fixed wire line traffic. As I said, I don’t doubt that we may eventually run out. However, I doubt anyone alive today will still be alive when we do. Owen From ml-nanog at techcompute.net Sat Dec 30 00:58:02 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Fri, 29 Dec 2017 16:58:02 -0800 (PST) Subject: 48vDC Output UPS Message-ID: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Greetings again, I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From surfer at mauigateway.com Sat Dec 30 01:11:34 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Dec 2017 17:11:34 -0800 Subject: Waste will kill ipv6 too Message-ID: <20171229171134.2D1FD881@m0117565.ppops.net> --- jlightfoot at gmail.com wrote: From: John Lightfoot Excuse the top post, but this seems to be an argument between people who understand big numbers and those who don't. ------------------------------------ No, not exactly. It's also about those that think in current/past network terms and those who are saying we don't know what the future holds, so we should be careful. ----------------------------- which means 79 octillion people...no one alive will be around ----------------------------- Stop thinking in terms of people. Think in terms of huge numbers of 'things' in the ocean, in the atmosphere, in space, zillions of 'things' on and around everyone's bodies and homes and myriad other 'things' we can't even imagine right now. scott From lista-gter at tbonet.net.br Sat Dec 30 01:11:53 2017 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Fri, 29 Dec 2017 23:11:53 -0200 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: <8f66a51f-f01a-dae2-e62e-8d2cb5c0d41d@tbonet.net.br> Mitchell, You can use Emerson Netsure (https://www.vertivco.com/en-us/products/brands/netsure/) You need to set next to the rack a battery bank ( 4x12v = 48v batteries in series ) Best Regards, João Butzke. Em 29/12/2017 22:58, Lewis,Mitchell T. escreveu: > Greetings again, > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? > > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > From mel at beckman.org Sat Dec 30 01:25:45 2017 From: mel at beckman.org (Mel Beckman) Date: Sat, 30 Dec 2017 01:25:45 +0000 Subject: Waste will kill ipv6 too In-Reply-To: <3CF60518-FDA4-4169-9FD7-036998452BC4@gmail.com> References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <67D179ED-F6EB-41A2-8CCA-D3B7EAFDDB96@delong.com> <0094C684-01FB-45DD-9638-4ABAAB4D6439@delong.com>, <3CF60518-FDA4-4169-9FD7-036998452BC4@gmail.com> Message-ID: <09A480A0-C432-44AB-B688-4EB6EA47E5EF@beckman.org> I'm saying I should be able to use whatever size LAN I want. Go ahead. Just don't use anybody else's addresses to do it. :) -mel On Dec 29, 2017, at 4:52 PM, John Lightfoot > wrote: Excuse the top post, but this seems to be an argument between people who understand big numbers and those who don't. IPv4 has 2^32 addresses, IPv6 has 2^128, which means 79 octillion people can each have their own internet. I think Owen is being modest when he says no one alive will be around for the exhaustion of IPv6, I think we're debating whether it will run out in a thousand years or a million. On 12/29/17, 10:44 AM, "NANOG on behalf of Owen DeLong" on behalf of owen at delong.com> wrote: On Dec 28, 2017, at 18:54, Ricky Beam > wrote: On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong > wrote: If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. I'm saying I should be able to use whatever size LAN I want. Sounds like you already are and nobody is telling you that you can’t. It’s a rather silly way to over-complicate your life, but if you want to be on the wrong side of a direcTV commercial, nobody’s trying to stop you. The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. Lots of home networks have multiple LANs today, so you’re patently wrong there already. Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) Given that more than 50% of US mobile traffic is now IPv6, I find it hard to give credence to a claim of “not using”. It’s also north of 40% for US fixed wire line traffic. As I said, I don’t doubt that we may eventually run out. However, I doubt anyone alive today will still be alive when we do. Owen From Brian at ampr.org Sat Dec 30 01:43:00 2017 From: Brian at ampr.org (Brian Kantor) Date: Fri, 29 Dec 2017 17:43:00 -0800 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: <20171230014300.GA37931@meow.BKantor.net> On Fri, Dec 29, 2017 at 04:58:02PM -0800, Lewis,Mitchell T. wrote: > Greetings again, > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? > Regards, > Mitchell T. Lewis > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] A word of caution (I was bitten by this): in many data centers, the USA National Electrical Code requires that UPS units be connected to the Emergency Power Off system so that in case of emergency the UPS will shut off too. Many of the less expensive UPS units do not have EPO shutdown capability, and it usually takes an electrician to wire it up when they do. There are also NEC regulations regarding batteries. - Brian From baldur.norddahl at gmail.com Sat Dec 30 02:12:22 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 30 Dec 2017 03:12:22 +0100 Subject: Waste will kill ipv6 too In-Reply-To: <20171229171134.2D1FD881@m0117565.ppops.net> References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: Nobody needs to worry. I promise to reserve the last /32 out of my /29 assignment. When the world has run out of addresses, I will start to sell from my pool using the same allocation policy that was used for IPv4. I would consider a /64 to be equal a /32 IPv4 address. This would make a /56 assignment equal to a /24 IPv4 minimum assignment. Historically we spent about 3 decades before running out of IPv4 space. So my scheme should be good enough for some additional decades of IPv6. I just hope nobody else does the same. That would be bad for my business case. Regards Baldur Den 30. dec. 2017 02.11 skrev "Scott Weeks" : > > --- jlightfoot at gmail.com wrote: > From: John Lightfoot > > Excuse the top post, but this seems to be an > argument between people who understand big > numbers and those who don't. > ------------------------------------ > > No, not exactly. It's also about those that > think in current/past network terms and those > who are saying we don't know what the future > holds, so we should be careful. > > > > ----------------------------- > which means 79 octillion people...no one > alive will be around > ----------------------------- > > Stop thinking in terms of people. Think in > terms of huge numbers of 'things' in the > ocean, in the atmosphere, in space, zillions > of 'things' on and around everyone's bodies > and homes and myriad other 'things' we can't > even imagine right now. > > scott > From lists.nanog at monmotha.net Sat Dec 30 02:18:37 2017 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 29 Dec 2017 21:18:37 -0500 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: On 12/29/2017 07:58 PM, Lewis,Mitchell T. wrote: > Greetings again, > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? Are you saying you want a 48V battery but AC in and AC to the devices being provided uninterruptible power, or do you want AC in and 48V DC out for both storage and devices being powered? If the latter, any reason not to just run conventional telecom-style DC plant with a "rectifier", stack(s) of 48V worth of lead-acid batteries, and appropriate DC power distribution? If the former, Tripp-Lite has several options that I like. You can get an "inverter/charger" (which is basically a UPS sans batteries) or many products in their SmartOnline (SU...) series have 48V batteries which can be external and (warranty/support issues aside as well as possible regulatory hassles) don't really care how big the battery bank is. -- Brandon Martin From surfer at mauigateway.com Sat Dec 30 02:30:40 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Dec 2017 18:30:40 -0800 Subject: Waste will kill ipv6 too Message-ID: <20171229183040.2D1FDBA0@m0117565.ppops.net> --- baldur.norddahl at gmail.com wrote: From: Baldur Norddahl Nobody needs to worry...Historically we spent... ------------------------------------------ Out of context, but yeah that. scott From michael at wi-fiber.io Sat Dec 30 02:31:47 2017 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 29 Dec 2017 19:31:47 -0700 Subject: Waste will kill ipv6 too In-Reply-To: References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: And if a medical breakthrough happens within the next 30 years? Nanobots that process insulin for the diabetic, or take care of cancer, or repair your cells so you don't age, or whatever, perhaps the inventor things ipv6 is a good idea for such an endeavour. a nanobot is microns wide, and there will be billions per person, hopefully not all on the same broadcast domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people = oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago. Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude below that. On 29 December 2017 at 19:12, Baldur Norddahl wrote: > Nobody needs to worry. I promise to reserve the last /32 out of my /29 > assignment. When the world has run out of addresses, I will start to sell > from my pool using the same allocation policy that was used for IPv4. I > would consider a /64 to be equal a /32 IPv4 address. This would make a /56 > assignment equal to a /24 IPv4 minimum assignment. > > Historically we spent about 3 decades before running out of IPv4 space. So > my scheme should be good enough for some additional decades of IPv6. > > I just hope nobody else does the same. That would be bad for my business > case. > > Regards > > Baldur > > > Den 30. dec. 2017 02.11 skrev "Scott Weeks" : > > > > > --- jlightfoot at gmail.com wrote: > > From: John Lightfoot > > > > Excuse the top post, but this seems to be an > > argument between people who understand big > > numbers and those who don't. > > ------------------------------------ > > > > No, not exactly. It's also about those that > > think in current/past network terms and those > > who are saying we don't know what the future > > holds, so we should be careful. > > > > > > > > ----------------------------- > > which means 79 octillion people...no one > > alive will be around > > ----------------------------- > > > > Stop thinking in terms of people. Think in > > terms of huge numbers of 'things' in the > > ocean, in the atmosphere, in space, zillions > > of 'things' on and around everyone's bodies > > and homes and myriad other 'things' we can't > > even imagine right now. > > > > scott > > > From gary.buhrmaster at gmail.com Sat Dec 30 02:46:49 2017 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 30 Dec 2017 02:46:49 +0000 Subject: Waste will kill ipv6 too In-Reply-To: References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: On Sat, Dec 30, 2017 at 2:31 AM, Michael Crapse wrote: > And if a medical breakthrough happens within the next 30 years? Nanobots > that process insulin for the diabetic, or take care of cancer, or repair > your cells so you don't age, or whatever, perhaps the inventor things ipv6 > is a good idea for such an endeavour. a nanobot is microns wide, and there > will be billions per person, hopefully not all on the same broadcast > domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for > ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people = > oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago. > Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude > below that. (the time has finally arrived) Obligatory xkcd ref: https://xkcd.com/865/ From Brian at ampr.org Sat Dec 30 02:50:38 2017 From: Brian at ampr.org (Brian Kantor) Date: Fri, 29 Dec 2017 18:50:38 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: <20171230025038.GA38197@meow.BKantor.net> On Sat, Dec 30, 2017 at 02:46:49AM +0000, Gary Buhrmaster wrote: > (the time has finally arrived) > Obligatory xkcd ref: https://xkcd.com/865/ Just how many nanobots can dance on the head of a pin? - Brian From brock at bmwl.co Sat Dec 30 03:01:09 2017 From: brock at bmwl.co (Brock Tice) Date: Fri, 29 Dec 2017 20:01:09 -0700 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: <15FA27FE-FCAC-4394-8369-89508D5A11AA@bmwl.co> On December 29, 2017 5:58:02 PM MST, "Lewis,Mitchell T." wrote: >Greetings again, >I have been looking for a Rack Mount UPS that accepts AC power input >but has 48vdc output(telco voltage). Anyone have any recommendations? > > > >Regards, > >Mitchell T. Lewis > >[ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > >[ http://linkedin.com/in/mlewiscc ] |203-816-0371 > >PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ >https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | >Public PGP Key ] > Samlex makes a nice one. 25A output. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From bill at herrin.us Sat Dec 30 03:05:15 2017 From: bill at herrin.us (William Herrin) Date: Fri, 29 Dec 2017 22:05:15 -0500 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T. wrote: > I have been looking for a Rack Mount UPS that accepts AC power input but > has 48vdc output(telco voltage). Anyone have any recommendations? > Hi Mitchell, That's not usually called an UPS. What you need is a Rectifier that feeds a -48 battery system. You connect your equipment the battery and make sure the rectifier system puts out enough wattage to both power the equipment and keep the battery topped off. Try searching ebay for "rack rectifier" Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Sat Dec 30 03:13:27 2017 From: bill at herrin.us (William Herrin) Date: Fri, 29 Dec 2017 22:13:27 -0500 Subject: Waste will kill ipv6 too In-Reply-To: <20171229171134.2D1FD881@m0117565.ppops.net> References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: On Fri, Dec 29, 2017 at 8:11 PM, Scott Weeks wrote: > Stop thinking in terms of people. Think in > terms of huge numbers of 'things' in the > ocean, in the atmosphere, in space, zillions > of 'things' on and around everyone's bodies > and homes and myriad other 'things' we can't > even imagine right now. > Think in terms of system architectures where the address space is fully consumed when empty to more than 20 decimal places. Because we're idiots and actually designed it that way. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ml-nanog at techcompute.net Sat Dec 30 03:16:46 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Fri, 29 Dec 2017 19:16:46 -0800 (PST) Subject: 48vDC Output UPS In-Reply-To: References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: <1552076465.331643.1514603806574.JavaMail.zimbra@techcompute.net> I should have been more specific(Quite obvious by the responses I have been getting). I am looking for a rack mount rectifier type device for a remote site(Not a Datacenter/Colo) which outputs 48vdc & has an 120vac input. I would like it to be remote monitor-able via snmp(battery charge, running on batteries etc). I am looking for a runtime of about an hour at about 500w load. A built in battery would be great but an external battery would work as well-I would like the whole setup to be no more than 3ru. The purpose this device will serve to allow remote monitoring of power conditions(Advance Power Outage Notification, Power Glitches etc) as well as power the connected devices for a short while in the event of a power glitch(Brown-Out, Power outages up to 30-45 minutes etc). I hope this help clarify. Thanks & Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "William Herrin" To: "Lewis,Mitchell T." Cc: "NANOG" Sent: Friday, December 29, 2017 10:05:15 PM Subject: Re: 48vDC Output UPS On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T. < [ mailto:ml-nanog at techcompute.net | ml-nanog at techcompute.net ] > wrote: I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? Hi Mitchell, That's not usually called an UPS. What you need is a Rectifier that feeds a -48 battery system. You connect your equipment the battery and make sure the rectifier system puts out enough wattage to both power the equipment and keep the battery topped off. Try searching ebay for "rack rectifier" Regards, Bill Herrin -- William Herrin ................ [ mailto:herrin at dirtside.com | herrin at dirtside.com ] [ mailto:bill at herrin.us | bill at herrin.us ] Dirtside Systems ......... Web: < [ http://www.dirtside.com/ | http://www.dirtside.com/ ] > From surfer at mauigateway.com Sat Dec 30 03:26:33 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Dec 2017 19:26:33 -0800 Subject: Waste will kill ipv6 too Message-ID: <20171229192633.2D1FDB5B@m0117565.ppops.net> --- Brian at ampr.org wrote: From: Brian Kantor Just how many nanobots can dance on the head of a pin? --------------------------------------- 2^128? Just guessing. >;-) scott From randy at psg.com Sat Dec 30 05:05:01 2017 From: randy at psg.com (Randy Bush) Date: Sat, 30 Dec 2017 14:05:01 +0900 Subject: Waste will kill ipv6 too In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: the good thing about these long threads, which have ZERO new information, is having a KillThread command in one's mail user agent. get a life! From bryan at shout.net Sat Dec 30 05:23:09 2017 From: bryan at shout.net (Bryan Holloway) Date: Fri, 29 Dec 2017 23:23:09 -0600 Subject: 48vDC Output UPS In-Reply-To: <1552076465.331643.1514603806574.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> <1552076465.331643.1514603806574.JavaMail.zimbra@techcompute.net> Message-ID: <16433731-cfbb-e9c5-ed18-7dd840b47dea@shout.net> Eltek is worth a look. Really solid stuff. Used them for awhile now. If you want battery back-up, it'll probably take more than 3 RU, though. On 12/29/17 9:16 PM, Lewis,Mitchell T. wrote: > I should have been more specific(Quite obvious by the responses I have been getting). I am looking for a rack mount rectifier type device for a remote site(Not a Datacenter/Colo) which outputs 48vdc & has an 120vac input. I would like it to be remote monitor-able via snmp(battery charge, running on batteries etc). I am looking for a runtime of about an hour at about 500w load. A built in battery would be great but an external battery would work as well-I would like the whole setup to be no more than 3ru. > > The purpose this device will serve to allow remote monitoring of power conditions(Advance Power Outage Notification, Power Glitches etc) as well as power the connected devices for a short while in the event of a power glitch(Brown-Out, Power outages up to 30-45 minutes etc). > > I hope this help clarify. > > > Thanks & Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > > > > From: "William Herrin" > To: "Lewis,Mitchell T." > Cc: "NANOG" > Sent: Friday, December 29, 2017 10:05:15 PM > Subject: Re: 48vDC Output UPS > > On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T. < [ mailto:ml-nanog at techcompute.net | ml-nanog at techcompute.net ] > wrote: > > > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? > > > > Hi Mitchell, > > That's not usually called an UPS. What you need is a Rectifier that feeds a -48 battery system. You connect your equipment the battery and make sure the rectifier system puts out enough wattage to both power the equipment and keep the battery topped off. > > Try searching ebay for "rack rectifier" > > Regards, > Bill Herrin > > From owen at delong.com Sat Dec 30 05:48:31 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Dec 2017 21:48:31 -0800 Subject: Waste will kill ipv6 too In-Reply-To: <20171229171134.2D1FD881@m0117565.ppops.net> References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: <8B97E2E4-D27F-4BE7-B4F9-E75EE5236F4D@delong.com> > On Dec 29, 2017, at 17:11, Scott Weeks wrote: > > > --- jlightfoot at gmail.com wrote: > From: John Lightfoot > > Excuse the top post, but this seems to be an > argument between people who understand big > numbers and those who don't. > ------------------------------------ > > No, not exactly. It's also about those that > think in current/past network terms and those > who are saying we don't know what the future > holds, so we should be careful. > > > > ----------------------------- > which means 79 octillion people...no one > alive will be around > ----------------------------- > > Stop thinking in terms of people. Think in > terms of huge numbers of 'things' in the > ocean, in the atmosphere, in space, zillions > of 'things' on and around everyone's bodies > and homes and myriad other 'things' we can't > even imagine right now. Sure, but likely zillions of ocean sensors will share a few /64s rather than getting a /48 each. Do you really think each person needs more than a thousand or so subnets for their wearable sensors? If not, then 1 of the many /48s they can safely consume has them covered. Can I see a possible future in which homes actually need /48s? Sure. But we’ve got more than enough /48s to do that. As I’ve said many times before, let’s see how it goes with the first /3 doing things as designed and intended. If it turns out to consume that 1/8th of the address space while I’m still alive, I’ll happily help build more restrictive allocation policies for the remaining virgin 5/8ths and the fractions of the 1/4 of the address that have a very small number of special use carve-outs (0::/3 and e000::/3). Given that we still have more than 500 /12s free in the first /3 20 years into the process, I’m thinking we aren’t likely to have that issue. Owen > > scott From owen at delong.com Sat Dec 30 05:52:24 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Dec 2017 21:52:24 -0800 Subject: Waste will kill ipv6 too In-Reply-To: References: <20171229171134.2D1FD881@m0117565.ppops.net> Message-ID: <229A439A-EA76-43C2-BC91-BA0FA3C8B1D5@delong.com> Giving each nanobot a pair of /64s would be absurd. Maybe they aren’t all on the same link (there are no broadcast domains in IPv6), but likely a few /64s would cover each person. Owen > On Dec 29, 2017, at 18:31, Michael Crapse wrote: > > And if a medical breakthrough happens within the next 30 years? Nanobots > that process insulin for the diabetic, or take care of cancer, or repair > your cells so you don't age, or whatever, perhaps the inventor things ipv6 > is a good idea for such an endeavour. a nanobot is microns wide, and there > will be billions per person, hopefully not all on the same broadcast > domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for > ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people = > oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago. > Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude > below that. > > On 29 December 2017 at 19:12, Baldur Norddahl > wrote: > >> Nobody needs to worry. I promise to reserve the last /32 out of my /29 >> assignment. When the world has run out of addresses, I will start to sell >> from my pool using the same allocation policy that was used for IPv4. I >> would consider a /64 to be equal a /32 IPv4 address. This would make a /56 >> assignment equal to a /24 IPv4 minimum assignment. >> >> Historically we spent about 3 decades before running out of IPv4 space. So >> my scheme should be good enough for some additional decades of IPv6. >> >> I just hope nobody else does the same. That would be bad for my business >> case. >> >> Regards >> >> Baldur >> >> >> Den 30. dec. 2017 02.11 skrev "Scott Weeks" : >> >>> >>> --- jlightfoot at gmail.com wrote: >>> From: John Lightfoot >>> >>> Excuse the top post, but this seems to be an >>> argument between people who understand big >>> numbers and those who don't. >>> ------------------------------------ >>> >>> No, not exactly. It's also about those that >>> think in current/past network terms and those >>> who are saying we don't know what the future >>> holds, so we should be careful. >>> >>> >>> >>> ----------------------------- >>> which means 79 octillion people...no one >>> alive will be around >>> ----------------------------- >>> >>> Stop thinking in terms of people. Think in >>> terms of huge numbers of 'things' in the >>> ocean, in the atmosphere, in space, zillions >>> of 'things' on and around everyone's bodies >>> and homes and myriad other 'things' we can't >>> even imagine right now. >>> >>> scott >>> >> From baldur.norddahl at gmail.com Sat Dec 30 13:36:06 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 30 Dec 2017 14:36:06 +0100 Subject: Waste will kill ipv6 too In-Reply-To: <20171229183040.2D1FDBA0@m0117565.ppops.net> References: <20171229183040.2D1FDBA0@m0117565.ppops.net> Message-ID: <923f03cd-b3a2-9d66-6118-72bf9ec1ca94@gmail.com> Den 30/12/2017 kl. 03.30 skrev Scott Weeks: > > --- baldur.norddahl at gmail.com wrote: > From: Baldur Norddahl > > Nobody needs to worry...Historically we spent... > ------------------------------------------ > > > Out of context, but yeah that. > > scott Not to worry, I thought about what to do if we run out of space. I will reserve my last /32 and sell sub allocations from that. Should that run out, I will reserve my last /64 out of my last /32 and sell /96 sub allocations from that. Just to be safe, I will also reserve the last /96 out of my last /64, so I can sell /128 from that. Every single network has enough address space to keep us going forever. It is not possible to "run out" of IPv6 address space like what happened to IPv4. Can we keep using the liberal allocation policy forever? Maybe not. But then we can simply switch to a more restrictive policy. Someone (or everyone) has enough space to sub allocate using this more restrictive policy forever. Does it make sense to switch to a more restrictive policy NOW? No why would we? Just so they can switch to the liberal policy sometime in the future? It is not so we can keep going with a restrictive policy forever, because that will always be an option, no matter what we do now. Regards, Baldur From list at satchell.net Sat Dec 30 14:42:46 2017 From: list at satchell.net (Stephen Satchell) Date: Sat, 30 Dec 2017 06:42:46 -0800 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: References: <3A60EBB4-674B-4D01-B3F8-51563E60E77D@egon.cc> <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> Message-ID: <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> On 12/29/2017 09:05 PM, Randy Bush wrote: > the good thing about these long threads, which have ZERO new > information, is having a KillThread command in one's mail user agent. > get a life! I no longer use KillThread. Instead, I sort my inbox by subject, and use the Delete key liberally. NANOG is by no means my first mailing list where religious wars have broken out. (*cough* Linux kernel list) :) From bryan at shout.net Sat Dec 30 19:26:08 2017 From: bryan at shout.net (Bryan Holloway) Date: Sat, 30 Dec 2017 13:26:08 -0600 Subject: Wi-Fi Analyzer In-Reply-To: References: <91b5bf8b-d59c-b036-ae80-dffee8cafaed@shout.net> Message-ID: <1a85bc38-a657-cf63-2dd5-5c21b7da8386@shout.net> Thanks for all of the great suggestions, both on- and off-list!! Cheers and Happy New Year, everyone. On 12/29/17 1:16 PM, Eric Kuhnke wrote: > In addition to the other tools already recommended by previous posters, I > recommend buying one of these: > > https://www.ubnt.com/airmax/nanobeam-ac-gen2/ > > It's a directional antenna/radio integrated unit and is intended as a point > to point or point-to-multipoint WISP client radio. The one feature you can > get from it very cheaply is a directional, 2x2 MIMO 5.x GHz band spectrum > analyzer that sees things *which are not 802.11 or wifi based.* > > The airview spectrum analyzer tool built into it looks like this: > https://www.google.com/search?q=ubiquiti+airview&num=100&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj0gtLI9q_YAhUC62MKHbZoAogQ_AUICygC&biw=1744&bih=994&dpr=1.1 > > Highly useful for tracking down a specific source of non-wifi 5 GHz band > interference. There's all sorts of random consumer grade things people can > buy and introduce into an environment which do not broadcast MAC addresses > or SSIDs, and do not show up on purely 802.11(abgn/ac) based tools. > > It will of course also see hidden SSIDs and standard+non-standard > 802.11abgn(ac) emitters. > > There are also 2.4 GHz versions of similar products which will let you find > non-802.11 emitters in the 2300 to 2500 MHz band. At $79 a lot less > expensive than a "real" spectrum analyzer. > > You can get DC PoE injectors for them which will connect to a Makita drill > battery if you want to make it portable and wander around with a laptop. > > > On Fri, Dec 29, 2017 at 7:17 AM, Bryan Holloway wrote: > >> Curious if the community has any recommendations and/or positive >> experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. >> >> Software/laptop-based solutions can be unwieldy in certain environments. >> However, given rave reviews, I'm open to the idea as long as it's >> Mac-compatible. >> >> Should be able to show detailed spectra, help locate sources of >> interference, have mapping capabilities, etc. >> >> Thanks! >> From math at sizone.org Sat Dec 30 23:39:05 2017 From: math at sizone.org (sizone!math) Date: Sat, 30 Dec 2017 18:39:05 -0500 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: <20171230154600.GB4208@sizone.org> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> Message-ID: <20171230233905.GK6349@sizone.org> On Sat, Dec 30, 2017 at 06:42:46AM -0800, Stephen Satchell said: > On 12/29/2017 09:05 PM, Randy Bush wrote: > >the good thing about these long threads, which have ZERO new > >information, is having a KillThread command in one's mail user agent. > >get a life! > >I no longer use KillThread. Instead, I sort my inbox by subject, and use >the Delete key liberally. NANOG is by no means my first mailing list where >religious wars have broken out. (*cough* Linux kernel list) :) I used to gate mailing lists into cnews, and then just use tin with well-developed killfiles. Been a while though since I've touched a news system at all. (long live sizone.uucp! :) Unfortunately I haven't gotten mutt to the tin level (though collapsing threads makes reading the index easier..). (Ctrl-D to kill an entire thread in mutt btw.) Congrats on the record breaking thread! If anyone wants to TL;DR Im mildly interested in the results of this 'wisdom of the cloud' brainstorm. Certainly ipv6 is well solved by now. Happy Brave New ipv6 Year! /kc -- Ken Chase - uunet.ca!{ryelect,zeibmef,pci,jaywon,robohack}!sizone!math From large.hadron.collider at gmx.com Sat Dec 30 23:42:48 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Sat, 30 Dec 2017 15:42:48 -0800 Subject: Threads that never end In-Reply-To: <20171230233905.GK6349@sizone.org> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> Message-ID: I haven't even ... This thread's going to turn into another thread that never ends. On 30/12/2017 15:39, sizone!math wrote: > On Sat, Dec 30, 2017 at 06:42:46AM -0800, Stephen Satchell said: > > On 12/29/2017 09:05 PM, Randy Bush wrote: > > >the good thing about these long threads, which have ZERO new > > >information, is having a KillThread command in one's mail user agent. > > >get a life! > > > >I no longer use KillThread. Instead, I sort my inbox by subject, and use > >the Delete key liberally. NANOG is by no means my first mailing list where > >religious wars have broken out. (*cough* Linux kernel list) :) > > I used to gate mailing lists into cnews, and then just use tin with > well-developed killfiles. Been a while though since I've touched a news system > at all. (long live sizone.uucp! :) Unfortunately I haven't gotten mutt to the > tin level (though collapsing threads makes reading the index easier..). > (Ctrl-D to kill an entire thread in mutt btw.) > > Congrats on the record breaking thread! If anyone wants to TL;DR Im mildly > interested in the results of this 'wisdom of the cloud' brainstorm. Certainly > ipv6 is well solved by now. > > Happy Brave New ipv6 Year! > > /kc > -- > Ken Chase - uunet.ca!{ryelect,zeibmef,pci,jaywon,robohack}!sizone!math > From andy at newslink.com Sun Dec 31 03:57:47 2017 From: andy at newslink.com (Andy Ringsmuth) Date: Sat, 30 Dec 2017 21:57:47 -0600 Subject: Iran censorship? Message-ID: <6C56EB5E-D9FB-439D-96C8-6E6B8B0090C5@newslink.com> Thought this might be a welcome change from the IPv6 waste discussion and meta-discussion. Seeing a few references in the news to Iran possibly cutting off Internet (at least on mobile devices) in light of significant protests around the country: https://www.yahoo.com/news/iran-warns-against-illegal-gatherings-protests-112847988.html Was curious if anyone “in the know” has anything to back it up, etc. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From andy at newslink.com Sun Dec 31 04:30:12 2017 From: andy at newslink.com (Andy Ringsmuth) Date: Sat, 30 Dec 2017 22:30:12 -0600 Subject: Iran censorship? In-Reply-To: References: <6C56EB5E-D9FB-439D-96C8-6E6B8B0090C5@newslink.com> Message-ID: I do remember that, and I know they’re capable of it. Was simply curious if anyone was aware of it actually happening (yet) this time around. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular > On Dec 30, 2017, at 10:19 PM, Matt Harris wrote: > > This is nothing new for even moderate authoritarian states (see: Egypt during the 'arab spring' protests), and should be no surprise from a totalitarian state such as Iran. > > We've seen Iran up to no good on a global scale in the past, too, far beyond what's being suggested here: https://dyn.com/blog/iran-leaks-censorship-via-bgp-hijacks/ > So we know that they have national censorship in place. > > Are you looking for anything more specific here? > > > On Sat, Dec 30, 2017 at 9:57 PM, Andy Ringsmuth wrote: > Thought this might be a welcome change from the IPv6 waste discussion and meta-discussion. > > Seeing a few references in the news to Iran possibly cutting off Internet (at least on mobile devices) in light of significant protests around the country: > > https://www.yahoo.com/news/iran-warns-against-illegal-gatherings-protests-112847988.html > > Was curious if anyone “in the know” has anything to back it up, etc. > > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > > > > -- > Matt Harris - Chief Security Officer > Main: +1 855.696.3834 ext 103 > Mobile: +1 908.590.9472 > Email: matt at netfire.net > From randy at psg.com Sun Dec 31 04:36:32 2017 From: randy at psg.com (Randy Bush) Date: Sun, 31 Dec 2017 13:36:32 +0900 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: <20171230233905.GK6349@sizone.org> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> Message-ID: > If anyone wants to TL;DR moe: 2^128 is effectively infinita larry: we thought 2^32 was effectively infinite curly: we'll never need more than 640k thomas watson: i think there is a world market for maybe five computers From frnkblk at iname.com Sun Dec 31 19:24:27 2017 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sun, 31 Dec 2017 13:24:27 -0600 Subject: 48vDC Output UPS In-Reply-To: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> Message-ID: <000401d3826c$f9bbce30$ed336a90$@iname.com> I've been looking for many years for something similar, one that has integrated batteries and is remote manageable (or ties into our equipment's telemetry) and reasonably priced, but haven't yet found one, yet. Many of the NIDs/ONTs that we install at our customer sites are DC powered, but none of the traditional ONT vendors have a rack-mountable solution. We'd like an all-in-one so it's neat and clean. This is what I found last time I looked: http://www.ict-power.com/products/display_pro.php?id=1458 (optional external battery backup) http://www.ict-power.com/products/display_digital.php?id=1287 (optional external battery backup) http://www.poweringthenetwork.com/integrated-power-system/ IPS 48-11 (only 5 Ah, no Ethernet management) https://www.fiberopticlink.com/products-item/acdc-2ru-rack-mount-power-supply/ (only 4.5 Ah, no Ethernet management) https://www.seipower.com/dc-48v-rack-mount/ (no Ethernet management) http://www.duracomm.com/product-category/rack-mount-power-supplies/ (no Ethernet management) Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. Sent: Friday, December 29, 2017 6:58 PM To: NANOG Subject: 48vDC Output UPS Greetings again, I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From simon at slimey.org Sun Dec 31 19:54:38 2017 From: simon at slimey.org (Simon Lockhart) Date: Sun, 31 Dec 2017 19:54:38 +0000 Subject: 48vDC Output UPS In-Reply-To: <000401d3826c$f9bbce30$ed336a90$@iname.com> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> <000401d3826c$f9bbce30$ed336a90$@iname.com> Message-ID: <20171231195438.GA13410@dilbert.slimey.org> I've got this in my lab. Batteries aren't integrated, but it has battery terminals to add some (and charge/monitor)... http://www.eltek.com/us/detail_products.epl?k1=25823&close=1&id=1291844 Ethernet management is built in (HTTP/SNMP). Simon On Sun Dec 31, 2017 at 01:24:27pm -0600, frnkblk at iname.com wrote: > I've been looking for many years for something similar, one that has integrated batteries and is remote manageable (or ties into our equipment's telemetry) and reasonably priced, but haven't yet found one, yet. Many of the NIDs/ONTs that we install at our customer sites are DC powered, but none of the traditional ONT vendors have a rack-mountable solution. We'd like an all-in-one so it's neat and clean. This is what I found last time I looked: > > http://www.ict-power.com/products/display_pro.php?id=1458 (optional external battery backup) > http://www.ict-power.com/products/display_digital.php?id=1287 (optional external battery backup) > http://www.poweringthenetwork.com/integrated-power-system/ IPS 48-11 (only 5 Ah, no Ethernet management) > https://www.fiberopticlink.com/products-item/acdc-2ru-rack-mount-power-supply/ (only 4.5 Ah, no Ethernet management) > https://www.seipower.com/dc-48v-rack-mount/ (no Ethernet management) > http://www.duracomm.com/product-category/rack-mount-power-supplies/ (no Ethernet management) > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. > Sent: Friday, December 29, 2017 6:58 PM > To: NANOG > Subject: 48vDC Output UPS > > Greetings again, > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? > > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > > > > -- Simon Lockhart | * Server Co-location * ADSL * Domain Registration * Director | * Domain & Web Hosting * Connectivity * Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From pete at ots.utsystem.edu Sun Dec 31 20:53:52 2017 From: pete at ots.utsystem.edu (Mitcheltree, Harold B) Date: Sun, 31 Dec 2017 20:53:52 +0000 Subject: 48vDC Output UPS In-Reply-To: <20171231195438.GA13410@dilbert.slimey.org> References: <89235404.327730.1514595482640.JavaMail.zimbra@techcompute.net> <000401d3826c$f9bbce30$ed336a90$@iname.com>, <20171231195438.GA13410@dilbert.slimey.org> Message-ID: Unit in URL below has integrated distribution breakers and battery string breaker. It's a 1RU. you'll need at LEAST an additional 2RU for batteries. Supports float charging, has built-in battery low volt disconnect and battery thermal monitor. SNMP management over IPv4 supported. Available with 400W or 800W or 1200W power modules. For USB craft interface order with ACC controller. For EIA232 serial craft port order with PCC controller. https://www.unipowerco.com/products/45-amp-dc-power-system-aspiro1u/ [https://www.unipowerco.com/wp-content/uploads/2016/03/aspiro1u_landing_na.jpg] 45 Amp DC Power System - Aspiro 1U | UNIPOWER www.unipowerco.com UNIPOWER is a world leading provider of dependable high‐efficiency power electronics and energy conversion systems and power supplies. https://goo.gl/tBXDEX 2RU battery subsystem. --pete ________________________________ From: NANOG on behalf of Simon Lockhart Sent: Sunday, December 31, 2017 1:54:38 PM To: frnkblk at iname.com Cc: NANOG Subject: Re: 48vDC Output UPS I've got this in my lab. Batteries aren't integrated, but it has battery terminals to add some (and charge/monitor)... http://www.eltek.com/us/detail_products.epl?k1=25823&close=1&id=1291844 Ethernet management is built in (HTTP/SNMP). Simon On Sun Dec 31, 2017 at 01:24:27pm -0600, frnkblk at iname.com wrote: > I've been looking for many years for something similar, one that has integrated batteries and is remote manageable (or ties into our equipment's telemetry) and reasonably priced, but haven't yet found one, yet. Many of the NIDs/ONTs that we install at our customer sites are DC powered, but none of the traditional ONT vendors have a rack-mountable solution. We'd like an all-in-one so it's neat and clean. This is what I found last time I looked: > > http://www.ict-power.com/products/display_pro.php?id=1458 (optional external battery backup) > http://www.ict-power.com/products/display_digital.php?id=1287 (optional external battery backup) > http://www.poweringthenetwork.com/integrated-power-system/ IPS 48-11 (only 5 Ah, no Ethernet management) > https://www.fiberopticlink.com/products-item/acdc-2ru-rack-mount-power-supply/ (only 4.5 Ah, no Ethernet management) > https://www.seipower.com/dc-48v-rack-mount/ (no Ethernet management) > http://www.duracomm.com/product-category/rack-mount-power-supplies/ (no Ethernet management) > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. > Sent: Friday, December 29, 2017 6:58 PM > To: NANOG > Subject: 48vDC Output UPS > > Greetings again, > I have been looking for a Rack Mount UPS that accepts AC power input but has 48vdc output(telco voltage). Anyone have any recommendations? > > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > > > > -- Simon Lockhart | * Server Co-location * ADSL * Domain Registration * Director | * Domain & Web Hosting * Connectivity * Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net *