From ccosta92630 at gmail.com Wed Jun 1 03:46:26 2016 From: ccosta92630 at gmail.com (Chris Costa) Date: Tue, 31 May 2016 20:46:26 -0700 Subject: Building a technical library Message-ID: Looking to develop a technical library for about 15 staff members all under the same roof. Subject matter would focus around Juniper/Junos, TCP/IP, dwdm, python, java, and expand from there. The O'reilly Safari service looks rather comprehensive, although at $400/user there may be more value buying hard copies and own them outright (or at least until they walk away). Are there other online resources that offer a good value? Other experiences weighing the pros and cons? Thanks, Chris From cb.list6 at gmail.com Wed Jun 1 03:53:43 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 31 May 2016 20:53:43 -0700 Subject: Building a technical library In-Reply-To: References: Message-ID: On Tuesday, May 31, 2016, Chris Costa wrote: > Looking to develop a technical library for about 15 staff members all under > the same roof. Subject matter would focus around Juniper/Junos, TCP/IP, > dwdm, python, java, and expand from there. The O'reilly Safari service > looks rather comprehensive, although at $400/user there may be more value > buying hard copies and own them outright (or at least until they walk > away). Are there other online resources that offer a good value? Other > experiences weighing the pros and cons? > > Thanks, > Chris > I have always used the public library, libraries i am familiar with have ebook offerings that are comparable to safari if not safari itself From nanogml at Mail.DDoS-Mitigator.net Wed Jun 1 04:38:02 2016 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Tue, 31 May 2016 21:38:02 -0700 Subject: Building a technical library In-Reply-To: References: Message-ID: <20160601043802.GA12069@Mail.DDoS-Mitigator.net> hi ya chris On 05/31/16 at 08:53pm, Ca By wrote: > On Tuesday, May 31, 2016, Chris Costa wrote: > > > Looking to develop a technical library for about 15 staff members all under > > the same roof. Subject matter would focus around Juniper/Junos, TCP/IP, > > dwdm, python, java, and expand from there. The O'reilly Safari service > > looks rather comprehensive, although at $400/user there may be more value $400 is good for around 5-8 new books .. > > buying hard copies and own them outright (or at least until they walk > > away). books are like paper clips and pens .. somehow they grow legs and like to play hide-n-seek > > Are there other online resources that offer a good value? Other > > experiences weighing the pros and cons? i'm one that say "owning" is better than renting under some cases .. - books is best owned because you probably have to look up the subject matter again and again, or put it into your online notes - usually, books comes with examples on DVD, or at least the ones i get - oreilly series, sam's, dummy series, IDG series, one can go broke :-) i have most of the common topics, but not cisco/juniper type stuff and most all books have been in dozens of boxes since moving and not unpacked - google is always good resource but filtering thru various posts/blogs implies you know what you're looking for - barns n noble is usually good for quick browsing - computer literacy is always good ( sf bay area ), not sure if they still around, similarly for digital guru > I have always used the public library, libraries i am familiar with have > ebook offerings that are comparable to safari if not safari itself public libraries are seriously lacking "good techie books" stuff university libraries are good too, but not sure if they let anybody browse another option .. everybody contributes to your "wiki" with pertinent info of what you were expecting to find in the "rent-a-book" services happy reading ( n comprehension ) alvin # # DDoS-Mitigator.net # DDoS-Simulator.net # From tore at fud.no Wed Jun 1 08:37:07 2016 From: tore at fud.no (Tore Anderson) Date: Wed, 1 Jun 2016 10:37:07 +0200 Subject: Public DNS64 In-Reply-To: References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: <20160601103707.7de9d97f@envy.e5.y.home> * Baldur Norddahl > It goes to the USA and back again. They would need NAT64 servers in > every region and then let the DNS64 service decide which one is close > to you by encoding the region information in the returned IPv6 > address. Such as 2001:470:64:[region number]::/96. > > An anycast solution would need a distributed NAT64 implementation, > such that the NAT64 servers could somehow synchronize state. Or you could simply accept that active sessions are torn down whenever the routing topology changes enough to flip traffic to the anycast prefix to another NAT64 instance in a different region. It would be no different from any other anycasted service. Tore From marty at cloudflare.com Wed Jun 1 10:30:57 2016 From: marty at cloudflare.com (Marty Strong) Date: Wed, 1 Jun 2016 11:30:57 +0100 Subject: PeeringDB ? In-Reply-To: <20160524114342.GP81971@Vurt.local> References: <20160524114342.GP81971@Vurt.local> Message-ID: <516B6CB4-5B4C-479E-95E1-BBF94EF138ED@cloudflare.com> More issues? :( Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 24 May 2016, at 12:43, Job Snijders wrote: > > On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: >> Whats happened today at PeeringDB web site ? > > And PeeringDB is back in business! http://instituut.net/~job/screenshots/2f255c17a8aa9cb99121b448.png > > A post-mortem will be shared on the pdb-tech@ list later today. > > Kind regards, > > Job From fohdeesha at gmail.com Wed Jun 1 11:12:29 2016 From: fohdeesha at gmail.com (Jon Sands) Date: Wed, 1 Jun 2016 07:12:29 -0400 Subject: ISP License in the USA? In-Reply-To: <01ABE89A-37ED-409C-81F7-5F1F9CC00C97@delong.com> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> <01ABE89A-37ED-409C-81F7-5F1F9CC00C97@delong.com> Message-ID: He might have meant one of these: Consultants Often Adlib License Specifications From marka at isc.org Wed Jun 1 11:49:30 2016 From: marka at isc.org (Mark Andrews) Date: Wed, 01 Jun 2016 21:49:30 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Wed, 01 Jun 2016 10:37:07 +0200." <20160601103707.7de9d97f@envy.e5.y.home> References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> <20160601103707.7de9d97f@envy.e5.y.home> Message-ID: <20160601114930.DED5D4A85314@rock.dv.isc.org> In message <20160601103707.7de9d97f at envy.e5.y.home>, Tore Anderson writes: > * Baldur Norddahl > > > It goes to the USA and back again. They would need NAT64 servers in > > every region and then let the DNS64 service decide which one is close > > to you by encoding the region information in the returned IPv6 > > address. Such as 2001:470:64:[region number]::/96. > > > > An anycast solution would need a distributed NAT64 implementation, > > such that the NAT64 servers could somehow synchronize state. > > Or you could simply accept that active sessions are torn down whenever > the routing topology changes enough to flip traffic to the anycast > prefix to another NAT64 instance in a different region. > > It would be no different from any other anycasted service. But some services are inherently short lived. NAT64 has no such property. > Tore -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tore at fud.no Wed Jun 1 12:47:10 2016 From: tore at fud.no (Tore Anderson) Date: Wed, 1 Jun 2016 14:47:10 +0200 Subject: Public DNS64 In-Reply-To: <20160601114930.DED5D4A85314@rock.dv.isc.org> References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> <20160601103707.7de9d97f@envy.e5.y.home> <20160601114930.DED5D4A85314@rock.dv.isc.org> Message-ID: <20160601144710.213d7e64@envy.e5.y.home> * Mark Andrews > In message <20160601103707.7de9d97f at envy.e5.y.home>, Tore Anderson writes: > > Or you could simply accept that active sessions are torn down > > whenever the routing topology changes enough to flip traffic to the > > anycast prefix to another NAT64 instance in a different region. > > > > It would be no different from any other anycasted service. > > But some services are inherently short lived. NAT64 has no such > property. Well, yes - it depends on the service/application, right? That is, anycasted_${service} will work pretty much the same as ${service}_via_anycasted_nat64 for most values of ${service}. Assuming that: 1) most of your customer's sessions are short-lived and/or their applications can handle failures reasonably gracefully, and/or 2) you have a stable and well-designed network where you can be reasonably certain that the traffic from clients in city/region/country X is going to consistently be routed to the NAT64 instance in city/region/country X: ...you will have very little to gain by setting up some complicated NAT64 session replication scheme to city/region/country Y, Z, and so on. KISS: Just use different IPv4 source address pools in each location and accept that any long-lived sessions are interrupted when your routing turns really wonky once in a blue moon. If on the other hand you cannot under any circumstance accept disruption to existing sessions, you probably don't want to be using any form of NAT in the first place. It's not like anycast routes flipping is the only reason why sessions through a NAT can be disrupted. In that case, native IPv6 is probably better, or possibly MAP if you have no control over the (presumably IPv4-only) remote ends of those sessions. Tore From cb.list6 at gmail.com Wed Jun 1 13:08:17 2016 From: cb.list6 at gmail.com (Ca By) Date: Wed, 1 Jun 2016 06:08:17 -0700 Subject: Public DNS64 In-Reply-To: References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: On Monday, May 30, 2016, Ca By wrote: > > > On Monday, May 30, 2016, Baldur Norddahl > wrote: > >> > >> > Like HE is doing? >> > >> > swmike at uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net >> > 2001:470:64:ffff::d4f7:c88f >> > swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f >> > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data >> bytes >> > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms >> > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms >> > >> > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means >> > the NAT64 isn't very local to me... :P >> >> >> >> It goes to the USA and back again. They would need NAT64 servers in every >> region and then let the DNS64 service decide which one is close to you by >> encoding the region information in the returned IPv6 address. Such as >> 2001:470:64:[region number]::/96. >> >> An anycast solution would need a distributed NAT64 implementation, such >> that the NAT64 servers could somehow synchronize state. A more simple >> solution is just to have the DNS64 be anycast and have a DNS64 at each >> NAT64 location with the DNS64 returning pointers to the local NAT64. >> >> Now, can we have a public MAP server? That might scale. The geo blockers >> will hate it. What is not to like? >> >> > MAP scale. I know folks think it is theoretically nice but.... > > > Just curious, has anyone yet deployed MAP at scale? I know of several > production and large scale nat64s (usually mobile 464xlat related), and a > few large ds-lite, but never MAP in production at scale. Maybe i am > missing something. > > CB > > Tore's email reminded me that we got no answers about a production large scale MAP deployment. I guess it is yet to be deployed. Since it came up 2x in this thread, not only is MAP apparently not deployed anywhere at scale and therefore unproven in the real world, it would not fit this public usecase. MAP requires dhcpv6 and that dhcpv6 server must statefully / tight-coordination assign the addresses and ports to the end user. This complexity and requirement, along with the unsavoriness of yet another tunnel made MAP a deal breaker for my network. It also statically assigns s fixed number of scarce ipv4 ports to users, this is inefficient and not flexible. I suppose some party could launch a public dhpv6 server. But the 2nd hop routing would not work without several hacks CB > Regards, >> >> Baldur >> > From jason.m.lee at gmail.com Wed Jun 1 17:58:15 2016 From: jason.m.lee at gmail.com (Jason Lee) Date: Wed, 1 Jun 2016 12:58:15 -0500 Subject: Tracking traffic usage at router or switch port? Message-ID: NANOG Community, Typically where would you expect a service provider to monitor bandwidth usage on your circuits? On the physical switch port interface or on the vlan interface at the router? In some of the field testing I've been doing there can be a difference in the bandwidth usage on the vlan interface at the router vs the physical switch port. Is there any particular reason for using one vs the other? Is there an industry best practice for this? Thanks, Jason From JJaritsch at anexia-it.com Wed Jun 1 17:59:45 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Wed, 1 Jun 2016 17:59:45 +0000 Subject: Verizon and Level3 DNS flush Message-ID: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> Dear NANOGers, is there anyone from Verizon and Level3 who can help me with DNS caching issue? We're running a global service for a customer and we had to change to NS IPs via Glue Records. At the moment at least Verizone and Level3 are caching old NS records. Looking for DNS admins out there. Please contact me off- or on-list! Thanks & best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From sryan at arbor.net Wed Jun 1 18:02:37 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 1 Jun 2016 14:02:37 -0400 Subject: Tracking traffic usage at router or switch port? In-Reply-To: References: Message-ID: I would monitor it wherever you would do traffic shaping/policing. If that happens on the CPE monitor it there. If the CPE is just all Layer2 back to a router or whatever and the router is doing rate limiting monitor it there. For circuits that run at wirespeed with no limits (10/100/1000/10k/etc) the same logic applies, just monitor the bandwidth where you would normally do the policing. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 1, 2016 at 1:58 PM, Jason Lee wrote: > NANOG Community, > > Typically where would you expect a service provider to monitor bandwidth > usage on your circuits? On the physical switch port interface or on the > vlan interface at the router? In some of the field testing I've been doing > there can be a difference in the bandwidth usage on the vlan interface at > the router vs the physical switch port. Is there any particular reason for > using one vs the other? Is there an industry best practice for this? > > Thanks, > > Jason > From hugo at slabnet.com Wed Jun 1 18:04:11 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 1 Jun 2016 11:04:11 -0700 Subject: Tracking traffic usage at router or switch port? In-Reply-To: References: Message-ID: <20160601180411.GF6467@bamboo.slabnet.com> On Wed 2016-Jun-01 12:58:15 -0500, Jason Lee wrote: >NANOG Community, > >Typically where would you expect a service provider to monitor bandwidth >usage on your circuits? On the physical switch port interface or on the >vlan interface at the router? In some of the field testing I've been doing >there can be a difference in the bandwidth usage on the vlan interface at >the router vs the physical switch port. Is there any particular reason for >using one vs the other? Is there an industry best practice for this? How big of a difference? Full frame / L2 (@ switch) vs. L3 payload (@ router)? > >Thanks, > >Jason -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From mel at beckman.org Wed Jun 1 18:08:15 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 1 Jun 2016 18:08:15 +0000 Subject: Tracking traffic usage at router or switch port? In-Reply-To: References: Message-ID: <04F47AA1-6715-47E8-973D-97FB04492F75@beckman.org> The reason there can be a (small) difference between those two test points is encapsulation overhead. If the provider is counting traffic that is still in an MPLS envelope, it will count more bytes than it will after the traffic has been stripped down to just the Ethernet frame on the switch port. This isn?t a big deal for large packets, but for small packets, such as those used for streaming protocol (e.g., VoIP) the percentage of overhead can be as high as 15%. -mel > On Jun 1, 2016, at 10:58 AM, Jason Lee wrote: > > NANOG Community, > > Typically where would you expect a service provider to monitor bandwidth > usage on your circuits? On the physical switch port interface or on the > vlan interface at the router? In some of the field testing I've been doing > there can be a difference in the bandwidth usage on the vlan interface at > the router vs the physical switch port. Is there any particular reason for > using one vs the other? Is there an industry best practice for this? > > Thanks, > > Jason From mike-nanog at tiedyenetworks.com Wed Jun 1 18:16:50 2016 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 1 Jun 2016 11:16:50 -0700 Subject: Verizon and Level3 DNS flush In-Reply-To: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> Message-ID: <574F2692.20606@tiedyenetworks.com> On 06/01/2016 10:59 AM, J?rgen Jaritsch wrote: > Dear NANOGers, > > is there anyone from Verizon and Level3 who can help me with DNS caching issue? We're running a global service for a customer and we had to change to NS IPs via Glue Records. At the moment at least Verizone and Level3 are caching old NS records. Looking for DNS admins out there. > > > Please contact me off- or on-list! > I totally understand the desire to just be able to go ask major operators for a courtesy cache flush, but there are ways to update dns and procedures to engage that can eliminate the underlaying causes of same. Not that everyone, including myself, is prefect or godly (or has their name in the rfc...!), but at the same time, it's a learning experience being offered to you and I hope that whatever hole you shot in your foot heals soon and hopefull you never have to make another one like it. Mike- From mark.tinka at seacom.mu Wed Jun 1 18:18:03 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jun 2016 20:18:03 +0200 Subject: Tracking traffic usage at router or switch port? In-Reply-To: References: Message-ID: <6889e6c1-7c22-d90d-ea65-9b219969afb8@seacom.mu> On 1/Jun/16 19:58, Jason Lee wrote: > NANOG Community, > > Typically where would you expect a service provider to monitor bandwidth > usage on your circuits? On the physical switch port interface or on the > vlan interface at the router? In some of the field testing I've been doing > there can be a difference in the bandwidth usage on the vlan interface at > the router vs the physical switch port. Is there any particular reason for > using one vs the other? Is there an industry best practice for this? We track both. Mark. From JJaritsch at anexia-it.com Wed Jun 1 18:24:52 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Wed, 1 Jun 2016 18:24:52 +0000 Subject: AW: Verizon and Level3 DNS flush In-Reply-To: <574F2692.20606@tiedyenetworks.com> References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> Message-ID: <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> Hi Mike, thanks for your (not so useful :)) answer ... I'm aware of things like TTL etc ... but the situation is that customer is receiving ~130gbit of DNS reflection attack to their original DNS and that's the reason why we had to move over to a new NS set. I'm not allowed to tell you the customers and/or project name but I guess many of you know them ... if you're reading Twitter or reddit you've probably recognized which global service is broken at the moment ... Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Mike Gesendet: Mittwoch, 01. Juni 2016 20:17 An: nanog at nanog.org Betreff: Re: Verizon and Level3 DNS flush On 06/01/2016 10:59 AM, J?rgen Jaritsch wrote: > Dear NANOGers, > > is there anyone from Verizon and Level3 who can help me with DNS caching issue? We're running a global service for a customer and we had to change to NS IPs via Glue Records. At the moment at least Verizone and Level3 are caching old NS records. Looking for DNS admins out there. > > > Please contact me off- or on-list! > I totally understand the desire to just be able to go ask major operators for a courtesy cache flush, but there are ways to update dns and procedures to engage that can eliminate the underlaying causes of same. Not that everyone, including myself, is prefect or godly (or has their name in the rfc...!), but at the same time, it's a learning experience being offered to you and I hope that whatever hole you shot in your foot heals soon and hopefull you never have to make another one like it. Mike- From mstorck at voipgate.com Wed Jun 1 19:16:08 2016 From: mstorck at voipgate.com (Marc Storck) Date: Wed, 1 Jun 2016 19:16:08 +0000 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: <046D8339-24D3-4A8C-BE4A-4D1A1097916A@voipgate.com> With BCP38 in mind, could therre be situations where Router R is not allowed to source packets with address A out of intergace C? I think that the possibility does exist. E.g. If interface A and C are upstream interfaces, router R may use an IP address from ISP A on interface A and an address from ISP C on interface C. Obviously BCP38 is not widely deployed but yet... Regards, Marc > On 31 mai 2016, at 07:05, Randy Bush wrote: > > rfc1812 says > > 4.3.2.4 ICMP Message Source Address > > Except where this document specifies otherwise, the IP source address > in an ICMP message originated by the router MUST be one of the IP > addresses associated with the physical interface over which the ICMP > message is transmitted. If the interface has no IP addresses > associated with it, the router's router-id (see Section [5.2.5]) is > used instead. > > some folk have interpreted this to mean that, if a router R has three > interfaces > > .-----------------. > | | > | B |--------- D > S ---------| A R | > | C |--------- (toward S) > | | > `-----------------' > > if the source of a traceroute from S toward D with TTL to expire on R, > and R's FIB wants to exit via C to get back to S (yes, virginia, the > internet is highly asymmetric), the source address of the time exceeded > message should be C. > > of course, simpletons such as i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. > > ras's preso, > https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf > page 10 illustrates this issue with rfc1812 > > cursory research and talking with C & J seem to indicate that they do > what i want not what some folk have interpreted 1812 to mean. at least > on some models. > > is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how > common is it? > > randy From octalnanog at alvarezp.org Wed Jun 1 21:03:41 2016 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Wed, 1 Jun 2016 14:03:41 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: <574DB70A.2010209@alvarezp.org> Message-ID: <574F4DAD.9040103@alvarezp.org> On 05/31/2016 11:22 AM, William Herrin wrote: >> I'm not sure if you mean that, if sent through C it should have the >> source addres of A, or that it should actually be sent through A >> regardless of the routing table (which sounds better to me). > > That doesn't make sense. There may be multiple next hops out A. If the > next hop in the FIB is out C, how would the router pick the next hop > to send to out A? Back to the physical address that sent the TTL-offending packet. > Anyway, Randy's comment was about source address selection, not > routing. With the packet coming from S into interface A, he'd prefer > that the ICMP error message be sourced from the IP address assigned to > A, not the IP address assigned to C or R. Thanks. From hugo at slabnet.com Wed Jun 1 21:08:37 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 1 Jun 2016 14:08:37 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <574F4DAD.9040103@alvarezp.org> References: <574DB70A.2010209@alvarezp.org> <574F4DAD.9040103@alvarezp.org> Message-ID: <20160601210837.GG6467@bamboo.slabnet.com> On Wed 2016-Jun-01 14:03:41 -0700, Octavio Alvarez wrote: >On 05/31/2016 11:22 AM, William Herrin wrote: >>> I'm not sure if you mean that, if sent through C it should have the >>> source addres of A, or that it should actually be sent through A >>> regardless of the routing table (which sounds better to me). >> >> That doesn't make sense. There may be multiple next hops out A. If the >> next hop in the FIB is out C, how would the router pick the next hop >> to send to out A? > >Back to the physical address that sent the TTL-offending packet. Which comes back to my question: What guarantees do you have that the device at that physical address (so, adjacent off of R's interface A) has a valid route for S, and that the route does not simply point back to R? >> Anyway, Randy's comment was about source address selection, not >> routing. With the packet coming from S into interface A, he'd prefer >> that the ICMP error message be sourced from the IP address assigned to >> A, not the IP address assigned to C or R. > >Thanks. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From octalnanog at alvarezp.org Wed Jun 1 21:14:26 2016 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Wed, 1 Jun 2016 14:14:26 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <20160531165200.GE6467@bamboo.slabnet.com> References: <574DB70A.2010209@alvarezp.org> <20160531165200.GE6467@bamboo.slabnet.com> Message-ID: <574F5032.6070209@alvarezp.org> On 05/31/2016 09:52 AM, Hugo Slabbert wrote: >> I'm not sure if you mean that, if sent through C it should have the >> source addres of A, or that it should actually be sent through A >> regardless of the routing table (which sounds better to me). > > How is the latter better? What guarantees are there that the > adjacent L3 device on R's interface A has a route for S [?] Consider this scenario: .-------. ISP1ADDR/30 { D---|B R A|---------------[ ISP 1 ]---- { `---C---' { |(towards S) { S is someplace | { over this side .----F---. { ---|G R2 H|--------------*[ ISP 2 ]---- { `--------' ISP2ADDR/30 { In the asterisk there is BCP38 filtering which won't allow ISPADDR/30. The packet expired on R incoming from ISP 1. Under Randy's scenario, the TTL-exceeded packet would get dropped by ISP2. The only way for the packet to get through is to follow RFC 1812, or to send it back through A using A's address (this follows RFC 1812 4.3.2.4). > and if such a route exists that it doesn't simply point at R? If the route points back to R, then R just forwards it using the routing table as with any packet. Best regards. From bill at herrin.us Wed Jun 1 21:42:02 2016 From: bill at herrin.us (William Herrin) Date: Wed, 1 Jun 2016 17:42:02 -0400 Subject: rfc 1812 third party address on traceroute In-Reply-To: <574F4DAD.9040103@alvarezp.org> References: <574DB70A.2010209@alvarezp.org> <574F4DAD.9040103@alvarezp.org> Message-ID: On Wed, Jun 1, 2016 at 5:03 PM, Octavio Alvarez wrote: > On 05/31/2016 11:22 AM, William Herrin wrote: >>> I'm not sure if you mean that, if sent through C it should have the >>> source addres of A, or that it should actually be sent through A >>> regardless of the routing table (which sounds better to me). >> >> That doesn't make sense. There may be multiple next hops out A. If the >> next hop in the FIB is out C, how would the router pick the next hop >> to send to out A? > > Back to the physical address that sent the TTL-offending packet. Howdy, That would be an example of a layer violation. The only guarantee that layer 2 makes to layer 3 is that if you tell the layer 2 stack the layer 3 next hop address on that lan segment, it can figure out where to deliver your packet (via arp on ethernet, but this is not necessarily true of other layer 2s). Long story short, layer violations break things. Indeed, many of BGP's thornier problems and the mess that is mobile routing can all be traced to a single layer violation that TCP commits on IP. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Wed Jun 1 21:45:41 2016 From: bill at herrin.us (William Herrin) Date: Wed, 1 Jun 2016 17:45:41 -0400 Subject: rfc 1812 third party address on traceroute In-Reply-To: <046D8339-24D3-4A8C-BE4A-4D1A1097916A@voipgate.com> References: <046D8339-24D3-4A8C-BE4A-4D1A1097916A@voipgate.com> Message-ID: On Wed, Jun 1, 2016 at 3:16 PM, Marc Storck wrote: >> .-----------------. >> | | >> | B |--------- D >> S ---------| A R | >> | C |--------- (toward S) >> | | >> `-----------------' >> > With BCP38 in mind, could there be situations > where Router R is not allowed to source packets > with address A out of interface C? Hi Marc, I think you're right. Address A in a /30 from ISP A. ISP C accepts source addresses from your /24 but not the A /30. So if the router does not follow the RFC (sends an ICMP packet out C with a source address from A), typical asynchronous routing can result in black-holding the ICMP error message. You've hit on a good reason to follow the RFC by default instead of doing what Randy wants. ;) -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mstorck at voipgate.com Wed Jun 1 21:50:28 2016 From: mstorck at voipgate.com (Marc Storck) Date: Wed, 1 Jun 2016 21:50:28 +0000 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: <046D8339-24D3-4A8C-BE4A-4D1A1097916A@voipgate.com>, Message-ID: I'm not saying anyone is wrong here. I merely want to point out eventual incompatabilities. So please don't get me wrong. Regards, Marc > On 1 juin 2016, at 23:46, William Herrin wrote: > > On Wed, Jun 1, 2016 at 3:16 PM, Marc Storck wrote: >>> .-----------------. >>> | | >>> | B |--------- D >>> S ---------| A R | >>> | C |--------- (toward S) >>> | | >>> `-----------------' >> With BCP38 in mind, could there be situations >> where Router R is not allowed to source packets >> with address A out of interface C? > > Hi Marc, > > I think you're right. Address A in a /30 from ISP A. ISP C accepts > source addresses from your /24 but not the A /30. So if the router > does not follow the RFC (sends an ICMP packet out C with a source > address from A), typical asynchronous routing can result in > black-holding the ICMP error message. > > You've hit on a good reason to follow the RFC by default instead of > doing what Randy wants. ;) > > -Bill > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From peterl at standingwave.org Wed Jun 1 22:17:33 2016 From: peterl at standingwave.org (Peter Loron) Date: Wed, 1 Jun 2016 15:17:33 -0700 Subject: Google GeoIP issue Message-ID: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> Hello folks. An address we use is not identified as being in the correct location by Google. Can someone from their NOC reach out off-list? Thanks. Sent from my iPhone From paras at protrafsolutions.com Wed Jun 1 22:26:21 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Wed, 1 Jun 2016 18:26:21 -0400 Subject: Google GeoIP issue In-Reply-To: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> References: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> Message-ID: We had the same issue, there's a form you can fill out on Google's site if you visit the homepage from one of the IPs in question. However, I don't remember the exact link. On Wed, Jun 1, 2016 at 6:17 PM, Peter Loron wrote: > Hello folks. An address we use is not identified as being in the correct > location by Google. Can someone from their NOC reach out off-list? > > Thanks. > > > Sent from my iPhone > -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation From cboyd at gizmopartners.com Wed Jun 1 22:28:54 2016 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 1 Jun 2016 17:28:54 -0500 Subject: Google GeoIP issue In-Reply-To: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> References: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> Message-ID: <64098D7A-E438-461D-A5B8-70752D11EA5E@gizmopartners.com> I too am having a similar problem. Used the remediation link at https://support.google.com/websearch/contact/ip and it?s only partially corrected. Users who log in to Google are seeing the US google.com page after they select the preferred country and languate, but everyone else is still getting google.ae. 208.81.245.226 is in Austin, TX. ?Chris > On Jun 1, 2016, at 5:17 PM, Peter Loron wrote: > > Hello folks. An address we use is not identified as being in the correct location by Google. Can someone from their NOC reach out off-list? > > Thanks. > > > Sent from my iPhone > From matthew at matthew.at Thu Jun 2 03:27:00 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 02 Jun 2016 03:27:00 +0000 Subject: Netflix VPN detection - actual engineer needed Message-ID: Every device in my house is blocked from Netflix this evening due to their new "VPN blocker". My house is on my own IP space, and the outside of the NAT that the family devices are on is 198.202.199.254, announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house should show that I'm no farther away than Santa Cruz, CA as microwaves fly. Unfortunately, when one calls Netflix support to talk about this, the only response is to say "call your ISP and have them turn off the VPN software they've added to your account". And they absolutely refuse to escalate. Even if you tell them that you are essentially your own ISP. So... where's the Netflix network engineer on the list who all of us can send these issues to directly? Matthew Kaufman From pete at fiberphone.co.nz Thu Jun 2 03:39:30 2016 From: pete at fiberphone.co.nz (Pete Mundy) Date: Thu, 2 Jun 2016 15:39:30 +1200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <7A3AA6D7-2244-4A02-B63F-5A749BA6488F@fiberphone.co.nz> Maybe it's time to use some reverse-psychology and try connecting through a VPN provider? ;-)  Pete Ps, I hope you succeed in getting an answer from an actual engineer. But if I were a betting man... > On 2/06/2016, at 3:27 pm, Matthew Kaufman wrote: > > Every device in my house is blocked from Netflix this evening due to their new "VPN blocker". My house is on my own IP space, and the outside of the NAT that the family devices are on is 198.202.199.254, announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house should show that I'm no farther away than Santa Cruz, CA as microwaves fly. > > Unfortunately, when one calls Netflix support to talk about this, the only response is to say "call your ISP and have them turn off the VPN software they've added to your account". And they absolutely refuse to escalate. Even if you tell them that you are essentially your own ISP. > > So... where's the Netflix network engineer on the list who all of us can send these issues to directly? > > Matthew Kaufman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From matthew at matthew.at Thu Jun 2 03:41:54 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 02 Jun 2016 03:41:54 +0000 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: Message-ID: Turns out it has nothing to do with my IPv4 connectivity. Neither of my ISPs has native IPv6 connectivity, so both require tunnels (one of them to HE.net, one to the ISPs own tunnel broker), and both appear to be detected as a non-permitted VPN. As an early IPv6 adopter, I've had IPv6 on all my household devices for years now. So after having to temporarily turn off IPv6 at my desktop to fix issues with pay.gov (FCC license payments), and issues with various other things, and then remember to turn it back on again... I now have the reason I've been waiting for to turn it off globally for the whole house. Thanks Netflix for helping move us forward here. Matthew Kaufman ps. Would still be helpful if the support techs could tell from the error codes that the denied VPN is an IPv6 tunnel ------ Original Message ------ From: "Matthew Kaufman" To: "NANOG" Sent: 6/1/2016 8:27:00 PM Subject: Netflix VPN detection - actual engineer needed >Every device in my house is blocked from Netflix this evening due to >their new "VPN blocker". My house is on my own IP space, and the >outside of the NAT that the family devices are on is 198.202.199.254, >announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >house should show that I'm no farther away than Santa Cruz, CA as >microwaves fly. > >Unfortunately, when one calls Netflix support to talk about this, the >only response is to say "call your ISP and have them turn off the VPN >software they've added to your account". And they absolutely refuse to >escalate. Even if you tell them that you are essentially your own ISP. > >So... where's the Netflix network engineer on the list who all of us >can send these issues to directly? > >Matthew Kaufman From fergdawgster at mykolab.com Thu Jun 2 03:47:59 2016 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 1 Jun 2016 20:47:59 -0700 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: References: Message-ID: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There is an epic lesson here. I'm just not sure what it is. :-) - - ferg On 6/1/2016 8:41 PM, Matthew Kaufman wrote: > Turns out it has nothing to do with my IPv4 connectivity. Neither > of my ISPs has native IPv6 connectivity, so both require tunnels > (one of them to HE.net, one to the ISPs own tunnel broker), and > both appear to be detected as a non-permitted VPN. As an early IPv6 > adopter, I've had IPv6 on all my household devices for years now. > > So after having to temporarily turn off IPv6 at my desktop to fix > issues with pay.gov (FCC license payments), and issues with > various other things, and then remember to turn it back on again... > I now have the reason I've been waiting for to turn it off globally > for the whole house. > > Thanks Netflix for helping move us forward here. > > Matthew Kaufman > > ps. Would still be helpful if the support techs could tell from > the error codes that the denied VPN is an IPv6 tunnel > > ------ Original Message ------ From: "Matthew Kaufman" > To: "NANOG" Sent: 6/1/2016 > 8:27:00 PM Subject: Netflix VPN detection - actual engineer needed > >> Every device in my house is blocked from Netflix this evening due >> to their new "VPN blocker". My house is on my own IP space, and >> the outside of the NAT that the family devices are on is >> 198.202.199.254, announced by AS 11994. A simple ping from >> Netflix HQ in Los Gatos to my house should show that I'm no >> farther away than Santa Cruz, CA as microwaves fly. >> >> Unfortunately, when one calls Netflix support to talk about this, >> the only response is to say "call your ISP and have them turn off >> the VPN software they've added to your account". And they >> absolutely refuse to escalate. Even if you tell them that you are >> essentially your own ISP. >> >> So... where's the Netflix network engineer on the list who all of >> us can send these issues to directly? >> >> Matthew Kaufman > > - -- Paul Ferguson ICEBRG.io PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAldPrG8ACgkQKJasdVTchbJ8lQEAgJrSwiKkyUcvoIoVp5gIBmkV Dp1JqLdUtNphHTx4n2QA/jILspE24/BuY71211CSNqb3d5l9PH/udxyF2rN79ddL =DLns -----END PGP SIGNATURE----- From woody at pch.net Thu Jun 2 03:55:16 2016 From: woody at pch.net (Bill Woodcock) Date: Thu, 2 Jun 2016 06:55:16 +0300 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <09498419-8F91-4F41-8E21-325225B894B8@pch.net> > On Jun 2, 2016, at 6:27 AM, Matthew Kaufman wrote: > > Every device in my house is blocked from Netflix this evening due to their new "VPN blocker". My house is on my own IP space, and the outside of the NAT that the family devices are on is 198.202.199.254, announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house should show that I'm no farther away than Santa Cruz, CA as microwaves fly. > > Unfortunately, when one calls Netflix support to talk about this, the only response is to say "call your ISP and have them turn off the VPN software they've added to your account". And they absolutely refuse to escalate. Even if you tell them that you are essentially your own ISP. > > So... where's the Netflix network engineer on the list who all of us can send these issues to directly? > > Matthew Kaufman Matthew, haven?t you told your ISP to stop using the dreaded 198 space? Everyone knows those are magic addresses that belong to NetGear! :-) -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From josh at imaginenetworksllc.com Thu Jun 2 04:03:47 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 2 Jun 2016 00:03:47 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <09498419-8F91-4F41-8E21-325225B894B8@pch.net> References: <09498419-8F91-4F41-8E21-325225B894B8@pch.net> Message-ID: Have you tried cdnetops at netflix.com ? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 1, 2016 11:56 PM, "Bill Woodcock" wrote: > > > On Jun 2, 2016, at 6:27 AM, Matthew Kaufman wrote: > > > > Every device in my house is blocked from Netflix this evening due to > their new "VPN blocker". My house is on my own IP space, and the outside of > the NAT that the family devices are on is 198.202.199.254, announced by AS > 11994. A simple ping from Netflix HQ in Los Gatos to my house should show > that I'm no farther away than Santa Cruz, CA as microwaves fly. > > > > Unfortunately, when one calls Netflix support to talk about this, the > only response is to say "call your ISP and have them turn off the VPN > software they've added to your account". And they absolutely refuse to > escalate. Even if you tell them that you are essentially your own ISP. > > > > So... where's the Netflix network engineer on the list who all of us can > send these issues to directly? > > > > Matthew Kaufman > > Matthew, haven?t you told your ISP to stop using the dreaded 198 space? > Everyone knows those are magic addresses that belong to NetGear! :-) > > -Bill > > > > > From rdobbins at arbor.net Thu Jun 2 04:23:54 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 02 Jun 2016 11:23:54 +0700 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> References: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> Message-ID: <543225C0-18BC-4F42-A49C-4F28501D4803@arbor.net> On 2 Jun 2016, at 10:47, Paul Ferguson wrote: > There is an epic lesson here. I'm just not sure what it is. :-) That Netflix offering free streaming to everyone over IPv6 (after fixing their VPN detection) would be the most effective way to convince end-users to demand IPv6 service from their ISPs? ;> ----------------------------------- Roland Dobbins From hank at efes.iucc.ac.il Thu Jun 2 04:32:07 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 2 Jun 2016 07:32:07 +0300 Subject: Verizon and Level3 DNS flush In-Reply-To: <574F2692.20606@tiedyenetworks.com> References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> Message-ID: On 01/06/2016 21:16, Mike wrote: > > > On 06/01/2016 10:59 AM, J?rgen Jaritsch wrote: >> Dear NANOGers, >> >> is there anyone from Verizon and Level3 who can help me with DNS >> caching issue? We're running a global service for a customer and we >> had to change to NS IPs via Glue Records. At the moment at least >> Verizone and Level3 are caching old NS records. Looking for DNS >> admins out there. >> >> >> Please contact me off- or on-list! >> > > I totally understand the desire to just be able to go ask major > operators for a courtesy cache flush, but there are ways to update dns > and procedures to engage that can eliminate the underlaying causes of > same. Not that everyone, including myself, is prefect or godly (or has > their name in the rfc...!), but at the same time, it's a learning > experience being offered to you and I hope that whatever hole you shot > in your foot heals soon and hopefull you never have to make another > one like it. > > Mike- > Those "procedures" were attempted to be documented in an RFC: https://tools.ietf.org/html/draft-jabley-dnsop-flush-reqs-00 https://tools.ietf.org/html/draft-jabley-dnsop-dns-flush-00 Unfortunately, nothing ever came of it, so people are forced to post to NANOG pleading for help. -Hank From randy at psg.com Thu Jun 2 04:39:54 2016 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jun 2016 21:39:54 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <574DB70A.2010209@alvarezp.org> References: <574DB70A.2010209@alvarezp.org> Message-ID: >> .-----------------. >> | | >> | B |--------- D >> S ---------| A R | >> | C |--------- (toward S) >> | | >> `-----------------' >> >> of course, simpletons such as i would desire the source of the time >> exceeded message to be A. after all, this is the interface to which i >> sent the icmp with the TTL to expire. > > Do you mean the source address or the source interface? the source address > I'm not sure if you mean that, if sent through C it should have the > source addres of A, or that it should actually be sent through A > regardless of the routing table (which sounds better to me). not to me. i have kinda grown used to fibs randy From rdobbins at arbor.net Thu Jun 2 08:37:56 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Jun 2016 15:37:56 +0700 Subject: AW: Verizon and Level3 DNS flush In-Reply-To: <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> Message-ID: On Jun 2, 2016, at 1:24 AM, J?rgen Jaritsch wrote: > and that's the reason why we had to move over to a new NS set. Which the attackers (or their attack tools) will immediately discern, & shift their targeting accordingly. Playing games like this with addressing seldom, if ever, accomplishes anything useful in terms of successfully defending against DDoS attacks. ----------------------------------- Roland Dobbins From JJaritsch at anexia-it.com Thu Jun 2 08:42:10 2016 From: JJaritsch at anexia-it.com (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Thu, 2 Jun 2016 08:42:10 +0000 Subject: AW: AW: Verizon and Level3 DNS flush In-Reply-To: References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> Message-ID: Hi Roland, the difference between old and new DNS are way more capacity and extra DDoS protection ... it IS expected behavior that traffic will switch over to the new DNS. best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Roland Dobbins Gesendet: Donnerstag, 02. Juni 2016 10:38 An: nanog at nanog.org Betreff: Re: AW: Verizon and Level3 DNS flush On Jun 2, 2016, at 1:24 AM, J?rgen Jaritsch wrote: > and that's the reason why we had to move over to a new NS set. Which the attackers (or their attack tools) will immediately discern, & shift their targeting accordingly. Playing games like this with addressing seldom, if ever, accomplishes anything useful in terms of successfully defending against DDoS attacks. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Thu Jun 2 09:30:23 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Jun 2016 16:30:23 +0700 Subject: AW: AW: Verizon and Level3 DNS flush In-Reply-To: References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> Message-ID: <6EA4E0DF-B99F-4651-B23D-2FBFB5677B77@arbor.net> On Jun 2, 2016, at 3:42 PM, J?rgen Jaritsch wrote: > it IS expected behavior that traffic will switch over to the new DNS. Altering routing and/or adding capacity/capabilities to the existing infrastructure is generally better, whenever possible, due to the cache-flushing challenges you're now experiencing. Sometimes it isn't possible, of course. ----------------------------------- Roland Dobbins From JJaritsch at anexia-it.com Thu Jun 2 10:06:30 2016 From: JJaritsch at anexia-it.com (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Thu, 2 Jun 2016 10:06:30 +0000 Subject: AW: AW: AW: Verizon and Level3 DNS flush In-Reply-To: <6EA4E0DF-B99F-4651-B23D-2FBFB5677B77@arbor.net> References: <694015c4a00b496aa7b779be60faea81@anx-i-dag02.anx.local> <574F2692.20606@tiedyenetworks.com> <4787ae6e960746e0b11cab109d5fdaf8@anx-i-dag02.anx.local> <6EA4E0DF-B99F-4651-B23D-2FBFB5677B77@arbor.net> Message-ID: <0ab685867fa54af5a1a2de610729f48c@anx-i-dag02.anx.local> > Altering routing and/or adding capacity/capabilities to the existing infrastructure is generally better Yes ... but as mentioned in one of the off-list replies: the original DNS are from a 3rd party and they had no chance to expand resources ... best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Roland Dobbins Gesendet: Donnerstag, 02. Juni 2016 11:30 An: nanog at nanog.org Betreff: Re: AW: AW: Verizon and Level3 DNS flush On Jun 2, 2016, at 3:42 PM, J?rgen Jaritsch wrote: > it IS expected behavior that traffic will switch over to the new DNS. Altering routing and/or adding capacity/capabilities to the existing infrastructure is generally better, whenever possible, due to the cache-flushing challenges you're now experiencing. Sometimes it isn't possible, of course. ----------------------------------- Roland Dobbins From mcole.mailinglists at gmail.com Thu Jun 2 13:19:22 2016 From: mcole.mailinglists at gmail.com (Maxwell Cole) Date: Thu, 2 Jun 2016 09:19:22 -0400 Subject: Google GeoIP issue In-Reply-To: <64098D7A-E438-461D-A5B8-70752D11EA5E@gizmopartners.com> References: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> <64098D7A-E438-461D-A5B8-70752D11EA5E@gizmopartners.com> Message-ID: <6CA1AC26-D729-4A96-9143-BAEC327D9564@gmail.com> Heya, Im in the same boat if anyone from google wants to be a dear and help out. Cheers, > On Jun 1, 2016, at 6:28 PM, Chris Boyd wrote: > > I too am having a similar problem. Used the remediation link at https://support.google.com/websearch/contact/ip and it?s only partially corrected. Users who log in to Google are seeing the US google.com page after they select the preferred country and languate, but everyone else is still getting google.ae. 208.81.245.226 is in Austin, TX. > > ?Chris > >> On Jun 1, 2016, at 5:17 PM, Peter Loron wrote: >> >> Hello folks. An address we use is not identified as being in the correct location by Google. Can someone from their NOC reach out off-list? >> >> Thanks. >> >> >> Sent from my iPhone >> > From cb.list6 at gmail.com Thu Jun 2 14:47:20 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Jun 2016 07:47:20 -0700 Subject: IPv6 is better than ipv4 Message-ID: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html Wherein akamai explains a detailed study showing ipv6 is "well over 10%" faster than ipv4 on mobile, and they reference corroborating studies from Linkedin and Facebook. Fair to ask your business 1) does mobile performance matter 2) are you taking advantage of this 10% page load speedup that ipv6 provides? From morrowc.lists at gmail.com Thu Jun 2 15:39:26 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jun 2016 11:39:26 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 10:47 AM, Ca By wrote: > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > Wherein akamai explains a detailed study showing ipv6 is "well > over 10%" faster than ipv4 on mobile, and they reference corroborating > studies from Linkedin and Facebook. > > Fair to ask your business 1) does mobile performance matter 2) are you > taking advantage of this 10% page load speedup that ipv6 provides? > ?srs question: "What percentage of the mobile world prefers v6 over v4?" I ask because perhaps the market for your app is such that v6 is actually a hinderance to the userbase... (or is slower in your market) Are there more holistic studies about this?? From josh at imaginenetworksllc.com Thu Jun 2 15:42:53 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 2 Jun 2016 11:42:53 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: Just a thought - ipv4 includes older more rural connections such as 1M DSL out in the sticks. That weighs the average connection time down. v6 being capable on modern 4G wireless and fiber connections makes the average faster. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Jun 2, 2016 at 11:39 AM, Christopher Morrow wrote: > On Thu, Jun 2, 2016 at 10:47 AM, Ca By wrote: > > > > > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > > > Wherein akamai explains a detailed study showing ipv6 is "well > > over 10%" faster than ipv4 on mobile, and they reference corroborating > > studies from Linkedin and Facebook. > > > > Fair to ask your business 1) does mobile performance matter 2) are you > > taking advantage of this 10% page load speedup that ipv6 provides? > > > > ?srs question: "What percentage of the mobile world prefers v6 over v4?" > > I ask because perhaps the market for your app is such that v6 is actually a > hinderance to the userbase... (or is slower in your market) > > Are there more holistic studies about this?? > From nwarren at barryelectric.com Thu Jun 2 15:46:58 2016 From: nwarren at barryelectric.com (Nicholas Warren) Date: Thu, 2 Jun 2016 15:46:58 +0000 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: CenturyTel in this area provides IPv6 to DSL customers. Thank you, - Nich > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman > Sent: Thursday, June 2, 2016 10:43 AM > To: Christopher Morrow > Cc: nanog at nanog.org > Subject: Re: IPv6 is better than ipv4 > > Just a thought - ipv4 includes older more rural connections such as 1M > DSL out in the sticks. That weighs the average connection time down. > v6 being capable on modern 4G wireless and fiber connections makes the > average faster. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Thu, Jun 2, 2016 at 11:39 AM, Christopher Morrow > > wrote: > > > On Thu, Jun 2, 2016 at 10:47 AM, Ca By wrote: > > > > > > > > > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile- > networ > > ks-why-and-how.html > > > > > > Wherein akamai explains a detailed study showing ipv6 is "well over > > > 10%" faster than ipv4 on mobile, and they reference corroborating > > > studies from Linkedin and Facebook. > > > > > > Fair to ask your business 1) does mobile performance matter 2) are > > > you taking advantage of this 10% page load speedup that ipv6 > provides? > > > > > > > ?srs question: "What percentage of the mobile world prefers v6 over > v4?" > > > > I ask because perhaps the market for your app is such that v6 is > > actually a hinderance to the userbase... (or is slower in your > market) > > > > Are there more holistic studies about this?? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: not available URL: From cb.list6 at gmail.com Thu Jun 2 16:13:56 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Jun 2016 09:13:56 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: On Thursday, June 2, 2016, Josh Luthman wrote: > Just a thought - ipv4 includes older more rural connections such as 1M DSL > out in the sticks. That weighs the average connection time down. v6 being > capable on modern 4G wireless and fiber connections makes the average > faster. > > > Akamai, linkedin, and facebook are not lightweights when it comes to data analysis. Meaning, they know about selection basis. I'll also mention that google has v6 as well. FTFA, Akamai states they isolated dual-stack iphones on vzw and ran parallel RUM v4 and v6 tests. I believe FB did the same thing and presented the data at nanog 64 CB > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Thu, Jun 2, 2016 at 11:39 AM, Christopher Morrow < > morrowc.lists at gmail.com > > wrote: > >> On Thu, Jun 2, 2016 at 10:47 AM, Ca By > > wrote: >> >> > >> > >> https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html >> > >> > Wherein akamai explains a detailed study showing ipv6 is "well >> > over 10%" faster than ipv4 on mobile, and they reference corroborating >> > studies from Linkedin and Facebook. >> > >> > Fair to ask your business 1) does mobile performance matter 2) are you >> > taking advantage of this 10% page load speedup that ipv6 provides? >> > >> >> ?srs question: "What percentage of the mobile world prefers v6 over v4?" >> >> I ask because perhaps the market for your app is such that v6 is actually >> a >> hinderance to the userbase... (or is slower in your market) >> >> Are there more holistic studies about this?? >> > > From dcorbe at hammerfiber.com Thu Jun 2 16:23:13 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Thu, 2 Jun 2016 12:23:13 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> > On Jun 2, 2016, at 12:13 PM, Ca By wrote: > > On Thursday, June 2, 2016, Josh Luthman wrote: > >> Just a thought - ipv4 includes older more rural connections such as 1M DSL >> out in the sticks. That weighs the average connection time down. v6 being >> capable on modern 4G wireless and fiber connections makes the average >> faster. >> >> >> > Akamai, linkedin, and facebook are not lightweights when it comes to data > analysis. Meaning, they know about selection basis. I'll also mention > that google has v6 as well. > > FTFA, Akamai states they isolated dual-stack iphones on vzw and ran > parallel RUM v4 and v6 tests. I believe FB did the same thing and > presented the data at nanog 64 > > CB > Just an ancillary thought. Maybe we should let people believe that IPv6 is faster than IPv4 even if objectively that isn?t true. Perhaps that will help speed along the adoption process. From rubensk at gmail.com Thu Jun 2 16:32:29 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 2 Jun 2016 13:32:29 -0300 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 11:47 AM, Ca By wrote: > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > Wherein akamai explains a detailed study showing ipv6 is "well > over 10%" faster than ipv4 on mobile, and they reference corroborating > studies from Linkedin and Facebook. > Says the company that consistently refused to dual-stack its customers by default... Rubens From morrowc.lists at gmail.com Thu Jun 2 16:41:33 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jun 2016 12:41:33 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> Message-ID: On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe wrote: > Maybe we should let people believe that IPv6 is faster than IPv4 even if > objectively that isn?t true. Perhaps that will help speed along the > adoption process. ?do we REALLY think it's still just /marketing problem/ that keeps v6 deployment on the slow-boat?? From cb.list6 at gmail.com Thu Jun 2 16:55:40 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Jun 2016 09:55:40 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> Message-ID: On Thursday, June 2, 2016, Christopher Morrow wrote: > > On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe > wrote: > >> Maybe we should let people believe that IPv6 is faster than IPv4 even if >> objectively that isn?t true. Perhaps that will help speed along the >> adoption process. > > > ?do we REALLY think it's still just /marketing problem/ that keeps v6 > deployment on the slow-boat?? > > YMMV, but the majority of my customers are ipv6. And for those customers with ipv6, 73% of their traffic is e2e IPv6. I agree that there are many dark corners of Santa Cruz without IPv6, but the story is: the whales of content and eyeballs are on IPv6, and it is cheaper (no cgn) and faster (RUM data) than the ipv4 alternative. Does it really matter what single digit % of Alexa 1M has a AAAA? From morrowc.lists at gmail.com Thu Jun 2 17:07:23 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jun 2016 13:07:23 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> Message-ID: On Thu, Jun 2, 2016 at 12:55 PM, Ca By wrote: > > > On Thursday, June 2, 2016, Christopher Morrow > wrote: > >> >> On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe >> wrote: >> >>> Maybe we should let people believe that IPv6 is faster than IPv4 even if >>> objectively that isn?t true. Perhaps that will help speed along the >>> adoption process. >> >> >> ?do we REALLY think it's still just /marketing problem/ that keeps v6 >> deployment on the slow-boat?? >> >> > YMMV, but the majority of my customers are ipv6. And for those customers > with ipv6, 73% of their traffic is e2e IPv6. > > ?I understand that tmo's (us at least) network is v6 native to the handset... my question was really trying to point out that even if tmo is 100M customers, there are ~3x that on sprint/vz/att/etc ... so just in the US is 25% repreesntative? and outside the US what does the mobile address family spread look like?? then, what if the resource being accessed to by the mobile users in zimbabwe are local to zimbabwe and there's only ipv4 versions of that mobile service... the reasons to go v6 on both sides aren't as clear. (to me) > I agree that there are many dark corners of Santa Cruz without IPv6, but > the story is: the whales of content and eyeballs are on IPv6, and it is > cheaper (no cgn) and faster (RUM data) than the ipv4 alternative. > > ?I get why things look better in the cases of FB/TMO (as one example)... but selling 'you should ipv6 because FB/TMO is better!' ?isn't really true all ways. > Does it really matter what single digit % of Alexa 1M has a AAAA? > ?:) I have no idea...? From nanog at ics-il.net Thu Jun 2 17:17:59 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Jun 2016 12:17:59 -0500 (CDT) Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> Message-ID: <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Yes. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "Daniel Corbe" Cc: nanog at nanog.org Sent: Thursday, June 2, 2016 11:41:33 AM Subject: Re: IPv6 is better than ipv4 On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe wrote: > Maybe we should let people believe that IPv6 is faster than IPv4 even if > objectively that isn?t true. Perhaps that will help speed along the > adoption process. do we REALLY think it's still just /marketing problem/ that keeps v6 deployment on the slow-boat? From morrowc.lists at gmail.com Thu Jun 2 17:31:43 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jun 2016 13:31:43 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett wrote: > Yes. > > ?REALLY??? I mean REALLY? people that operate networks haven't haven't had beaten into their heads: 1) cgn is expensive 2) there is no more ipv4 (not large amounts for large deployments of new thingies) 3) there really isn't much else except the internet for global networking and reachabilty 4) ipv6 'works' on almost all gear you'd deploy in your network and content side folks haven't had beaten into their heads: 1) ipv6 is where the network is going, do it now so you aren't caught with your pants (proverbial!) down 2) more and more customers are going to have ipv6 and not NAT'd ipv4... you can better target, better identify and better service v6 vs v4 users?. 3) adding ipv6 transport really SHOULD be as simple as adding a AAAA I figure at this point, in 2016, the reasons aren't "marketing" but either: a) turning the ship is hard (vz's continual lack of v6 on wireline services...) b) can't spend the opex/capex while keeping the current ship afloat c) meh I can't see that 'marketing' is really going to matter... I mean, if you haven't gotten the message now: http://i.imgur.com/8vZOU0T.gif > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Daniel Corbe" > Cc: nanog at nanog.org > Sent: Thursday, June 2, 2016 11:41:33 AM > Subject: Re: IPv6 is better than ipv4 > > On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe > wrote: > > > Maybe we should let people believe that IPv6 is faster than IPv4 even if > > objectively that isn?t true. Perhaps that will help speed along the > > adoption process. > > > do we REALLY think it's still just /marketing problem/ that keeps v6 > deployment on the slow-boat? > > From nanog at ics-il.net Thu Jun 2 17:38:46 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Jun 2016 12:38:46 -0500 (CDT) Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: <815775958.4219.1464889122318.JavaMail.mhammett@ThunderFuck> I would be surprised if more than 10% - 20% of networks have received effective marketing on IPv6. Look at how many network operators that don't "get" basic network security alerts like "There is a long since patched vulnerability being actively exploited on the Internet right now. Your equipment will reset to default in 18.5 hours of infection. Please patch now." Equipment resetting to default is a metric crap ton more serious than IPv6 implementation and people don't take that seriously. Think outside of the NANOG bubble. (I *REALLY* hate the way this list replies to the individual and not the list... and doesn't have a bracketed name in the subject.) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "Mike Hammett" Cc: "nanog list" Sent: Thursday, June 2, 2016 12:31:43 PM Subject: Re: IPv6 is better than ipv4 On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett < nanog at ics-il.net > wrote: Yes. REALLY??? I mean REALLY? people that operate networks haven't haven't had beaten into their heads: 1) cgn is expensive 2) there is no more ipv4 (not large amounts for large deployments of new thingies) 3) there really isn't much else except the internet for global networking and reachabilty 4) ipv6 'works' on almost all gear you'd deploy in your network and content side folks haven't had beaten into their heads: 1) ipv6 is where the network is going, do it now so you aren't caught with your pants (proverbial!) down 2) more and more customers are going to have ipv6 and not NAT'd ipv4... you can better target, better identify and better service v6 vs v4 users?. 3) adding ipv6 transport really SHOULD be as simple as adding a AAAA I figure at this point, in 2016, the reasons aren't "marketing" but either: a) turning the ship is hard (vz's continual lack of v6 on wireline services...) b) can't spend the opex/capex while keeping the current ship afloat c) meh I can't see that 'marketing' is really going to matter... I mean, if you haven't gotten the message now: http://i.imgur.com/8vZOU0T.gif
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" < morrowc.lists at gmail.com > To: "Daniel Corbe" < dcorbe at hammerfiber.com > Cc: nanog at nanog.org Sent: Thursday, June 2, 2016 11:41:33 AM Subject: Re: IPv6 is better than ipv4 On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe < dcorbe at hammerfiber.com > wrote: > Maybe we should let people believe that IPv6 is faster than IPv4 even if > objectively that isn?t true. Perhaps that will help speed along the > adoption process. do we REALLY think it's still just /marketing problem/ that keeps v6 deployment on the slow-boat?
From bicknell at ufp.org Thu Jun 2 18:05:54 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 2 Jun 2016 11:05:54 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: <20160602180554.GA18851@ussenterprise.ufp.org> Warning: Hat = Enterprise Network Admin Sarcasm = High In a message written on Thu, Jun 02, 2016 at 01:31:43PM -0400, Christopher Morrow wrote: > ?REALLY??? I mean REALLY? people that operate networks haven't haven't had > beaten into their heads: > 1) cgn is expensive Wazzat? Isn't the C for Carrier? So, not my problem. > 2) there is no more ipv4 (not large amounts for large deployments of new > thingies) I got a /24 from my provider years ago. I only use half of it. If we needed to economize we could probably go ahead and deploy name based virtual hosting, the server guys have talked about that for years. I can't imagine I will ever run out of IPv4. > 3) there really isn't much else except the internet for global networking > and reachabilty IPv4 currently has more reach than IPv6? Didn't you just tell me people aren't deploying IPv6. > 4) ipv6 'works' on almost all gear you'd deploy in your network I can't find it in the docs for our IBM Token Ring switch that connects the payroll mainframe to the ERP NEC box. That's our only critical application. > and content side folks haven't had beaten into their heads: > 1) ipv6 is where the network is going, do it now so you aren't caught > with your pants (proverbial!) down I thought all the providers were deploying that CGN thing so IPv4 kept working. They would never leave us high and dry, right? > 2) more and more customers are going to have ipv6 and not NAT'd ipv4... > you can better target, better identify and better service v6 vs v4 users?. I was told DNS64 fixed that problem, and carriers would have to deploy it as a transition strategy. > 3) adding ipv6 transport really SHOULD be as simple as adding a AAAA My IPAM software doesn't have AAAA support because I haven't bought a support contract for it for 10 years. Do I really need to buy new IPAM software? > I figure at this point, in 2016, the reasons aren't "marketing" but either: > a) turning the ship is hard (vz's continual lack of v6 on wireline > services...) > b) can't spend the opex/capex while keeping the current ship afloat > c) meh Actually it's more my boss has 100 "critical" initiatives and staff to do 20 of them, and IPv6 isn't even on the list. Our planning window is crisis to crisis, err, I mean quarter to quarter. Will my web site go down this quarter if I don't deploy it? Otherwise we can put that off. Sadly, I wish all these answers were some sort of carachture of reality, but I think they are too many folks reality. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From cb.list6 at gmail.com Thu Jun 2 18:20:27 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Jun 2016 11:20:27 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> Message-ID: On Thursday, June 2, 2016, Christopher Morrow wrote: > > > On Thu, Jun 2, 2016 at 12:55 PM, Ca By wrote: > >> >> >> On Thursday, June 2, 2016, Christopher Morrow >> wrote: >> >>> >>> On Thu, Jun 2, 2016 at 12:23 PM, Daniel Corbe >>> wrote: >>> >>>> Maybe we should let people believe that IPv6 is faster than IPv4 even >>>> if objectively that isn?t true. Perhaps that will help speed along the >>>> adoption process. >>> >>> >>> ?do we REALLY think it's still just /marketing problem/ that keeps v6 >>> deployment on the slow-boat?? >>> >>> >> YMMV, but the majority of my customers are ipv6. And for those customers >> with ipv6, 73% of their traffic is e2e IPv6. >> >> > ?I understand that tmo's (us at least) network is v6 native to the > handset... my question was really trying to point out that even if tmo is > 100M customers, there are ~3x that on sprint/vz/att/etc ... so just in the > US is 25% repreesntative? > > > Sprint, vzw, and at&t all have ipv6 enabled by default on many handsets. I believe the samsung s6 was the first to launch on all national carrier with v6 on by default > and outside the US what does the mobile address family spread look like?? > > Not sure, but v6 does live a dramatic life outside the US too http://labs.apnic.net/ipv6-measurement/AS/5/5/8/3/6/ > then, what if the resource being accessed to by the mobile users in > zimbabwe are local to zimbabwe and there's only ipv4 versions of that > mobile service... the reasons to go v6 on both sides aren't as clear. (to > me) > > Afrnic has v4, apnic does not. As with the Jio example in india, networks need to grow and they cannot do that well with v4. And, the things that make v4 slow in the USA likely apply elsewhere. > >> I agree that there are many dark corners of Santa Cruz without IPv6, but >> the story is: the whales of content and eyeballs are on IPv6, and it is >> cheaper (no cgn) and faster (RUM data) than the ipv4 alternative. >> >> > ?I get why things look better in the cases of FB/TMO (as one example)... > but selling 'you should ipv6 because FB/TMO is better!' ?isn't really true > all ways. > > Your network, your problem. The akamai / fb / linkedin data are just data points. If you are in the nanog region and want data to show up on mobiles, it is likely 10% faster if your server has v6. > > >> Does it really matter what single digit % of Alexa 1M has a AAAA? >> > > ?:) I have no idea...? > > From bill at herrin.us Thu Jun 2 18:57:54 2016 From: bill at herrin.us (William Herrin) Date: Thu, 2 Jun 2016 14:57:54 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett wrote: >> do we REALLY think it's still just /marketing problem/ that keeps v6 >> deployment on the slow-boat? > Yes. I have a confession: I don't use IPv6. I don't use IPv6 at home because: 1. My Verizon FiOS link does not support IPv6. 2. My Cox Cable Internet link does not support IPv6. 3. The colo I tunnel to in order to announce my addresses via BGP does not support IPv6. 4. IPv6 does not offer me enough value to pony up the $500 initial and $100/year ARIN fees I would have to pay in order to have parity with my IPv4 installation, at least not until my other vendors support it. I don't use IPv6 at work because: 1. My employer moved half of everything to the Amazon cloud. AWS does not support IPv6. 2. My employer moved the other half of everything to various software as a service vendors, none of whom implement IPv6. Marketing problem? If it won't work with -any- of the vendors I do business with, that's not a marketing problem. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cb.list6 at gmail.com Thu Jun 2 19:34:45 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Jun 2016 12:34:45 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: On Thursday, June 2, 2016, William Herrin wrote: > On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett > wrote: > >> do we REALLY think it's still just /marketing problem/ that keeps v6 > >> deployment on the slow-boat? > > Yes. > > I have a confession: I don't use IPv6. > > I don't use IPv6 at home because: > > 1. My Verizon FiOS link does not support IPv6. > 2. My Cox Cable Internet link does not support IPv6. > 3. The colo I tunnel to in order to announce my addresses via BGP does > not support IPv6. > 4. IPv6 does not offer me enough value to pony up the $500 initial and > $100/year ARIN fees I would have to pay in order to have parity with > my IPv4 installation, at least not until my other vendors support it. > > I don't use IPv6 at work because: > > 1. My employer moved half of everything to the Amazon cloud. AWS does > not support IPv6. > 2. My employer moved the other half of everything to various software > as a service vendors, none of whom implement IPv6. > > > Marketing problem? If it won't work with -any- of the vendors I do > business with, that's not a marketing problem. > > Regards, > Bill Herrin > > > Yes, the data shows your page loads will be 10% slower than other folks. I am sure you don't mind CB > -- > William Herrin ................ herrin at dirtside.com > bill at herrin.us > Owner, Dirtside Systems ......... Web: > From jeffm at iglou.com Thu Jun 2 19:37:18 2016 From: jeffm at iglou.com (Jeff McAdams) Date: Thu, 2 Jun 2016 15:37:18 -0400 (EDT) Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> Message-ID: <32916.64.6.220.221.1464896238.iglou@webmail.iglou.com> On Thu, June 2, 2016 13:31, Christopher Morrow wrote: > On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett wrote: >> Yes. >> > ???REALLY??? I mean REALLY? people that operate networks haven't haven't > had beaten into their heads: 1) cgn is expensive > 2) there is no more ipv4 (not large amounts for large deployments of new > thingies) 3) there really isn't much else except the internet for global > networking and reachabilty 4) ipv6 'works' on almost all gear you'd deploy > in your network (more, reasonably valid observations elided) Yes. I had a member of an account team for a networking vendor express extreme skepticism when discussing IP address plans and work I had done. When describing why I went with an IPv6 only solution for this setup, he responded, "Why not just get more IPv4 addresses? Just go back to IANA[sic] for more if you don't have enough already." OK, maybe it's not *just* marketing, but marketing (using the term broadly) is still a very large part of it. -- Jeff From job at ntt.net Thu Jun 2 19:41:38 2016 From: job at ntt.net (Job Snijders) Date: Thu, 2 Jun 2016 21:41:38 +0200 Subject: Bogon ASN Filter Policy Message-ID: <20160602194138.GM15096@57.rev.meerval.net> Dear fellow network operators, In July 2016, NTT Communications' Global IP Network AS2914 will deploy a new routing policy to block Bogon ASNs from its view of the default-free zone. This notification is provided as a courtesy to the network community at large. After the Bogon ASN filter policy has been deployed, AS 2914 will not accept route announcements from any eBGP neighbor which contains a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. The reasoning behind this policy is twofold: - Private or Reserved ASNs have no place in the public DFZ. Barring these from the DFZ helps improve accountability and dampen accidental exposure of internal routing artifacts. - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" in the DFZ is a either a misconfiguration or software issue. We are undertaking this effort to improve the quality of routing data as part of the global ecosystem. This should improve the security posture and provide additional certainty [1] to those undertaking network troubleshooting. Bogon ASNs are currently defined as following: 0 # Reserved RFC7607 23456 # AS_TRANS RFC6793 64496-64511 # Reserved for use in docs and code RFC5398 64512-65534 # Reserved for Private Use RFC6996 65535 # Reserved RFC7300 65536-65551 # Reserved for use in docs and code RFC5398 65552-131071 # Reserved 4200000000-4294967294 # Reserved for Private Use RFC6996 4294967295 # Reserved RFC7300 A current overview of what are considered Bogon ASNs is maintained at NTT's Routing Policies page [2]. The IANA Autonomous System Number Registry [3] is closely tracked and the NTT Bogon ASN definitions are updated accordingly. We encourage network operators to consider deploying similar policies. Configuration examples for various platforms can be found here [4]. NTT staff is monitoring current occurrences of Bogon ASNs in the routing system and reaching out to impacted parties on a weekly basis. Kind regards, Job Contact persons: Job Snijders , Jared Mauch , NTT Communications NOC References: [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml [4]: http://as2914.net/bogon_asns/configuration_examples.txt From morrowc.lists at gmail.com Thu Jun 2 19:45:30 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jun 2016 15:45:30 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: <32916.64.6.220.221.1464896238.iglou@webmail.iglou.com> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <32916.64.6.220.221.1464896238.iglou@webmail.iglou.com> Message-ID: On Thu, Jun 2, 2016 at 3:37 PM, Jeff McAdams wrote: > On Thu, June 2, 2016 13:31, Christopher Morrow wrote: > > On Thu, Jun 2, 2016 at 1:17 PM, Mike Hammett wrote: > > >> Yes. > >> > > ?REALLY??? I mean REALLY? people that operate networks haven't haven't > > had beaten into their heads: 1) cgn is expensive > > 2) there is no more ipv4 (not large amounts for large deployments of new > > thingies) 3) there really isn't much else except the internet for global > > networking and reachabilty 4) ipv6 'works' on almost all gear you'd > deploy > > in your network > > (more, reasonably valid observations elided) > > Yes. I had a member of an account team for a networking vendor express > extreme skepticism when discussing IP address plans and work I had done. > When describing why I went with an IPv6 only solution for this setup, he > responded, "Why not just get more IPv4 addresses? Just go back to > IANA[sic] for more if you don't have enough already." > > OK, maybe it's not *just* marketing, but marketing (using the term > broadly) is still a very large part of it. > > ?your example sounds like ignorance, not marketing.? From darin.steffl at mnwifi.com Thu Jun 2 20:45:33 2016 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Thu, 2 Jun 2016 15:45:33 -0500 Subject: craigslist.com admin In-Reply-To: References: Message-ID: Have been getting reports of the same thing. Went to the craigslist help forums where some people there decided to call us a fake ISP because we don't hand out publics to every customer. They were VERY rude and hopefully none of them were employees. They said our customers can't use craigslist if we don't hand publics to everyone. It didn't matter to them that we don't have enough IP's for every customer. I sent an email to some admin account someone recommended but haven't heard anything back yet. On Tue, May 31, 2016 at 3:07 PM, Dennis Burgess wrote: > Looking for a craigslist.com admin to connect with offlist about a block > :) > > [DennisBurgessSignature] > www.linktechs.net - 314-735-0270 x103 - > dmburgess at linktechs.net > > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook From adam.davenport at gtt.net Thu Jun 2 20:46:13 2016 From: adam.davenport at gtt.net (Adam Davenport) Date: Thu, 2 Jun 2016 16:46:13 -0400 Subject: Bogon ASN Filter Policy In-Reply-To: <20160602194138.GM15096@57.rev.meerval.net> References: <20160602194138.GM15096@57.rev.meerval.net> Message-ID: I personally applaud this effort as initiatives like this that help prevent the global propagation of Bogons and other "bad things" only serves to help us all. With that said, notice went out to potentially affected GTT / AS3257 customers this week that by the end of June we too will be filtering prefixes that contain any of the Bogon ASNs listed below in the in the as-path. I highly encourage other networks to follow suit, as again it only helps us all. Thanks Job for kicking this one off, and I look forward to others to doing the same! Adam Davenport / adam.davenport at gtt.net On 6/2/16 3:41 PM, Job Snijders wrote: > Dear fellow network operators, > > In July 2016, NTT Communications' Global IP Network AS2914 will deploy a > new routing policy to block Bogon ASNs from its view of the default-free > zone. This notification is provided as a courtesy to the network > community at large. > > After the Bogon ASN filter policy has been deployed, AS 2914 will not > accept route announcements from any eBGP neighbor which contains a Bogon > ASN anywhere in the AS_PATH or its atomic aggregate attribute. > > The reasoning behind this policy is twofold: > > - Private or Reserved ASNs have no place in the public DFZ. Barring > these from the DFZ helps improve accountability and dampen > accidental exposure of internal routing artifacts. > > - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" > in the DFZ is a either a misconfiguration or software issue. > > We are undertaking this effort to improve the quality of routing data as > part of the global ecosystem. This should improve the security posture > and provide additional certainty [1] to those undertaking network > troubleshooting. > > Bogon ASNs are currently defined as following: > > 0 # Reserved RFC7607 > 23456 # AS_TRANS RFC6793 > 64496-64511 # Reserved for use in docs and code RFC5398 > 64512-65534 # Reserved for Private Use RFC6996 > 65535 # Reserved RFC7300 > 65536-65551 # Reserved for use in docs and code RFC5398 > 65552-131071 # Reserved > 4200000000-4294967294 # Reserved for Private Use RFC6996 > 4294967295 # Reserved RFC7300 > > A current overview of what are considered Bogon ASNs is maintained at > NTT's Routing Policies page [2]. The IANA Autonomous System Number > Registry [3] is closely tracked and the NTT Bogon ASN definitions are > updated accordingly. > > We encourage network operators to consider deploying similar policies. > Configuration examples for various platforms can be found here [4]. > > NTT staff is monitoring current occurrences of Bogon ASNs in the routing > system and reaching out to impacted parties on a weekly basis. > > Kind regards, > > Job > > Contact persons: > > Job Snijders , Jared Mauch , > NTT Communications NOC > > References: > [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon > [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml > [4]: http://as2914.net/bogon_asns/configuration_examples.txt From jeffm at iglou.com Thu Jun 2 20:46:50 2016 From: jeffm at iglou.com (Jeff McAdams) Date: Thu, 2 Jun 2016 16:46:50 -0400 (EDT) Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <32916.64.6.220.221.1464896238.iglou@webmail.iglou.com> Message-ID: <33064.64.6.220.221.1464900410.iglou@webmail.iglou.com> On Thu, June 2, 2016 15:45, Christopher Morrow wrote: > On Thu, Jun 2, 2016 at 3:37 PM, Jeff McAdams wrote: >> Yes. I had a member of an account team for a networking vendor express >> extreme skepticism when discussing IP address plans and work I had >> done. When describing why I went with an IPv6 only solution for this >> setup, he responded, "Why not just get more IPv4 addresses? Just go >> back to IANA[sic] for more if you don't have enough already." >> OK, maybe it's not *just* marketing, but marketing (using the term >> broadly) is still a very large part of it. > ???your example sounds like ignorance, not marketing.??? No doubt his response was born of ignorance. The correct response is...well, education, not necessarily marketing...but at the 30k foot level, they amount to the same thing (thus my parenthetical comment about using the term "marketing" broadly), as I think the upthread comments were doing. -- Jeff From fhr at fhrnet.eu Thu Jun 2 20:53:15 2016 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 2 Jun 2016 22:53:15 +0200 Subject: craigslist.com admin In-Reply-To: References: Message-ID: <57509CBB.3070006@fhrnet.eu> Would be really stupid if they were blocking all users behind NATs. BTW if I enter craigslist.com, it redirects me to "prague.craigslist.cz" (makes sense, I'm from CZ and close to Prague), but it uses an invalid SSL certificate. --- Filip On 06/02/2016 10:45 PM, Darin Steffl wrote: > Have been getting reports of the same thing. Went to the craigslist help > forums where some people there decided to call us a fake ISP because we > don't hand out publics to every customer. They were VERY rude and hopefully > none of them were employees. They said our customers can't use craigslist > if we don't hand publics to everyone. It didn't matter to them that we > don't have enough IP's for every customer. > > I sent an email to some admin account someone recommended but haven't heard > anything back yet. > > > > On Tue, May 31, 2016 at 3:07 PM, Dennis Burgess > wrote: > >> Looking for a craigslist.com admin to connect with offlist about a block >> :) >> >> [DennisBurgessSignature] >> www.linktechs.net - 314-735-0270 x103 - >> dmburgess at linktechs.net >> >> > > From jfbeam at gmail.com Thu Jun 2 20:53:52 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 02 Jun 2016 16:53:52 -0400 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> References: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> Message-ID: On Wed, 01 Jun 2016 23:47:59 -0400, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > There is an epic lesson here. I'm just not sure what it is. :-) > > - - ferg https://youtu.be/SlA9hmrC8DU?t=2m25s From Valdis.Kletnieks at vt.edu Thu Jun 2 21:00:05 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Jun 2016 17:00:05 -0400 Subject: craigslist.com admin In-Reply-To: References: Message-ID: <19795.1464901205@turing-police.cc.vt.edu> On Thu, 02 Jun 2016 15:45:33 -0500, Darin Steffl said: > Have been getting reports of the same thing. Went to the craigslist help > forums where some people there decided to call us a fake ISP because we > don't hand out publics to every customer. They were VERY rude and hopefully > none of them were employees. They said our customers can't use craigslist > if we don't hand publics to everyone. It didn't matter to them that we > don't have enough IP's for every customer. Welcome to life in the post-exhaustion IPV4 space. I'd say "Deploy IPv6 and give everybody an address", except that won't fix the problem, as apparently Craigslist doesn't have an IPv6 presence yet.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From todd.crane at n5tech.com Thu Jun 2 21:11:57 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Thu, 2 Jun 2016 14:11:57 -0700 Subject: craigslist.com admin In-Reply-To: <19795.1464901205@turing-police.cc.vt.edu> References: <19795.1464901205@turing-police.cc.vt.edu> Message-ID: According to bgp.he.net and ARIN, craigslist has 2620:7E::/44 which is announced on several transits. Curious as to what they use it for if not Web, MX, or DNS. ?Todd > On Jun 2, 2016, at 2:00 PM, Valdis.Kletnieks at vt.edu wrote: > > apparently Craigslist doesn't have an IPv6 presence yet.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Thu Jun 2 21:25:02 2016 From: johnl at iecc.com (John Levine) Date: 2 Jun 2016 21:25:02 -0000 Subject: IPv6 is better than ipv4 In-Reply-To: <32916.64.6.220.221.1464896238.iglou@webmail.iglou.com> Message-ID: <20160602212502.11667.qmail@ary.lan> >responded, "Why not just get more IPv4 addresses? Just go back to >IANA[sic] for more if you don't have enough already." I can't say I'm surprised. Within the past year we've had mail from people here on NANOG who haven't gotten the memo that Network Solutions and Verisign are not the same company. R's, John From Valdis.Kletnieks at vt.edu Thu Jun 2 21:28:37 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Jun 2016 17:28:37 -0400 Subject: craigslist.com admin In-Reply-To: References: <19795.1464901205@turing-police.cc.vt.edu> Message-ID: <22077.1464902917@turing-police.cc.vt.edu> On Thu, 02 Jun 2016 14:11:57 -0700, Todd Crane said: > According to bgp.he.net and ARIN, craigslist has 2620:7E::/44 which is > announced on several transits. Curious as to what they use it for if not > Web, MX, or DNS. Well, for starters, they could put a quad-A in the DNS for www.craigslist.com, or for the MX for the craigslist.com domain, or for the 4 NS entries for their zone in the DNS. Evidence certainly points to them getting the block, and announcing it, but not actually using it for much of anything.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From richard.hesse at weebly.com Thu Jun 2 22:26:12 2016 From: richard.hesse at weebly.com (Richard Hesse) Date: Thu, 2 Jun 2016 15:26:12 -0700 Subject: Google GeoIP issue In-Reply-To: <6CA1AC26-D729-4A96-9143-BAEC327D9564@gmail.com> References: <5993A3E6-157D-4B0A-8E10-EF3FC8186DDD@standingwave.org> <64098D7A-E438-461D-A5B8-70752D11EA5E@gizmopartners.com> <6CA1AC26-D729-4A96-9143-BAEC327D9564@gmail.com> Message-ID: If you have peering relationship with Google, you can use the isp.google.com portal to self-publish geo information on your netblocks. At least you can in theory. By their own admission, they have never checked the self-published URL that I configured over a month ago. YMMV. -richard On Thu, Jun 2, 2016 at 6:19 AM, Maxwell Cole wrote: > Heya, > > Im in the same boat if anyone from google wants to be a dear and help out. > > Cheers, > > On Jun 1, 2016, at 6:28 PM, Chris Boyd wrote: > > > > I too am having a similar problem. Used the remediation link at > https://support.google.com/websearch/contact/ip and it?s only partially > corrected. Users who log in to Google are seeing the US google.com page > after they select the preferred country and languate, but everyone else is > still getting google.ae. 208.81.245.226 is in Austin, TX. > > > > ?Chris > > > >> On Jun 1, 2016, at 5:17 PM, Peter Loron > wrote: > >> > >> Hello folks. An address we use is not identified as being in the > correct location by Google. Can someone from their NOC reach out off-list? > >> > >> Thanks. > >> > >> > >> Sent from my iPhone > >> > > > > From jfbeam at gmail.com Fri Jun 3 01:23:52 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 02 Jun 2016 21:23:52 -0400 Subject: craigslist.com admin In-Reply-To: References: <19795.1464901205@turing-police.cc.vt.edu> Message-ID: On Thu, 02 Jun 2016 17:11:57 -0400, Todd Crane wrote: > ... Curious as to what they use it for if not Web, MX, or DNS. Same thing as Earthlink, apparently. (answer: nothing. at. all.) From michael at supermathie.net Fri Jun 3 02:36:06 2016 From: michael at supermathie.net (Michael Brown) Date: Thu, 2 Jun 2016 22:36:06 -0400 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: References: Message-ID: <5750ED16.90202@supermathie.net> On 2016-06-01 11:41 PM, Matthew Kaufman wrote: > Turns out it has nothing to do with my IPv4 connectivity. Neither of > my ISPs has native IPv6 connectivity, so both require tunnels (one of > them to HE.net, one to the ISPs own tunnel broker), and both appear to > be detected as a non-permitted VPN. As an early IPv6 adopter, I've had > IPv6 on all my household devices for years now. > > So after having to temporarily turn off IPv6 at my desktop to fix > issues with pay.gov (FCC license payments), and issues with various > other things, and then remember to turn it back on again... I now have > the reason I've been waiting for to turn it off globally for the whole > house. Wish I read this thread earlier. Damn. I just went through the whole useless process myself with an ineffectual support rep? ? > But if the system is telling you that error code, it is a setting on the local network, call your ISP, they can assist you on that issue. Oh right. RIGHT. I'm SURE they'll be able to help. ? ?and I came to the same conclusion and similar resolution (adding an outbound rule rejecting traffic to 2620:108:700f::/48, causing fallback to IPv4 worked for me). At least I got the support rep to SAY he opened a ticket. Wow! It's my chance to be the noisy minority! M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From hugo at slabnet.com Fri Jun 3 03:33:22 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 2 Jun 2016 20:33:22 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: <20160602180554.GA18851@ussenterprise.ufp.org> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <20160602180554.GA18851@ussenterprise.ufp.org> Message-ID: <20160603033322.GD4456@slab-wks-04.int.slabnet.com> On Thu 2016-Jun-02 11:05:54 -0700, Leo Bicknell wrote: >Warning: Hat = Enterprise Network Admin > Sarcasm = High > ... > >Sadly, I wish all these answers were some sort of carachture of reality, >but I think they are too many folks reality. IOW: http://ipv6excuses.com/ / https://twitter.com/ipv6excuses -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rea+nanog at grid.kiae.ru Fri Jun 3 05:05:44 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 3 Jun 2016 08:05:44 +0300 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: <20160603050544.GI1227light.codelabs.ru@light.codelabs.ru> Rubens, good day. Thu, Jun 02, 2016 at 01:32:29PM -0300, Rubens Kuhl wrote: > On Thu, Jun 2, 2016 at 11:47 AM, Ca By wrote: > > > > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > > > Wherein akamai explains a detailed study showing ipv6 is "well > > over 10%" faster than ipv4 on mobile, and they reference corroborating > > studies from Linkedin and Facebook. > > > > Says the company that consistently refused to dual-stack its customers by > default... What's your point? Does their technical reasoning or proving grounds for it lacking the needed expertise/experience due to the problems you're describing? Any other thigs you can say about the actual study? -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From vicente.luca at gmail.com Thu Jun 2 20:49:55 2016 From: vicente.luca at gmail.com (Vicente De Luca) Date: Thu, 02 Jun 2016 21:49:55 +0100 Subject: craigslist.com admin In-Reply-To: References: Message-ID: <57509BF3.3010409@gmail.com> I'd try consider this argument if they at least offer the web service in v6, which is not the case > Darin Steffl > June 2, 2016 at 9:45 PM > Have been getting reports of the same thing. Went to the craigslist help > forums where some people there decided to call us a fake ISP because we > don't hand out publics to every customer. They were VERY rude and > hopefully > none of them were employees. They said our customers can't use craigslist > if we don't hand publics to everyone. It didn't matter to them that we > don't have enough IP's for every customer. > > I sent an email to some admin account someone recommended but haven't > heard > anything back yet. > > > > On Tue, May 31, 2016 at 3:07 PM, Dennis Burgess > > > Dennis Burgess > May 31, 2016 at 9:07 PM > Looking for a craigslist.com admin to connect with offlist about a > block :) > > [DennisBurgessSignature] > www.linktechs.net - 314-735-0270 x103 - > dmburgess at linktechs.net > -- Sent with Postbox From mike.hyde1 at gmail.com Thu Jun 2 21:15:14 2016 From: mike.hyde1 at gmail.com (mike.hyde1 at gmail.com) Date: Thu, 2 Jun 2016 17:15:14 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Had the same problem at my house, but it was caused by the IPv6 connection to HE. Turned of V6 and the device worked. -- Sent with Airmail On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) wrote: Every device in my house is blocked from Netflix this evening due to their new "VPN blocker". My house is on my own IP space, and the outside of the NAT that the family devices are on is 198.202.199.254, announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house should show that I'm no farther away than Santa Cruz, CA as microwaves fly. Unfortunately, when one calls Netflix support to talk about this, the only response is to say "call your ISP and have them turn off the VPN software they've added to your account". And they absolutely refuse to escalate. Even if you tell them that you are essentially your own ISP. So... where's the Netflix network engineer on the list who all of us can send these issues to directly? Matthew Kaufman From jayb at braeburn.org Fri Jun 3 13:08:29 2016 From: jayb at braeburn.org (Jay Borkenhagen) Date: Fri, 3 Jun 2016 09:08:29 -0400 Subject: Bogon ASN Filter Policy In-Reply-To: References: <20160602194138.GM15096@57.rev.meerval.net> Message-ID: <22353.33101.968191.138056@oz.mt.att.com> AT&T/as7018 is also now in the process of updating its as-path bogon filters to match those cited below. We have long employed such filters, and our changes at this time are primarily to extend them to prohibit as23456 and the reserved blocks > as65535. So to Job and Adam and anyone else who deploys such filters: Thanks! I would like to extend to you this laurel, and hearty handshake... On 02-June-2016, Adam Davenport writes: > I personally applaud this effort as initiatives like this that help > prevent the global propagation of Bogons and other "bad things" only > serves to help us all. With that said, notice went out to potentially > affected GTT / AS3257 customers this week that by the end of June we too > will be filtering prefixes that contain any of the Bogon ASNs listed > below in the in the as-path. I highly encourage other networks to > follow suit, as again it only helps us all. > > Thanks Job for kicking this one off, and I look forward to others to > doing the same! > > Adam Davenport / adam.davenport at gtt.net > > > > On 6/2/16 3:41 PM, Job Snijders wrote: > > Dear fellow network operators, > > > > In July 2016, NTT Communications' Global IP Network AS2914 will deploy a > > new routing policy to block Bogon ASNs from its view of the default-free > > zone. This notification is provided as a courtesy to the network > > community at large. > > > > After the Bogon ASN filter policy has been deployed, AS 2914 will not > > accept route announcements from any eBGP neighbor which contains a Bogon > > ASN anywhere in the AS_PATH or its atomic aggregate attribute. > > > > The reasoning behind this policy is twofold: > > > > - Private or Reserved ASNs have no place in the public DFZ. Barring > > these from the DFZ helps improve accountability and dampen > > accidental exposure of internal routing artifacts. > > > > - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" > > in the DFZ is a either a misconfiguration or software issue. > > > > We are undertaking this effort to improve the quality of routing data as > > part of the global ecosystem. This should improve the security posture > > and provide additional certainty [1] to those undertaking network > > troubleshooting. > > > > Bogon ASNs are currently defined as following: > > > > 0 # Reserved RFC7607 > > 23456 # AS_TRANS RFC6793 > > 64496-64511 # Reserved for use in docs and code RFC5398 > > 64512-65534 # Reserved for Private Use RFC6996 > > 65535 # Reserved RFC7300 > > 65536-65551 # Reserved for use in docs and code RFC5398 > > 65552-131071 # Reserved > > 4200000000-4294967294 # Reserved for Private Use RFC6996 > > 4294967295 # Reserved RFC7300 > > > > A current overview of what are considered Bogon ASNs is maintained at > > NTT's Routing Policies page [2]. The IANA Autonomous System Number > > Registry [3] is closely tracked and the NTT Bogon ASN definitions are > > updated accordingly. > > > > We encourage network operators to consider deploying similar policies. > > Configuration examples for various platforms can be found here [4]. > > > > NTT staff is monitoring current occurrences of Bogon ASNs in the routing > > system and reaching out to impacted parties on a weekly basis. > > > > Kind regards, > > > > Job > > > > Contact persons: > > > > Job Snijders , Jared Mauch , > > NTT Communications NOC > > > > References: > > [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > > [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon > > [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml > > [4]: http://as2914.net/bogon_asns/configuration_examples.txt From nevin at yahoo-inc.com Fri Jun 3 15:55:10 2016 From: nevin at yahoo-inc.com (Nevin Gonsalves) Date: Fri, 3 Jun 2016 15:55:10 +0000 (UTC) Subject: craigslist.com admin In-Reply-To: References: Message-ID: <1916372015.769335.1464969310757.JavaMail.yahoo@mail.yahoo.com> Have you tried reaching them on?noc at craigslist.org ??thanks,-nevin On Thursday, June 2, 2016 1:48 PM, Darin Steffl wrote: Have been getting reports of the same thing. Went to the craigslist help forums where some people there decided to call us a fake ISP because we don't hand out publics to every customer. They were VERY rude and hopefully none of them were employees. They said our customers can't use craigslist if we don't hand publics to everyone. It didn't matter to them that we don't have enough IP's for every customer. I sent an email to some admin account someone recommended but haven't heard anything back yet. On Tue, May 31, 2016 at 3:07 PM, Dennis Burgess wrote: > Looking for a craigslist.com admin to connect with offlist about a block > :) > > [DennisBurgessSignature] > www.linktechs.net - 314-735-0270 x103 - > dmburgess at linktechs.net > > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook From blair.trosper at gmail.com Fri Jun 3 19:11:29 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 3 Jun 2016 12:11:29 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Confirmed that Hurricane Electric's TunnelBroker is now blocked by Netflix. Anyone nice people from Netflix perhaps want to take a crack at this? On Thu, Jun 2, 2016 at 2:15 PM, wrote: > Had the same problem at my house, but it was caused by the IPv6 connection > to HE. Turned of V6 and the device worked. > > > -- > > Sent with Airmail > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) > wrote: > > Every device in my house is blocked from Netflix this evening due to > their new "VPN blocker". My house is on my own IP space, and the outside > of the NAT that the family devices are on is 198.202.199.254, announced > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house > should show that I'm no farther away than Santa Cruz, CA as microwaves > fly. > > Unfortunately, when one calls Netflix support to talk about this, the > only response is to say "call your ISP and have them turn off the VPN > software they've added to your account". And they absolutely refuse to > escalate. Even if you tell them that you are essentially your own ISP. > > So... where's the Netflix network engineer on the list who all of us can > send these issues to directly? > > Matthew Kaufman > From mhuff at ox.com Fri Jun 3 19:37:39 2016 From: mhuff at ox.com (Matthew Huff) Date: Fri, 3 Jun 2016 19:37:39 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: I would imagine it was done on purpose. The purpose of the Netflix VPN detection was to block users from outside of different regions due to content providers requests. Since HE provides free ipv6 tunnels, it's an easy way to get around the blockage, hence the restriction. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Blair Trosper > Sent: Friday, June 3, 2016 3:11 PM > To: mike.hyde1 at gmail.com > Cc: NANOG > Subject: Re: Netflix VPN detection - actual engineer needed > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > Netflix. Anyone nice people from Netflix perhaps want to take a crack > at > this? > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > Had the same problem at my house, but it was caused by the IPv6 > connection > > to HE. Turned of V6 and the device worked. > > > > > > -- > > > > Sent with Airmail > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) > > wrote: > > > > Every device in my house is blocked from Netflix this evening due to > > their new "VPN blocker". My house is on my own IP space, and the > outside > > of the NAT that the family devices are on is 198.202.199.254, > announced > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house > > should show that I'm no farther away than Santa Cruz, CA as > microwaves > > fly. > > > > Unfortunately, when one calls Netflix support to talk about this, the > > only response is to say "call your ISP and have them turn off the VPN > > software they've added to your account". And they absolutely refuse > to > > escalate. Even if you tell them that you are essentially your own > ISP. > > > > So... where's the Netflix network engineer on the list who all of us > can > > send these issues to directly? > > > > Matthew Kaufman > > From cryptographrix at gmail.com Fri Jun 3 19:46:09 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 19:46:09 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Netflix needs to figure out a fix for this until ISPs actually provide IPv6 natively. On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper wrote: > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > Netflix. Anyone nice people from Netflix perhaps want to take a crack at > this? > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > Had the same problem at my house, but it was caused by the IPv6 > connection > > to HE. Turned of V6 and the device worked. > > > > > > -- > > > > Sent with Airmail > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) > > wrote: > > > > Every device in my house is blocked from Netflix this evening due to > > their new "VPN blocker". My house is on my own IP space, and the outside > > of the NAT that the family devices are on is 198.202.199.254, announced > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house > > should show that I'm no farther away than Santa Cruz, CA as microwaves > > fly. > > > > Unfortunately, when one calls Netflix support to talk about this, the > > only response is to say "call your ISP and have them turn off the VPN > > software they've added to your account". And they absolutely refuse to > > escalate. Even if you tell them that you are essentially your own ISP. > > > > So... where's the Netflix network engineer on the list who all of us can > > send these issues to directly? > > > > Matthew Kaufman > > > From sryan at arbor.net Fri Jun 3 19:49:06 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 15:49:06 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: I don't blame them for blocking a (effectively) anonymous tunnel broker. I'm sure their content providers are forcing their hand. On Jun 3, 2016 3:46 PM, "Cryptographrix" wrote: > Netflix needs to figure out a fix for this until ISPs actually provide IPv6 > natively. > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > wrote: > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > Netflix. Anyone nice people from Netflix perhaps want to take a crack at > > this? > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > Had the same problem at my house, but it was caused by the IPv6 > > connection > > > to HE. Turned of V6 and the device worked. > > > > > > > > > -- > > > > > > Sent with Airmail > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) > > > wrote: > > > > > > Every device in my house is blocked from Netflix this evening due to > > > their new "VPN blocker". My house is on my own IP space, and the > outside > > > of the NAT that the family devices are on is 198.202.199.254, announced > > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house > > > should show that I'm no farther away than Santa Cruz, CA as microwaves > > > fly. > > > > > > Unfortunately, when one calls Netflix support to talk about this, the > > > only response is to say "call your ISP and have them turn off the VPN > > > software they've added to your account". And they absolutely refuse to > > > escalate. Even if you tell them that you are essentially your own ISP. > > > > > > So... where's the Netflix network engineer on the list who all of us > can > > > send these issues to directly? > > > > > > Matthew Kaufman > > > > > > From rjacobs at pslightwave.com Fri Jun 3 19:55:57 2016 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Fri, 3 Jun 2016 19:55:57 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Seems everyone continues to forget the content providers are not Netflix...They are the Disney, Discovery, NBC, Turner ect... These are the ones that put clauses and restrictions in their licensing and re-broadcast agreements forcing things like Netflix is doing.. Robert Jacobs | Network Director/Architect Direct:? 832-615-7742 Main:?? 832-615-8000 Fax:??? 713-510-1650 5959 Corporate Dr. Suite 3300; Houston, TX 77036 A Certified Woman-Owned Business 24x7x365 Customer? Support: 832-615-8000 | support at pslightwave.com This electronic message contains information from Phonoscope Lightwave which may be privileged and confidential. The information is intended to be for the use of individual(s) or entity named above. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify me by telephone or e-mail immediately. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan Sent: Friday, June 3, 2016 2:49 PM To: Cryptographrix Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed I don't blame them for blocking a (effectively) anonymous tunnel broker. I'm sure their content providers are forcing their hand. On Jun 3, 2016 3:46 PM, "Cryptographrix" wrote: > Netflix needs to figure out a fix for this until ISPs actually provide > IPv6 natively. > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > wrote: > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > Netflix. Anyone nice people from Netflix perhaps want to take a > > crack at this? > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > Had the same problem at my house, but it was caused by the IPv6 > > connection > > > to HE. Turned of V6 and the device worked. > > > > > > > > > -- > > > > > > Sent with Airmail > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > (matthew at matthew.at) > > > wrote: > > > > > > Every device in my house is blocked from Netflix this evening due > > > to their new "VPN blocker". My house is on my own IP space, and > > > the > outside > > > of the NAT that the family devices are on is 198.202.199.254, > > > announced by AS 11994. A simple ping from Netflix HQ in Los Gatos > > > to my house should show that I'm no farther away than Santa Cruz, > > > CA as microwaves fly. > > > > > > Unfortunately, when one calls Netflix support to talk about this, > > > the only response is to say "call your ISP and have them turn off > > > the VPN software they've added to your account". And they > > > absolutely refuse to escalate. Even if you tell them that you are essentially your own ISP. > > > > > > So... where's the Netflix network engineer on the list who all of > > > us > can > > > send these issues to directly? > > > > > > Matthew Kaufman > > > > > > From cryptographrix at gmail.com Fri Jun 3 20:03:05 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:03:05 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Same, but until there's a real IPv6 presence in the US, it's really annoying that they haven't come up with some fix for this. I have no plans to turn off IPv6 at home - I actually have many uses for it, and as much as I dislike the controversy around it, think that adoption needs to be prioritized, not penalized. Additionally, I think that discussing content provider control over regional decisions isn't productive to the conversation, as they didn't build the banhammer (wouldn't you want to control your own content if you had made content specific to regional laws etc?). I.e. - not all shows need to have regional restrictions between New York (where I live) and California (where my IPv6 /64 says I live). I'm able to watch House in the any state in the U.S.? Great - ignore my intra-US proxy connection. My Netflix account randomly tries to connect from Tokyo because I forgot to shut off my work VPN? Fine....let me know and I'll turn *that* off. On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: > I don't blame them for blocking a (effectively) anonymous tunnel broker. > I'm sure their content providers are forcing their hand. > On Jun 3, 2016 3:46 PM, "Cryptographrix" wrote: > >> Netflix needs to figure out a fix for this until ISPs actually provide >> IPv6 >> natively. >> >> >> >> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >> wrote: >> >> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >> > Netflix. Anyone nice people from Netflix perhaps want to take a crack >> at >> > this? >> > >> > >> > >> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >> > >> > > Had the same problem at my house, but it was caused by the IPv6 >> > connection >> > > to HE. Turned of V6 and the device worked. >> > > >> > > >> > > -- >> > > >> > > Sent with Airmail >> > > >> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) >> > > wrote: >> > > >> > > Every device in my house is blocked from Netflix this evening due to >> > > their new "VPN blocker". My house is on my own IP space, and the >> outside >> > > of the NAT that the family devices are on is 198.202.199.254, >> announced >> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >> > > should show that I'm no farther away than Santa Cruz, CA as microwaves >> > > fly. >> > > >> > > Unfortunately, when one calls Netflix support to talk about this, the >> > > only response is to say "call your ISP and have them turn off the VPN >> > > software they've added to your account". And they absolutely refuse to >> > > escalate. Even if you tell them that you are essentially your own ISP. >> > > >> > > So... where's the Netflix network engineer on the list who all of us >> can >> > > send these issues to directly? >> > > >> > > Matthew Kaufman >> > > >> > >> > From sryan at arbor.net Fri Jun 3 20:05:04 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 16:05:04 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: There is no way for Netflix to know the difference between you being in NY and using the tunnel, and you living in Hong Kong and using the tunnel. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix wrote: > Same, but until there's a real IPv6 presence in the US, it's really > annoying that they haven't come up with some fix for this. > > I have no plans to turn off IPv6 at home - I actually have many uses for > it, and as much as I dislike the controversy around it, think that adoption > needs to be prioritized, not penalized. > > Additionally, I think that discussing content provider control over > regional decisions isn't productive to the conversation, as they didn't > build the banhammer (wouldn't you want to control your own content if you > had made content specific to regional laws etc?). > > I.e. - not all shows need to have regional restrictions between New York > (where I live) and California (where my IPv6 /64 says I live). > > I'm able to watch House in the any state in the U.S.? Great - ignore my > intra-US proxy connection. > > My Netflix account randomly tries to connect from Tokyo because I forgot > to shut off my work VPN? Fine....let me know and I'll turn *that* off. > > > > > > > On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: > >> I don't blame them for blocking a (effectively) anonymous tunnel broker. >> I'm sure their content providers are forcing their hand. >> On Jun 3, 2016 3:46 PM, "Cryptographrix" >> wrote: >> >>> Netflix needs to figure out a fix for this until ISPs actually provide >>> IPv6 >>> natively. >>> >>> >>> >>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>> wrote: >>> >>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>> > Netflix. Anyone nice people from Netflix perhaps want to take a crack >>> at >>> > this? >>> > >>> > >>> > >>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>> > >>> > > Had the same problem at my house, but it was caused by the IPv6 >>> > connection >>> > > to HE. Turned of V6 and the device worked. >>> > > >>> > > >>> > > -- >>> > > >>> > > Sent with Airmail >>> > > >>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at) >>> > > wrote: >>> > > >>> > > Every device in my house is blocked from Netflix this evening due to >>> > > their new "VPN blocker". My house is on my own IP space, and the >>> outside >>> > > of the NAT that the family devices are on is 198.202.199.254, >>> announced >>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>> > > should show that I'm no farther away than Santa Cruz, CA as >>> microwaves >>> > > fly. >>> > > >>> > > Unfortunately, when one calls Netflix support to talk about this, the >>> > > only response is to say "call your ISP and have them turn off the VPN >>> > > software they've added to your account". And they absolutely refuse >>> to >>> > > escalate. Even if you tell them that you are essentially your own >>> ISP. >>> > > >>> > > So... where's the Netflix network engineer on the list who all of us >>> can >>> > > send these issues to directly? >>> > > >>> > > Matthew Kaufman >>> > > >>> > >>> >> From cryptographrix at gmail.com Fri Jun 3 20:09:35 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:09:35 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: I have a VPN connection at my house. There's no way for them to know the difference between me using my home network connection from Hong Kong or my home network connection from my house. Are they going to disable connectivity from everywhere they can detect an open VPN port to, also? If they trust my v4 address, they can use that to establish historical reference. Additionally, they can fail over to v4 if they do not trust the v6 address. On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: > There is no way for Netflix to know the difference between you being in NY > and using the tunnel, and you living in Hong Kong and using the tunnel. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > wrote: > >> Same, but until there's a real IPv6 presence in the US, it's really >> annoying that they haven't come up with some fix for this. >> >> I have no plans to turn off IPv6 at home - I actually have many uses for >> it, and as much as I dislike the controversy around it, think that adoption >> needs to be prioritized, not penalized. >> >> Additionally, I think that discussing content provider control over >> regional decisions isn't productive to the conversation, as they didn't >> build the banhammer (wouldn't you want to control your own content if you >> had made content specific to regional laws etc?). >> >> I.e. - not all shows need to have regional restrictions between New York >> (where I live) and California (where my IPv6 /64 says I live). >> >> I'm able to watch House in the any state in the U.S.? Great - ignore my >> intra-US proxy connection. >> >> My Netflix account randomly tries to connect from Tokyo because I forgot >> to shut off my work VPN? Fine....let me know and I'll turn *that* off. >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >> >>> I don't blame them for blocking a (effectively) anonymous tunnel broker. >>> I'm sure their content providers are forcing their hand. >>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>> wrote: >>> >>>> Netflix needs to figure out a fix for this until ISPs actually provide >>>> IPv6 >>>> natively. >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>> wrote: >>>> >>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>> crack at >>>> > this? >>>> > >>>> > >>>> > >>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>> > >>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>> > connection >>>> > > to HE. Turned of V6 and the device worked. >>>> > > >>>> > > >>>> > > -- >>>> > > >>>> > > Sent with Airmail >>>> > > >>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at >>>> ) >>>> > > wrote: >>>> > > >>>> > > Every device in my house is blocked from Netflix this evening due to >>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>> outside >>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>> announced >>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>> microwaves >>>> > > fly. >>>> > > >>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>> the >>>> > > only response is to say "call your ISP and have them turn off the >>>> VPN >>>> > > software they've added to your account". And they absolutely refuse >>>> to >>>> > > escalate. Even if you tell them that you are essentially your own >>>> ISP. >>>> > > >>>> > > So... where's the Netflix network engineer on the list who all of >>>> us can >>>> > > send these issues to directly? >>>> > > >>>> > > Matthew Kaufman >>>> > > >>>> > >>>> >>> > From cryptographrix at gmail.com Fri Jun 3 20:10:52 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:10:52 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: (since we must dual-stack still here in the US) On Fri, Jun 3, 2016 at 4:09 PM Cryptographrix wrote: > I have a VPN connection at my house. There's no way for them to know the > difference between me using my home network connection from Hong Kong or my > home network connection from my house. > > Are they going to disable connectivity from everywhere they can detect an > open VPN port to, also? > > If they trust my v4 address, they can use that to establish historical > reference. Additionally, they can fail over to v4 if they do not trust the > v6 address. > > > > > On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: > >> There is no way for Netflix to know the difference between you being in >> NY and using the tunnel, and you living in Hong Kong and using the tunnel. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >> wrote: >> >>> Same, but until there's a real IPv6 presence in the US, it's really >>> annoying that they haven't come up with some fix for this. >>> >>> I have no plans to turn off IPv6 at home - I actually have many uses for >>> it, and as much as I dislike the controversy around it, think that adoption >>> needs to be prioritized, not penalized. >>> >>> Additionally, I think that discussing content provider control over >>> regional decisions isn't productive to the conversation, as they didn't >>> build the banhammer (wouldn't you want to control your own content if you >>> had made content specific to regional laws etc?). >>> >>> I.e. - not all shows need to have regional restrictions between New York >>> (where I live) and California (where my IPv6 /64 says I live). >>> >>> I'm able to watch House in the any state in the U.S.? Great - ignore my >>> intra-US proxy connection. >>> >>> My Netflix account randomly tries to connect from Tokyo because I forgot >>> to shut off my work VPN? Fine....let me know and I'll turn *that* off. >>> >>> >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >>> >>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>> broker. I'm sure their content providers are forcing their hand. >>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>> wrote: >>>> >>>>> Netflix needs to figure out a fix for this until ISPs actually provide >>>>> IPv6 >>>>> natively. >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>> wrote: >>>>> >>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>>> crack at >>>>> > this? >>>>> > >>>>> > >>>>> > >>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>>> > >>>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>>> > connection >>>>> > > to HE. Turned of V6 and the device worked. >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > >>>>> > > Sent with Airmail >>>>> > > >>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>> matthew at matthew.at) >>>>> > > wrote: >>>>> > > >>>>> > > Every device in my house is blocked from Netflix this evening due >>>>> to >>>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>>> outside >>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>> announced >>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>> microwaves >>>>> > > fly. >>>>> > > >>>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>>> the >>>>> > > only response is to say "call your ISP and have them turn off the >>>>> VPN >>>>> > > software they've added to your account". And they absolutely >>>>> refuse to >>>>> > > escalate. Even if you tell them that you are essentially your own >>>>> ISP. >>>>> > > >>>>> > > So... where's the Netflix network engineer on the list who all of >>>>> us can >>>>> > > send these issues to directly? >>>>> > > >>>>> > > Matthew Kaufman >>>>> > > >>>>> > >>>>> >>>> >> From sryan at arbor.net Fri Jun 3 20:17:39 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 16:17:39 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: There is a large difference between "the VPN run at your house" and "Arguably the most popular, free, mostly anonymous tunnel broker service" If it were up to the content providers, they probably would block any IP they saw a VPN server listening on. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix wrote: > I have a VPN connection at my house. There's no way for them to know the > difference between me using my home network connection from Hong Kong or my > home network connection from my house. > > Are they going to disable connectivity from everywhere they can detect an > open VPN port to, also? > > If they trust my v4 address, they can use that to establish historical > reference. Additionally, they can fail over to v4 if they do not trust the > v6 address. > > > > > On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: > >> There is no way for Netflix to know the difference between you being in >> NY and using the tunnel, and you living in Hong Kong and using the tunnel. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >> wrote: >> >>> Same, but until there's a real IPv6 presence in the US, it's really >>> annoying that they haven't come up with some fix for this. >>> >>> I have no plans to turn off IPv6 at home - I actually have many uses for >>> it, and as much as I dislike the controversy around it, think that adoption >>> needs to be prioritized, not penalized. >>> >>> Additionally, I think that discussing content provider control over >>> regional decisions isn't productive to the conversation, as they didn't >>> build the banhammer (wouldn't you want to control your own content if you >>> had made content specific to regional laws etc?). >>> >>> I.e. - not all shows need to have regional restrictions between New York >>> (where I live) and California (where my IPv6 /64 says I live). >>> >>> I'm able to watch House in the any state in the U.S.? Great - ignore my >>> intra-US proxy connection. >>> >>> My Netflix account randomly tries to connect from Tokyo because I forgot >>> to shut off my work VPN? Fine....let me know and I'll turn *that* off. >>> >>> >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >>> >>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>> broker. I'm sure their content providers are forcing their hand. >>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>> wrote: >>>> >>>>> Netflix needs to figure out a fix for this until ISPs actually provide >>>>> IPv6 >>>>> natively. >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>> wrote: >>>>> >>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>>> crack at >>>>> > this? >>>>> > >>>>> > >>>>> > >>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>>> > >>>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>>> > connection >>>>> > > to HE. Turned of V6 and the device worked. >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > >>>>> > > Sent with Airmail >>>>> > > >>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>> matthew at matthew.at) >>>>> > > wrote: >>>>> > > >>>>> > > Every device in my house is blocked from Netflix this evening due >>>>> to >>>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>>> outside >>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>> announced >>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>> microwaves >>>>> > > fly. >>>>> > > >>>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>>> the >>>>> > > only response is to say "call your ISP and have them turn off the >>>>> VPN >>>>> > > software they've added to your account". And they absolutely >>>>> refuse to >>>>> > > escalate. Even if you tell them that you are essentially your own >>>>> ISP. >>>>> > > >>>>> > > So... where's the Netflix network engineer on the list who all of >>>>> us can >>>>> > > send these issues to directly? >>>>> > > >>>>> > > Matthew Kaufman >>>>> > > >>>>> > >>>>> >>>> >> From cryptographrix at gmail.com Fri Jun 3 20:17:55 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:17:55 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: To be honest, I don't care about content providers having control over regional access controls - it's completely technologically backwards, but they're all about time zones so they can do what they want. BUT there are more reliable ways than using an IP to get geographic location in an era where any website can request your GPS location. They have an iOS team that can provide them with *the most authoritatively precise location of my device* for their Apple TV app. My IP should be the last thing they check to determine my location. I can do a million things to tweak that, including things that their proxy detection will never ever find out about. On Fri, Jun 3, 2016 at 3:55 PM Robert Jacobs wrote: > Seems everyone continues to forget the content providers are not > Netflix...They are the Disney, Discovery, NBC, Turner ect... These are the > ones that put clauses and restrictions in their licensing and re-broadcast > agreements forcing things like Netflix is doing.. > > Robert Jacobs | Network Director/Architect > > Direct: 832-615-7742 > Main: 832-615-8000 > Fax: 713-510-1650 > > 5959 Corporate Dr. Suite 3300; Houston, TX 77036 > > > > A Certified Woman-Owned Business > > 24x7x365 Customer Support: 832-615-8000 | support at pslightwave.com > This electronic message contains information from Phonoscope Lightwave > which may be privileged and confidential. The information is intended to be > for the use of individual(s) or entity named above. If you are not the > intended recipient, any disclosure, copying, distribution or use of the > contents of this information is prohibited. If you have received this > electronic message in error, please notify me by telephone or e-mail > immediately. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan > Sent: Friday, June 3, 2016 2:49 PM > To: Cryptographrix > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > I don't blame them for blocking a (effectively) anonymous tunnel broker. > I'm sure their content providers are forcing their hand. > On Jun 3, 2016 3:46 PM, "Cryptographrix" wrote: > > > Netflix needs to figure out a fix for this until ISPs actually provide > > IPv6 natively. > > > > > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > wrote: > > > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > > Netflix. Anyone nice people from Netflix perhaps want to take a > > > crack at this? > > > > > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > > > Had the same problem at my house, but it was caused by the IPv6 > > > connection > > > > to HE. Turned of V6 and the device worked. > > > > > > > > > > > > -- > > > > > > > > Sent with Airmail > > > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > > (matthew at matthew.at) > > > > wrote: > > > > > > > > Every device in my house is blocked from Netflix this evening due > > > > to their new "VPN blocker". My house is on my own IP space, and > > > > the > > outside > > > > of the NAT that the family devices are on is 198.202.199.254, > > > > announced by AS 11994. A simple ping from Netflix HQ in Los Gatos > > > > to my house should show that I'm no farther away than Santa Cruz, > > > > CA as microwaves fly. > > > > > > > > Unfortunately, when one calls Netflix support to talk about this, > > > > the only response is to say "call your ISP and have them turn off > > > > the VPN software they've added to your account". And they > > > > absolutely refuse to escalate. Even if you tell them that you are > essentially your own ISP. > > > > > > > > So... where's the Netflix network engineer on the list who all of > > > > us > > can > > > > send these issues to directly? > > > > > > > > Matthew Kaufman > > > > > > > > > > From cryptographrix at gmail.com Fri Jun 3 20:21:28 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:21:28 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any IP > they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > wrote: > >> I have a VPN connection at my house. There's no way for them to know the >> difference between me using my home network connection from Hong Kong or my >> home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can detect an >> open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish historical >> reference. Additionally, they can fail over to v4 if they do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: >> >>> There is no way for Netflix to know the difference between you being in >>> NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many uses >>>> for it, and as much as I dislike the controversy around it, think that >>>> adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they didn't >>>> build the banhammer (wouldn't you want to control your own content if you >>>> had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - ignore my >>>> intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 >>>>>> natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From SNaslund at medline.com Fri Jun 3 20:25:39 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 20:25:39 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B401E6619F67@MUNPRDMBXA1.medline.com> Two problem I see with that. 1. My TV is going to have a hard time figuring out its GPS location inside my living room. 2. It's not hard to make a device lie about a GPS position. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:18 PM To: Robert Jacobs; Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed To be honest, I don't care about content providers having control over regional access controls - it's completely technologically backwards, but they're all about time zones so they can do what they want. BUT there are more reliable ways than using an IP to get geographic location in an era where any website can request your GPS location. They have an iOS team that can provide them with *the most authoritatively precise location of my device* for their Apple TV app. My IP should be the last thing they check to determine my location. I can do a million things to tweak that, including things that their proxy detection will never ever find out about. On Fri, Jun 3, 2016 at 3:55 PM Robert Jacobs wrote: > Seems everyone continues to forget the content providers are not > Netflix...They are the Disney, Discovery, NBC, Turner ect... These are > the ones that put clauses and restrictions in their licensing and > re-broadcast agreements forcing things like Netflix is doing.. > > Robert Jacobs | Network Director/Architect > > Direct: 832-615-7742 > Main: 832-615-8000 > Fax: 713-510-1650 > > 5959 Corporate Dr. Suite 3300; Houston, TX 77036 > > > > A Certified Woman-Owned Business > > 24x7x365 Customer Support: 832-615-8000 | support at pslightwave.com > This electronic message contains information from Phonoscope Lightwave > which may be privileged and confidential. The information is intended > to be for the use of individual(s) or entity named above. If you are > not the intended recipient, any disclosure, copying, distribution or > use of the contents of this information is prohibited. If you have > received this electronic message in error, please notify me by > telephone or e-mail immediately. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan > Sent: Friday, June 3, 2016 2:49 PM > To: Cryptographrix > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > I don't blame them for blocking a (effectively) anonymous tunnel broker. > I'm sure their content providers are forcing their hand. > On Jun 3, 2016 3:46 PM, "Cryptographrix" wrote: > > > Netflix needs to figure out a fix for this until ISPs actually > > provide > > IPv6 natively. > > > > > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > > > wrote: > > > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > > Netflix. Anyone nice people from Netflix perhaps want to take a > > > crack at this? > > > > > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > > > Had the same problem at my house, but it was caused by the IPv6 > > > connection > > > > to HE. Turned of V6 and the device worked. > > > > > > > > > > > > -- > > > > > > > > Sent with Airmail > > > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > > (matthew at matthew.at) > > > > wrote: > > > > > > > > Every device in my house is blocked from Netflix this evening > > > > due to their new "VPN blocker". My house is on my own IP space, > > > > and the > > outside > > > > of the NAT that the family devices are on is 198.202.199.254, > > > > announced by AS 11994. A simple ping from Netflix HQ in Los > > > > Gatos to my house should show that I'm no farther away than > > > > Santa Cruz, CA as microwaves fly. > > > > > > > > Unfortunately, when one calls Netflix support to talk about > > > > this, the only response is to say "call your ISP and have them > > > > turn off the VPN software they've added to your account". And > > > > they absolutely refuse to escalate. Even if you tell them that > > > > you are > essentially your own ISP. > > > > > > > > So... where's the Netflix network engineer on the list who all > > > > of us > > can > > > > send these issues to directly? > > > > > > > > Matthew Kaufman > > > > > > > > > > From SNaslund at medline.com Fri Jun 3 20:34:54 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 20:34:54 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From cryptographrix at gmail.com Fri Jun 3 20:36:20 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:36:20 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6619F67@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F67@MUNPRDMBXA1.medline.com> Message-ID: It's much less hard to make an IP connection lie about it's location than it is to make a non-rooted (which is easy to detect) iOS device lie about it's AGPS-derived location. In all cases. On Fri, Jun 3, 2016 at 4:28 PM Naslund, Steve wrote: > Two problem I see with that. > > 1. My TV is going to have a hard time figuring out its GPS location > inside my living room. > 2. It's not hard to make a device lie about a GPS position. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix > Sent: Friday, June 03, 2016 3:18 PM > To: Robert Jacobs; Spencer Ryan > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > To be honest, I don't care about content providers having control over > regional access controls - it's completely technologically backwards, but > they're all about time zones so they can do what they want. > > BUT there are more reliable ways than using an IP to get geographic > location in an era where any website can request your GPS location. > > They have an iOS team that can provide them with *the most authoritatively > precise location of my device* for their Apple TV app. > > My IP should be the last thing they check to determine my location. I can > do a million things to tweak that, including things that their proxy > detection will never ever find out about. > > > On Fri, Jun 3, 2016 at 3:55 PM Robert Jacobs > wrote: > > > Seems everyone continues to forget the content providers are not > > Netflix...They are the Disney, Discovery, NBC, Turner ect... These are > > the ones that put clauses and restrictions in their licensing and > > re-broadcast agreements forcing things like Netflix is doing.. > > > > Robert Jacobs | Network Director/Architect > > > > Direct: 832-615-7742 > > Main: 832-615-8000 > > Fax: 713-510-1650 > > > > 5959 Corporate Dr. Suite 3300; Houston, TX 77036 > > > > > > > > A Certified Woman-Owned Business > > > > 24x7x365 Customer Support: 832-615-8000 | support at pslightwave.com > > This electronic message contains information from Phonoscope Lightwave > > which may be privileged and confidential. The information is intended > > to be for the use of individual(s) or entity named above. If you are > > not the intended recipient, any disclosure, copying, distribution or > > use of the contents of this information is prohibited. If you have > > received this electronic message in error, please notify me by > > telephone or e-mail immediately. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan > > Sent: Friday, June 3, 2016 2:49 PM > > To: Cryptographrix > > Cc: North American Network Operators' Group > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > I don't blame them for blocking a (effectively) anonymous tunnel broker. > > I'm sure their content providers are forcing their hand. > > On Jun 3, 2016 3:46 PM, "Cryptographrix" > wrote: > > > > > Netflix needs to figure out a fix for this until ISPs actually > > > provide > > > IPv6 natively. > > > > > > > > > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > > > > > wrote: > > > > > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > > > Netflix. Anyone nice people from Netflix perhaps want to take a > > > > crack at this? > > > > > > > > > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > > > > > Had the same problem at my house, but it was caused by the IPv6 > > > > connection > > > > > to HE. Turned of V6 and the device worked. > > > > > > > > > > > > > > > -- > > > > > > > > > > Sent with Airmail > > > > > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > > > (matthew at matthew.at) > > > > > wrote: > > > > > > > > > > Every device in my house is blocked from Netflix this evening > > > > > due to their new "VPN blocker". My house is on my own IP space, > > > > > and the > > > outside > > > > > of the NAT that the family devices are on is 198.202.199.254, > > > > > announced by AS 11994. A simple ping from Netflix HQ in Los > > > > > Gatos to my house should show that I'm no farther away than > > > > > Santa Cruz, CA as microwaves fly. > > > > > > > > > > Unfortunately, when one calls Netflix support to talk about > > > > > this, the only response is to say "call your ISP and have them > > > > > turn off the VPN software they've added to your account". And > > > > > they absolutely refuse to escalate. Even if you tell them that > > > > > you are > > essentially your own ISP. > > > > > > > > > > So... where's the Netflix network engineer on the list who all > > > > > of us > > > can > > > > > send these issues to directly? > > > > > > > > > > Matthew Kaufman > > > > > > > > > > > > > > > From cryptographrix at gmail.com Fri Jun 3 20:41:57 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 20:41:57 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> Message-ID: Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve wrote: > Their app could request your devices location. Problem is a lot of > devices (like TVs, Apple TVs, most DVD player, i.e. device with built in > Netflix) don't know where they are and it cannot easily be added (indoor > GPS is still difficult/expensive) and even if they could should they be > believed. I think the bigger issue is whether any kind of regional > controls are enforceable or effective any more. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix > Sent: Friday, June 03, 2016 3:21 PM > To: Spencer Ryan > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > Come now, content providers really just care that they have access to > regional controls more so than their ability to blanket-deny access (ok, > minus the MLB who are just insane). > > And part of those regional controls deal with the accuracy of the location > information. > > If their app can request my device's precise location, it doesn't need to > infer my location from my IP any more. > > As a matter of fact, it's only detrimental to them for it to do so, > because of the lack of accuracy from geo databases and the various reasons > that people use VPNs nowadays (i.e. for some devices that you can't even > turn VPN connections off for - OR in the case of IPv6, when you can't reach > a segment of the Internet without it). > > > On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan wrote: > > > There is a large difference between "the VPN run at your house" and > > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > > > If it were up to the content providers, they probably would block any > > IP they saw a VPN server listening on. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > > Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > > wrote: > > > >> I have a VPN connection at my house. There's no way for them to know > >> the difference between me using my home network connection from Hong > >> Kong or my home network connection from my house. > >> > >> Are they going to disable connectivity from everywhere they can > >> detect an open VPN port to, also? > >> > >> If they trust my v4 address, they can use that to establish > >> historical reference. Additionally, they can fail over to v4 if they > >> do not trust the > >> v6 address. > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: > >> > >>> There is no way for Netflix to know the difference between you being > >>> in NY and using the tunnel, and you living in Hong Kong and using the > tunnel. > >>> > >>> > >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >>> *Arbor Networks* > >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>> www.arbornetworks.com > >>> > >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > >>> >>> > wrote: > >>> > >>>> Same, but until there's a real IPv6 presence in the US, it's really > >>>> annoying that they haven't come up with some fix for this. > >>>> > >>>> I have no plans to turn off IPv6 at home - I actually have many > >>>> uses for it, and as much as I dislike the controversy around it, > >>>> think that adoption needs to be prioritized, not penalized. > >>>> > >>>> Additionally, I think that discussing content provider control over > >>>> regional decisions isn't productive to the conversation, as they > >>>> didn't build the banhammer (wouldn't you want to control your own > >>>> content if you had made content specific to regional laws etc?). > >>>> > >>>> I.e. - not all shows need to have regional restrictions between New > >>>> York (where I live) and California (where my IPv6 /64 says I live). > >>>> > >>>> I'm able to watch House in the any state in the U.S.? Great - > >>>> ignore my intra-US proxy connection. > >>>> > >>>> My Netflix account randomly tries to connect from Tokyo because I > >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn > >>>> *that* off. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: > >>>> > >>>>> I don't blame them for blocking a (effectively) anonymous tunnel > >>>>> broker. I'm sure their content providers are forcing their hand. > >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Netflix needs to figure out a fix for this until ISPs actually > >>>>>> provide IPv6 natively. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > >>>>>> >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked > >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to > >>>>>> > take a > >>>>>> crack at > >>>>>> > this? > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > >>>>>> > > >>>>>> > > Had the same problem at my house, but it was caused by the > >>>>>> > > IPv6 > >>>>>> > connection > >>>>>> > > to HE. Turned of V6 and the device worked. > >>>>>> > > > >>>>>> > > > >>>>>> > > -- > >>>>>> > > > >>>>>> > > Sent with Airmail > >>>>>> > > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( > >>>>>> matthew at matthew.at) > >>>>>> > > wrote: > >>>>>> > > > >>>>>> > > Every device in my house is blocked from Netflix this evening > >>>>>> > > due > >>>>>> to > >>>>>> > > their new "VPN blocker". My house is on my own IP space, and > >>>>>> > > the > >>>>>> outside > >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, > >>>>>> announced > >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my > >>>>>> house > >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as > >>>>>> microwaves > >>>>>> > > fly. > >>>>>> > > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about > >>>>>> > > this, > >>>>>> the > >>>>>> > > only response is to say "call your ISP and have them turn off > >>>>>> > > the > >>>>>> VPN > >>>>>> > > software they've added to your account". And they absolutely > >>>>>> refuse to > >>>>>> > > escalate. Even if you tell them that you are essentially your > >>>>>> > > own > >>>>>> ISP. > >>>>>> > > > >>>>>> > > So... where's the Netflix network engineer on the list who > >>>>>> > > all of > >>>>>> us can > >>>>>> > > send these issues to directly? > >>>>>> > > > >>>>>> > > Matthew Kaufman > >>>>>> > > > >>>>>> > > >>>>>> > >>>>> > >>> > > > From sryan at arbor.net Fri Jun 3 20:43:12 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 16:43:12 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F67@MUNPRDMBXA1.medline.com> Message-ID: And what about the millions of TVs, DVD players and all the other embedded devices that don't/can't support any kind of location services? On Jun 3, 2016 4:38 PM, "Cryptographrix" wrote: > It's much less hard to make an IP connection lie about it's location than > it is to make a non-rooted (which is easy to detect) iOS device lie about > it's AGPS-derived location. > > In all cases. > On Fri, Jun 3, 2016 at 4:28 PM Naslund, Steve > wrote: > > > Two problem I see with that. > > > > 1. My TV is going to have a hard time figuring out its GPS location > > inside my living room. > > 2. It's not hard to make a device lie about a GPS position. > > > > Steven Naslund > > Chicago IL > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix > > Sent: Friday, June 03, 2016 3:18 PM > > To: Robert Jacobs; Spencer Ryan > > Cc: North American Network Operators' Group > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > To be honest, I don't care about content providers having control over > > regional access controls - it's completely technologically backwards, but > > they're all about time zones so they can do what they want. > > > > BUT there are more reliable ways than using an IP to get geographic > > location in an era where any website can request your GPS location. > > > > They have an iOS team that can provide them with *the most > authoritatively > > precise location of my device* for their Apple TV app. > > > > My IP should be the last thing they check to determine my location. I can > > do a million things to tweak that, including things that their proxy > > detection will never ever find out about. > > > > > > On Fri, Jun 3, 2016 at 3:55 PM Robert Jacobs > > wrote: > > > > > Seems everyone continues to forget the content providers are not > > > Netflix...They are the Disney, Discovery, NBC, Turner ect... These are > > > the ones that put clauses and restrictions in their licensing and > > > re-broadcast agreements forcing things like Netflix is doing.. > > > > > > Robert Jacobs | Network Director/Architect > > > > > > Direct: 832-615-7742 > > > Main: 832-615-8000 > > > Fax: 713-510-1650 > > > > > > 5959 Corporate Dr. Suite 3300; Houston, TX 77036 > > > > > > > > > > > > A Certified Woman-Owned Business > > > > > > 24x7x365 Customer Support: 832-615-8000 | support at pslightwave.com > > > This electronic message contains information from Phonoscope Lightwave > > > which may be privileged and confidential. The information is intended > > > to be for the use of individual(s) or entity named above. If you are > > > not the intended recipient, any disclosure, copying, distribution or > > > use of the contents of this information is prohibited. If you have > > > received this electronic message in error, please notify me by > > > telephone or e-mail immediately. > > > > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan > > > Sent: Friday, June 3, 2016 2:49 PM > > > To: Cryptographrix > > > Cc: North American Network Operators' Group > > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > > > I don't blame them for blocking a (effectively) anonymous tunnel > broker. > > > I'm sure their content providers are forcing their hand. > > > On Jun 3, 2016 3:46 PM, "Cryptographrix" > > wrote: > > > > > > > Netflix needs to figure out a fix for this until ISPs actually > > > > provide > > > > IPv6 natively. > > > > > > > > > > > > > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > > > > > > > wrote: > > > > > > > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > > > > > Netflix. Anyone nice people from Netflix perhaps want to take a > > > > > crack at this? > > > > > > > > > > > > > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > > > > > > > Had the same problem at my house, but it was caused by the IPv6 > > > > > connection > > > > > > to HE. Turned of V6 and the device worked. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Sent with Airmail > > > > > > > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > > > > (matthew at matthew.at) > > > > > > wrote: > > > > > > > > > > > > Every device in my house is blocked from Netflix this evening > > > > > > due to their new "VPN blocker". My house is on my own IP space, > > > > > > and the > > > > outside > > > > > > of the NAT that the family devices are on is 198.202.199.254, > > > > > > announced by AS 11994. A simple ping from Netflix HQ in Los > > > > > > Gatos to my house should show that I'm no farther away than > > > > > > Santa Cruz, CA as microwaves fly. > > > > > > > > > > > > Unfortunately, when one calls Netflix support to talk about > > > > > > this, the only response is to say "call your ISP and have them > > > > > > turn off the VPN software they've added to your account". And > > > > > > they absolutely refuse to escalate. Even if you tell them that > > > > > > you are > > > essentially your own ISP. > > > > > > > > > > > > So... where's the Netflix network engineer on the list who all > > > > > > of us > > > > can > > > > > > send these issues to directly? > > > > > > > > > > > > Matthew Kaufman > > > > > > > > > > > > > > > > > > > > > From alex.buie at frozenfeline.net Fri Jun 3 20:53:22 2016 From: alex.buie at frozenfeline.net (Alex Buie) Date: Fri, 3 Jun 2016 16:53:22 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F67@MUNPRDMBXA1.medline.com> Message-ID: This is not a zero sum solution. Fallback to IP geolocation if more precise location detection is not available, but if it is, use that. You could even have a "location score" composite index composed of all the different locale and historical session data you've accumulated. (cf things like cloudflare bad-actor detection which uses many heuristics to determine if you are who you say you are and whether to serve content to you) On Fri, Jun 3, 2016 at 4:43 PM, Spencer Ryan wrote: > And what about the millions of TVs, DVD players and all the other embedded > devices that don't/can't support any kind of location services? > On Jun 3, 2016 4:38 PM, "Cryptographrix" wrote: > > > It's much less hard to make an IP connection lie about it's location than > > it is to make a non-rooted (which is easy to detect) iOS device lie about > > it's AGPS-derived location. > > > > In all cases. > > On Fri, Jun 3, 2016 at 4:28 PM Naslund, Steve > > wrote: > > > > > Two problem I see with that. > > > > > > 1. My TV is going to have a hard time figuring out its GPS > location > > > inside my living room. > > > 2. It's not hard to make a device lie about a GPS position. > > > > > > Steven Naslund > > > Chicago IL > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Cryptographrix > > > Sent: Friday, June 03, 2016 3:18 PM > > > To: Robert Jacobs; Spencer Ryan > > > Cc: North American Network Operators' Group > > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > > > To be honest, I don't care about content providers having control over > > > regional access controls - it's completely technologically backwards, > but > > > they're all about time zones so they can do what they want. > > > > > > BUT there are more reliable ways than using an IP to get geographic > > > location in an era where any website can request your GPS location. > > > > > > They have an iOS team that can provide them with *the most > > authoritatively > > > precise location of my device* for their Apple TV app. > > > > > > My IP should be the last thing they check to determine my location. I > can > > > do a million things to tweak that, including things that their proxy > > > detection will never ever find out about. > > > > > > > > > On Fri, Jun 3, 2016 at 3:55 PM Robert Jacobs > > > wrote: > > > > > > > Seems everyone continues to forget the content providers are not > > > > Netflix...They are the Disney, Discovery, NBC, Turner ect... These > are > > > > the ones that put clauses and restrictions in their licensing and > > > > re-broadcast agreements forcing things like Netflix is doing.. > > > > > > > > Robert Jacobs | Network Director/Architect > > > > > > > > Direct: 832-615-7742 > > > > Main: 832-615-8000 > > > > Fax: 713-510-1650 > > > > > > > > 5959 Corporate Dr. Suite 3300; Houston, TX 77036 > > > > > > > > > > > > > > > > A Certified Woman-Owned Business > > > > > > > > 24x7x365 Customer Support: 832-615-8000 | support at pslightwave.com > > > > This electronic message contains information from Phonoscope > Lightwave > > > > which may be privileged and confidential. The information is intended > > > > to be for the use of individual(s) or entity named above. If you are > > > > not the intended recipient, any disclosure, copying, distribution or > > > > use of the contents of this information is prohibited. If you have > > > > received this electronic message in error, please notify me by > > > > telephone or e-mail immediately. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer > Ryan > > > > Sent: Friday, June 3, 2016 2:49 PM > > > > To: Cryptographrix > > > > Cc: North American Network Operators' Group > > > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > > > > > I don't blame them for blocking a (effectively) anonymous tunnel > > broker. > > > > I'm sure their content providers are forcing their hand. > > > > On Jun 3, 2016 3:46 PM, "Cryptographrix" > > > wrote: > > > > > > > > > Netflix needs to figure out a fix for this until ISPs actually > > > > > provide > > > > > IPv6 natively. > > > > > > > > > > > > > > > > > > > > On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > > > > > > > > > wrote: > > > > > > > > > > > Confirmed that Hurricane Electric's TunnelBroker is now blocked > by > > > > > > Netflix. Anyone nice people from Netflix perhaps want to take a > > > > > > crack at this? > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > > > > > > > > > > > > > Had the same problem at my house, but it was caused by the IPv6 > > > > > > connection > > > > > > > to HE. Turned of V6 and the device worked. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Sent with Airmail > > > > > > > > > > > > > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman > > > > > > > (matthew at matthew.at) > > > > > > > wrote: > > > > > > > > > > > > > > Every device in my house is blocked from Netflix this evening > > > > > > > due to their new "VPN blocker". My house is on my own IP space, > > > > > > > and the > > > > > outside > > > > > > > of the NAT that the family devices are on is 198.202.199.254, > > > > > > > announced by AS 11994. A simple ping from Netflix HQ in Los > > > > > > > Gatos to my house should show that I'm no farther away than > > > > > > > Santa Cruz, CA as microwaves fly. > > > > > > > > > > > > > > Unfortunately, when one calls Netflix support to talk about > > > > > > > this, the only response is to say "call your ISP and have them > > > > > > > turn off the VPN software they've added to your account". And > > > > > > > they absolutely refuse to escalate. Even if you tell them that > > > > > > > you are > > > > essentially your own ISP. > > > > > > > > > > > > > > So... where's the Netflix network engineer on the list who all > > > > > > > of us > > > > > can > > > > > > > send these issues to directly? > > > > > > > > > > > > > > Matthew Kaufman > > > > > > > > > > > > > > > > > > > > > > > > > > > > From SNaslund at medline.com Fri Jun 3 20:55:43 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 20:55:43 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> Wifi location depends on a bunch of problematic things. First, your SSID needs to get collected and put in a database somewhere. That itself is a crap shoot. Next, you can stop google (and some other wifi databases) from collecting the data by putting _nomap at the end of your SSID. Lastly, not everyone has wifi or iOS or GPS or whatever location method you can think of. BTW, my apple TV is on a wired Ethernet, not wifi. Point is, for whatever location technology you want to use be it IP, GPS, WiFi location, sextant?..they can be inaccurate and they can be faked and there are privacy concerns with all of them. What the content producers need to figure out is that regionalization DOES NOT WORK ANYMORE! The original point was that they could have different release dates in different areas at different prices and availability. They are going to have to get over it because they will lose the technological arms race. There is no reason you could not beat all of the location systems with a simple proxy. A proxy makes a Netflix connection from an allowed IP, location or whatever and then builds a new video/audio stream out the back end to the client anywhere in the world. Simple to implement and damn near impossible to beat. Ever hear of Slingbox? Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 3:42 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > wrote: Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan > wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan > wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >>> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan > wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> > >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> >>>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, > wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From alex.buie at frozenfeline.net Fri Jun 3 20:56:50 2016 From: alex.buie at frozenfeline.net (Alex Buie) Date: Fri, 3 Jun 2016 16:56:50 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: Agreed. I find it silly that as a US citizen on my US-bank-paid-for Netflix account with US physical address information suddenly cannot watch things when travelling I legally could if I were standing in another place. On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix wrote: > I have a VPN connection at my house. There's no way for them to know the > difference between me using my home network connection from Hong Kong or my > home network connection from my house. > > Are they going to disable connectivity from everywhere they can detect an > open VPN port to, also? > > If they trust my v4 address, they can use that to establish historical > reference. Additionally, they can fail over to v4 if they do not trust the > v6 address. > > > > > On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan wrote: > > > There is no way for Netflix to know the difference between you being in > NY > > and using the tunnel, and you living in Hong Kong and using the tunnel. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > *Arbor Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > > > wrote: > > > >> Same, but until there's a real IPv6 presence in the US, it's really > >> annoying that they haven't come up with some fix for this. > >> > >> I have no plans to turn off IPv6 at home - I actually have many uses for > >> it, and as much as I dislike the controversy around it, think that > adoption > >> needs to be prioritized, not penalized. > >> > >> Additionally, I think that discussing content provider control over > >> regional decisions isn't productive to the conversation, as they didn't > >> build the banhammer (wouldn't you want to control your own content if > you > >> had made content specific to regional laws etc?). > >> > >> I.e. - not all shows need to have regional restrictions between New York > >> (where I live) and California (where my IPv6 /64 says I live). > >> > >> I'm able to watch House in the any state in the U.S.? Great - ignore my > >> intra-US proxy connection. > >> > >> My Netflix account randomly tries to connect from Tokyo because I forgot > >> to shut off my work VPN? Fine....let me know and I'll turn *that* off. > >> > >> > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: > >> > >>> I don't blame them for blocking a (effectively) anonymous tunnel > broker. > >>> I'm sure their content providers are forcing their hand. > >>> On Jun 3, 2016 3:46 PM, "Cryptographrix" > >>> wrote: > >>> > >>>> Netflix needs to figure out a fix for this until ISPs actually provide > >>>> IPv6 > >>>> natively. > >>>> > >>>> > >>>> > >>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > > >>>> wrote: > >>>> > >>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by > >>>> > Netflix. Anyone nice people from Netflix perhaps want to take a > >>>> crack at > >>>> > this? > >>>> > > >>>> > > >>>> > > >>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: > >>>> > > >>>> > > Had the same problem at my house, but it was caused by the IPv6 > >>>> > connection > >>>> > > to HE. Turned of V6 and the device worked. > >>>> > > > >>>> > > > >>>> > > -- > >>>> > > > >>>> > > Sent with Airmail > >>>> > > > >>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( > matthew at matthew.at > >>>> ) > >>>> > > wrote: > >>>> > > > >>>> > > Every device in my house is blocked from Netflix this evening due > to > >>>> > > their new "VPN blocker". My house is on my own IP space, and the > >>>> outside > >>>> > > of the NAT that the family devices are on is 198.202.199.254, > >>>> announced > >>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my > house > >>>> > > should show that I'm no farther away than Santa Cruz, CA as > >>>> microwaves > >>>> > > fly. > >>>> > > > >>>> > > Unfortunately, when one calls Netflix support to talk about this, > >>>> the > >>>> > > only response is to say "call your ISP and have them turn off the > >>>> VPN > >>>> > > software they've added to your account". And they absolutely > refuse > >>>> to > >>>> > > escalate. Even if you tell them that you are essentially your own > >>>> ISP. > >>>> > > > >>>> > > So... where's the Netflix network engineer on the list who all of > >>>> us can > >>>> > > send these issues to directly? > >>>> > > > >>>> > > Matthew Kaufman > >>>> > > > >>>> > > >>>> > >>> > > > From blair.trosper at gmail.com Fri Jun 3 20:59:58 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 3 Jun 2016 13:59:58 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: I dunno. I could argue that I could -- to extend that idea -- let literally ANYONE tunnel through my Comcast Business connection to appear to be in the Bay Area. How's that fundamentally different than a service like TunnelBroker apart from economies of scale? More than a few people I know are ready to dump Netflix for this. Fortunately, where I live, Comcast Business has native dual stack... On Fri, Jun 3, 2016 at 1:05 PM, Spencer Ryan wrote: > There is no way for Netflix to know the difference between you being in NY > and using the tunnel, and you living in Hong Kong and using the tunnel. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > wrote: > >> Same, but until there's a real IPv6 presence in the US, it's really >> annoying that they haven't come up with some fix for this. >> >> I have no plans to turn off IPv6 at home - I actually have many uses for >> it, and as much as I dislike the controversy around it, think that adoption >> needs to be prioritized, not penalized. >> >> Additionally, I think that discussing content provider control over >> regional decisions isn't productive to the conversation, as they didn't >> build the banhammer (wouldn't you want to control your own content if you >> had made content specific to regional laws etc?). >> >> I.e. - not all shows need to have regional restrictions between New York >> (where I live) and California (where my IPv6 /64 says I live). >> >> I'm able to watch House in the any state in the U.S.? Great - ignore my >> intra-US proxy connection. >> >> My Netflix account randomly tries to connect from Tokyo because I forgot >> to shut off my work VPN? Fine....let me know and I'll turn *that* off. >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >> >>> I don't blame them for blocking a (effectively) anonymous tunnel broker. >>> I'm sure their content providers are forcing their hand. >>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>> wrote: >>> >>>> Netflix needs to figure out a fix for this until ISPs actually provide >>>> IPv6 >>>> natively. >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>> wrote: >>>> >>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>> crack at >>>> > this? >>>> > >>>> > >>>> > >>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>> > >>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>> > connection >>>> > > to HE. Turned of V6 and the device worked. >>>> > > >>>> > > >>>> > > -- >>>> > > >>>> > > Sent with Airmail >>>> > > >>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman (matthew at matthew.at >>>> ) >>>> > > wrote: >>>> > > >>>> > > Every device in my house is blocked from Netflix this evening due to >>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>> outside >>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>> announced >>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>> microwaves >>>> > > fly. >>>> > > >>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>> the >>>> > > only response is to say "call your ISP and have them turn off the >>>> VPN >>>> > > software they've added to your account". And they absolutely refuse >>>> to >>>> > > escalate. Even if you tell them that you are essentially your own >>>> ISP. >>>> > > >>>> > > So... where's the Netflix network engineer on the list who all of >>>> us can >>>> > > send these issues to directly? >>>> > > >>>> > > Matthew Kaufman >>>> > > >>>> > >>>> >>> > From sryan at arbor.net Fri Jun 3 21:03:27 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 17:03:27 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: It's not. But if you start pumping 10s of gigabits to Netflix with thousands of user IDs Netflix will blacklist your /56 as well. On Jun 3, 2016 5:00 PM, "Blair Trosper" wrote: > I dunno. I could argue that I could -- to extend that idea -- let > literally ANYONE tunnel through my Comcast Business connection to appear to > be in the Bay Area. How's that fundamentally different than a service like > TunnelBroker apart from economies of scale? > > More than a few people I know are ready to dump Netflix for this. > Fortunately, where I live, Comcast Business has native dual stack... > > On Fri, Jun 3, 2016 at 1:05 PM, Spencer Ryan wrote: > >> There is no way for Netflix to know the difference between you being in >> NY and using the tunnel, and you living in Hong Kong and using the tunnel. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >> wrote: >> >>> Same, but until there's a real IPv6 presence in the US, it's really >>> annoying that they haven't come up with some fix for this. >>> >>> I have no plans to turn off IPv6 at home - I actually have many uses for >>> it, and as much as I dislike the controversy around it, think that adoption >>> needs to be prioritized, not penalized. >>> >>> Additionally, I think that discussing content provider control over >>> regional decisions isn't productive to the conversation, as they didn't >>> build the banhammer (wouldn't you want to control your own content if you >>> had made content specific to regional laws etc?). >>> >>> I.e. - not all shows need to have regional restrictions between New York >>> (where I live) and California (where my IPv6 /64 says I live). >>> >>> I'm able to watch House in the any state in the U.S.? Great - ignore my >>> intra-US proxy connection. >>> >>> My Netflix account randomly tries to connect from Tokyo because I forgot >>> to shut off my work VPN? Fine....let me know and I'll turn *that* off. >>> >>> >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >>> >>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>> broker. I'm sure their content providers are forcing their hand. >>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>> wrote: >>>> >>>>> Netflix needs to figure out a fix for this until ISPs actually provide >>>>> IPv6 >>>>> natively. >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>> wrote: >>>>> >>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked by >>>>> > Netflix. Anyone nice people from Netflix perhaps want to take a >>>>> crack at >>>>> > this? >>>>> > >>>>> > >>>>> > >>>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>>> > >>>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>>> > connection >>>>> > > to HE. Turned of V6 and the device worked. >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > >>>>> > > Sent with Airmail >>>>> > > >>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>> matthew at matthew.at) >>>>> > > wrote: >>>>> > > >>>>> > > Every device in my house is blocked from Netflix this evening due >>>>> to >>>>> > > their new "VPN blocker". My house is on my own IP space, and the >>>>> outside >>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>> announced >>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house >>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>> microwaves >>>>> > > fly. >>>>> > > >>>>> > > Unfortunately, when one calls Netflix support to talk about this, >>>>> the >>>>> > > only response is to say "call your ISP and have them turn off the >>>>> VPN >>>>> > > software they've added to your account". And they absolutely >>>>> refuse to >>>>> > > escalate. Even if you tell them that you are essentially your own >>>>> ISP. >>>>> > > >>>>> > > So... where's the Netflix network engineer on the list who all of >>>>> us can >>>>> > > send these issues to directly? >>>>> > > >>>>> > > Matthew Kaufman >>>>> > > >>>>> > >>>>> >>>> >> > From laszlo at heliacal.net Fri Jun 3 21:07:15 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 3 Jun 2016 21:07:15 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> On 2016-06-03 19:37, Matthew Huff wrote: > I would imagine it was done on purpose. The purpose of the Netflix VPN detection was to block users from outside of different regions due to content providers requests. Since HE provides free ipv6 tunnels, it's an easy way to get around the blockage, hence the restriction. > > I know this isn't news to anyone on the list but I want to point out that the root of this problem is in trying to attach an Earth location to a network packet. The only good solution we have for this is to ASK the user where they are located. Netflix has a broken system that is causing a lot of collateral damage because the whole thing is based on the premise that they can determine where the users are by guessing. If you just got your netblock it's probably going to be banned because it's not in their GeoIP database. Maybe if you jump through all the right hoops, in a few months time they will update the database. Working around it just sends the message that this is an acceptable practice and you will own the problems they caused. This a widespread problem and not specific to Netflix. There's also another angle to this in that old IP addresses (that work with Netflix/youtube/whatever) become more valuable and newly registered netblocks (like the ones everyone should be getting for IPv6) are not useful. This might be a good way to keep new ISPs out too, unless they can pay for a well aged IPv4 block so their subscribers can access Netflix and friends. -Laszlo From SNaslund at medline.com Fri Jun 3 21:09:24 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 21:09:24 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A059@MUNPRDMBXA1.medline.com> Well, that's the rub of the whole issue with Netflix VPN detection. They don't actually detect the VPN, they detect a bunch of people coming from the same IP address which they assume to be done via a VPN or proxy. Any large networks sitting behind a single NAT are going to get looked at that way. If everyone was using a VPN to their home and jumping through that to get to Netflix it would be nearly impossible to detect reliably (I know you could play games with MTU detection and stuff like that but those will give even more false positives). The big fight is coming when Netflix is going to have to get real with the content providers and admit that there is no reliable way to regionalize. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Blair Trosper Sent: Friday, June 03, 2016 4:00 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed I dunno. I could argue that I could -- to extend that idea -- let literally ANYONE tunnel through my Comcast Business connection to appear to be in the Bay Area. How's that fundamentally different than a service like TunnelBroker apart from economies of scale? More than a few people I know are ready to dump Netflix for this. Fortunately, where I live, Comcast Business has native dual stack... On Fri, Jun 3, 2016 at 1:05 PM, Spencer Ryan wrote: > There is no way for Netflix to know the difference between you being > in NY and using the tunnel, and you living in Hong Kong and using the tunnel. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > > wrote: > >> Same, but until there's a real IPv6 presence in the US, it's really >> annoying that they haven't come up with some fix for this. >> >> I have no plans to turn off IPv6 at home - I actually have many uses >> for it, and as much as I dislike the controversy around it, think >> that adoption needs to be prioritized, not penalized. >> >> Additionally, I think that discussing content provider control over >> regional decisions isn't productive to the conversation, as they >> didn't build the banhammer (wouldn't you want to control your own >> content if you had made content specific to regional laws etc?). >> >> I.e. - not all shows need to have regional restrictions between New >> York (where I live) and California (where my IPv6 /64 says I live). >> >> I'm able to watch House in the any state in the U.S.? Great - ignore >> my intra-US proxy connection. >> >> My Netflix account randomly tries to connect from Tokyo because I >> forgot to shut off my work VPN? Fine....let me know and I'll turn *that* off. >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan wrote: >> >>> I don't blame them for blocking a (effectively) anonymous tunnel broker. >>> I'm sure their content providers are forcing their hand. >>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>> wrote: >>> >>>> Netflix needs to figure out a fix for this until ISPs actually >>>> provide >>>> IPv6 >>>> natively. >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>> >>>> wrote: >>>> >>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>> > by Netflix. Anyone nice people from Netflix perhaps want to take >>>> > a >>>> crack at >>>> > this? >>>> > >>>> > >>>> > >>>> > On Thu, Jun 2, 2016 at 2:15 PM, wrote: >>>> > >>>> > > Had the same problem at my house, but it was caused by the IPv6 >>>> > connection >>>> > > to HE. Turned of V6 and the device worked. >>>> > > >>>> > > >>>> > > -- >>>> > > >>>> > > Sent with Airmail >>>> > > >>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman >>>> > > (matthew at matthew.at >>>> ) >>>> > > wrote: >>>> > > >>>> > > Every device in my house is blocked from Netflix this evening >>>> > > due to their new "VPN blocker". My house is on my own IP space, >>>> > > and the >>>> outside >>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>> announced >>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>> > > house should show that I'm no farther away than Santa Cruz, CA >>>> > > as >>>> microwaves >>>> > > fly. >>>> > > >>>> > > Unfortunately, when one calls Netflix support to talk about >>>> > > this, >>>> the >>>> > > only response is to say "call your ISP and have them turn off >>>> > > the >>>> VPN >>>> > > software they've added to your account". And they absolutely >>>> > > refuse >>>> to >>>> > > escalate. Even if you tell them that you are essentially your >>>> > > own >>>> ISP. >>>> > > >>>> > > So... where's the Netflix network engineer on the list who all >>>> > > of >>>> us can >>>> > > send these issues to directly? >>>> > > >>>> > > Matthew Kaufman >>>> > > >>>> > >>>> >>> > From nanog at ics-il.net Fri Jun 3 21:16:54 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 3 Jun 2016 16:16:54 -0500 (CDT) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> Message-ID: <2001068920.6149.1464988611138.JavaMail.mhammett@ThunderFuck> As bad as some are in the telecom industry, they don't hold a candle to those in the content industry. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Friday, June 3, 2016 3:55:43 PM Subject: RE: Netflix VPN detection - actual engineer needed Wifi location depends on a bunch of problematic things. First, your SSID needs to get collected and put in a database somewhere. That itself is a crap shoot. Next, you can stop google (and some other wifi databases) from collecting the data by putting _nomap at the end of your SSID. Lastly, not everyone has wifi or iOS or GPS or whatever location method you can think of. BTW, my apple TV is on a wired Ethernet, not wifi. Point is, for whatever location technology you want to use be it IP, GPS, WiFi location, sextant?..they can be inaccurate and they can be faked and there are privacy concerns with all of them. What the content producers need to figure out is that regionalization DOES NOT WORK ANYMORE! The original point was that they could have different release dates in different areas at different prices and availability. They are going to have to get over it because they will lose the technological arms race. There is no reason you could not beat all of the location systems with a simple proxy. A proxy makes a Netflix connection from an allowed IP, location or whatever and then builds a new video/audio stream out the back end to the client anywhere in the world. Simple to implement and damn near impossible to beat. Ever hear of Slingbox? Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 3:42 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > wrote: Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan > wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan > wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >>> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan > wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> > >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> >>>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, > wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From marka at isc.org Fri Jun 3 21:28:08 2016 From: marka at isc.org (Mark Andrews) Date: Sat, 04 Jun 2016 07:28:08 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Fri, 03 Jun 2016 21:07:15 +0000." <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> Message-ID: <20160603212808.61A794AC8EC8@rock.dv.isc.org> It's time for Netflix to offer IPv6 tunnels. That way they can correlate IPv4 and IPv6 addresses. Longest match will result is the correct source address being selected if they do the job correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From SNaslund at medline.com Fri Jun 3 21:40:54 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 21:40:54 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2001068920.6149.1464988611138.JavaMail.mhammett@ThunderFuck> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <2001068920.6149.1464988611138.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A094@MUNPRDMBXA1.medline.com> True, I thought digital distribution almost killed them. Then they started to understand that Netflix and iTunes are the new normal and got on board (kicking and screaming). Now, they get all torn up over the completely outdated concept of regionalization that should have died along with physical media distribution. Do they honestly believe that they can prevent some guy in Pakistan from seeing a movie they want? Don't they know that in most third world areas you can find PRE-RELEASE DVDs before stuff hits the theaters in the U.S.? You would think that they would welcome someone actually using a legitimate distribution medium rather than the traditional black market method. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Friday, June 03, 2016 4:17 PM Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed As bad as some are in the telecom industry, they don't hold a candle to those in the content industry. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Friday, June 3, 2016 3:55:43 PM Subject: RE: Netflix VPN detection - actual engineer needed Wifi location depends on a bunch of problematic things. First, your SSID needs to get collected and put in a database somewhere. That itself is a crap shoot. Next, you can stop google (and some other wifi databases) from collecting the data by putting _nomap at the end of your SSID. Lastly, not everyone has wifi or iOS or GPS or whatever location method you can think of. BTW, my apple TV is on a wired Ethernet, not wifi. Point is, for whatever location technology you want to use be it IP, GPS, WiFi location, sextant?..they can be inaccurate and they can be faked and there are privacy concerns with all of them. What the content producers need to figure out is that regionalization DOES NOT WORK ANYMORE! The original point was that they could have different release dates in different areas at different prices and availability. They are going to have to get over it because they will lose the technological arms race. There is no reason you could not beat all of the location systems with a simple proxy. A proxy makes a Netflix connection from an allowed IP, location or whatever and then builds a new video/audio stream out the back end to the client anywhere in the world. Simple to implement and damn near impossible to beat. Ever hear of Slingbox? Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 3:42 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > wrote: Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan > wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | > sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan > wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | >>> sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >>> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan > wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> > >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> >>>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, > wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From sryan at arbor.net Fri Jun 3 21:48:42 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 17:48:42 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A094@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <2001068920.6149.1464988611138.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B401E661A094@MUNPRDMBXA1.medline.com> Message-ID: > Do they honestly believe that they can prevent some guy in Pakistan from seeing a movie they want? The content providers do. And given the choice between "Try and stop vpn users" and "We are pulling all our content" I know which most people would rather. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 5:40 PM, Naslund, Steve wrote: > True, I thought digital distribution almost killed them. Then they > started to understand that Netflix and iTunes are the new normal and got on > board (kicking and screaming). Now, they get all torn up over the > completely outdated concept of regionalization that should have died along > with physical media distribution. Do they honestly believe that they can > prevent some guy in Pakistan from seeing a movie they want? Don't they > know that in most third world areas you can find PRE-RELEASE DVDs before > stuff hits the theaters in the U.S.? You would think that they would > welcome someone actually using a legitimate distribution medium rather than > the traditional black market method. > > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Friday, June 03, 2016 4:17 PM > Cc: nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > As bad as some are in the telecom industry, they don't hold a candle to > those in the content industry. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Steve Naslund" > To: nanog at nanog.org > Sent: Friday, June 3, 2016 3:55:43 PM > Subject: RE: Netflix VPN detection - actual engineer needed > > Wifi location depends on a bunch of problematic things. First, your SSID > needs to get collected and put in a database somewhere. That itself is a > crap shoot. Next, you can stop google (and some other wifi databases) from > collecting the data by putting _nomap at the end of your SSID. Lastly, not > everyone has wifi or iOS or GPS or whatever location method you can think > of. BTW, my apple TV is on a wired Ethernet, not wifi. > > Point is, for whatever location technology you want to use be it IP, GPS, > WiFi location, sextant?..they can be inaccurate and they can be faked and > there are privacy concerns with all of them. What the content producers > need to figure out is that regionalization DOES NOT WORK ANYMORE! The > original point was that they could have different release dates in > different areas at different prices and availability. They are going to > have to get over it because they will lose the technological arms race. > > There is no reason you could not beat all of the location systems with a > simple proxy. A proxy makes a Netflix connection from an allowed IP, > location or whatever and then builds a new video/audio stream out the back > end to the client anywhere in the world. Simple to implement and damn near > impossible to beat. Ever hear of Slingbox? > > Steven Naslund > Chicago IL > > From: Cryptographrix [mailto:cryptographrix at gmail.com] > Sent: Friday, June 03, 2016 3:42 PM > To: Naslund, Steve; nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > Apple TVs get their location indoors using the same method they use for > other iOS devices when indoors - wifi ssid/Mac scanning. > > Non-iOS devices are often capable of this as well. > > (As someone that spends >67% of his time underground and whose Apple TV > requests my location from my underground bedroom and is very accurate) > > On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > wrote: > Their app could request your devices location. Problem is a lot of devices > (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) > don't know where they are and it cannot easily be added (indoor GPS is > still difficult/expensive) and even if they could should they be believed. > I think the bigger issue is whether any kind of regional controls are > enforceable or effective any more. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] > On Behalf Of Cryptographrix > Sent: Friday, June 03, 2016 3:21 PM > To: Spencer Ryan > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > Come now, content providers really just care that they have access to > regional controls more so than their ability to blanket-deny access (ok, > minus the MLB who are just insane). > > And part of those regional controls deal with the accuracy of the location > information. > > If their app can request my device's precise location, it doesn't need to > infer my location from my IP any more. > > As a matter of fact, it's only detrimental to them for it to do so, > because of the lack of accuracy from geo databases and the various reasons > that people use VPNs nowadays (i.e. for some devices that you can't even > turn VPN connections off for - OR in the case of IPv6, when you can't reach > a segment of the Internet without it). > > > On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan sryan at arbor.net>> wrote: > > > There is a large difference between "the VPN run at your house" and > > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > > > If it were up to the content providers, they probably would block any > > IP they saw a VPN server listening on. > > > > > > *Spencer Ryan* | Senior Systems Administrator | > > sryan at arbor.net *Arbor > > Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > > > wrote: > > > >> I have a VPN connection at my house. There's no way for them to know > >> the difference between me using my home network connection from Hong > >> Kong or my home network connection from my house. > >> > >> Are they going to disable connectivity from everywhere they can > >> detect an open VPN port to, also? > >> > >> If they trust my v4 address, they can use that to establish > >> historical reference. Additionally, they can fail over to v4 if they > >> do not trust the > >> v6 address. > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan sryan at arbor.net>> wrote: > >> > >>> There is no way for Netflix to know the difference between you being > >>> in NY and using the tunnel, and you living in Hong Kong and using the > tunnel. > >>> > >>> > >>> *Spencer Ryan* | Senior Systems Administrator | > >>> sryan at arbor.net > >>> *Arbor Networks* > >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>> www.arbornetworks.com > >>> > >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > >>> > >>> > wrote: > >>> > >>>> Same, but until there's a real IPv6 presence in the US, it's really > >>>> annoying that they haven't come up with some fix for this. > >>>> > >>>> I have no plans to turn off IPv6 at home - I actually have many > >>>> uses for it, and as much as I dislike the controversy around it, > >>>> think that adoption needs to be prioritized, not penalized. > >>>> > >>>> Additionally, I think that discussing content provider control over > >>>> regional decisions isn't productive to the conversation, as they > >>>> didn't build the banhammer (wouldn't you want to control your own > >>>> content if you had made content specific to regional laws etc?). > >>>> > >>>> I.e. - not all shows need to have regional restrictions between New > >>>> York (where I live) and California (where my IPv6 /64 says I live). > >>>> > >>>> I'm able to watch House in the any state in the U.S.? Great - > >>>> ignore my intra-US proxy connection. > >>>> > >>>> My Netflix account randomly tries to connect from Tokyo because I > >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn > >>>> *that* off. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan sryan at arbor.net>> wrote: > >>>> > >>>>> I don't blame them for blocking a (effectively) anonymous tunnel > >>>>> broker. I'm sure their content providers are forcing their hand. > >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" > >>>>> > > >>>>> wrote: > >>>>> > >>>>>> Netflix needs to figure out a fix for this until ISPs actually > >>>>>> provide IPv6 natively. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > >>>>>> > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked > >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to > >>>>>> > take a > >>>>>> crack at > >>>>>> > this? > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, mike.hyde1 at gmail.com>> wrote: > >>>>>> > > >>>>>> > > Had the same problem at my house, but it was caused by the > >>>>>> > > IPv6 > >>>>>> > connection > >>>>>> > > to HE. Turned of V6 and the device worked. > >>>>>> > > > >>>>>> > > > >>>>>> > > -- > >>>>>> > > > >>>>>> > > Sent with Airmail > >>>>>> > > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( > >>>>>> matthew at matthew.at) > >>>>>> > > wrote: > >>>>>> > > > >>>>>> > > Every device in my house is blocked from Netflix this evening > >>>>>> > > due > >>>>>> to > >>>>>> > > their new "VPN blocker". My house is on my own IP space, and > >>>>>> > > the > >>>>>> outside > >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, > >>>>>> announced > >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my > >>>>>> house > >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as > >>>>>> microwaves > >>>>>> > > fly. > >>>>>> > > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about > >>>>>> > > this, > >>>>>> the > >>>>>> > > only response is to say "call your ISP and have them turn off > >>>>>> > > the > >>>>>> VPN > >>>>>> > > software they've added to your account". And they absolutely > >>>>>> refuse to > >>>>>> > > escalate. Even if you tell them that you are essentially your > >>>>>> > > own > >>>>>> ISP. > >>>>>> > > > >>>>>> > > So... where's the Netflix network engineer on the list who > >>>>>> > > all of > >>>>>> us can > >>>>>> > > send these issues to directly? > >>>>>> > > > >>>>>> > > Matthew Kaufman > >>>>>> > > > >>>>>> > > >>>>>> > >>>>> > >>> > > > > From SNaslund at medline.com Fri Jun 3 21:51:38 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 21:51:38 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160603212808.61A794AC8EC8@rock.dv.isc.org> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> Actually it's time for Netflix to get out of the network transport business and tell the content providers to get over it or not get carried on Netflix. It used to be that Netflix needed content providers, now I am starting to believe it might be the other way around. Netflix might have to take a page from the satellite guys and start calling them out publicly. i.e. "Netflix will no longer be able to provide you with Warner Bros. content because they are dinosaurs that are worried that someone might be watching in the wrong country. We are pleased to offer you content from producers that are not complete morons...." As the content producers lose more and more control over the distribution channel they are going to take whatever terms are necessary to get them on Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not on any or all of those platforms, you are going to be dead meat. Who would be hurt worse, Netflix or the movie producer that got seen nowhere on their latest film. To me, this is the last gasp of an industry that lost control of its distribution channel years ago and is still trying to impose that control. Steven Naslund -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Friday, June 03, 2016 4:28 PM To: Laszlo Hanyecz Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed It's time for Netflix to offer IPv6 tunnels. That way they can correlate IPv4 and IPv6 addresses. Longest match will result is the correct source address being selected if they do the job correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cryptographrix at gmail.com Fri Jun 3 21:56:23 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 21:56:23 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> Message-ID: Oh I'm not suggesting for a microsecond that any provenance of location can not be hacked, but I totally think that - until the content providers change their business model to not rely on regional controls - they could at least use a more accurate source for that information than my IP(4 or 6) address. I just don't think that this is an appropriate venue to discuss the value of their business model as that's something their business needs to work on changing internally, and fighting it (at least for the moment) will only land Netflix in court. In short, I'm pointing the finger at Netflix's developers for coming up with such a lazy control for geolocation. On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve wrote: > Wifi location depends on a bunch of problematic things. First, your SSID > needs to get collected and put in a database somewhere. That itself is a > crap shoot. Next, you can stop google (and some other wifi databases) from > collecting the data by putting _nomap at the end of your SSID. Lastly, not > everyone has wifi or iOS or GPS or whatever location method you can think > of. BTW, my apple TV is on a wired Ethernet, not wifi. > > Point is, for whatever location technology you want to use be it IP, GPS, > WiFi location, sextant?..they can be inaccurate and they can be faked and > there are privacy concerns with all of them. What the content producers > need to figure out is that regionalization DOES NOT WORK ANYMORE! The > original point was that they could have different release dates in > different areas at different prices and availability. They are going to > have to get over it because they will lose the technological arms race. > > There is no reason you could not beat all of the location systems with a > simple proxy. A proxy makes a Netflix connection from an allowed IP, > location or whatever and then builds a new video/audio stream out the back > end to the client anywhere in the world. Simple to implement and damn near > impossible to beat. Ever hear of Slingbox? > > Steven Naslund > Chicago IL > > From: Cryptographrix [mailto:cryptographrix at gmail.com] > Sent: Friday, June 03, 2016 3:42 PM > To: Naslund, Steve; nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > Apple TVs get their location indoors using the same method they use for > other iOS devices when indoors - wifi ssid/Mac scanning. > > Non-iOS devices are often capable of this as well. > > (As someone that spends >67% of his time underground and whose Apple TV > requests my location from my underground bedroom and is very accurate) > > On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > wrote: > Their app could request your devices location. Problem is a lot of > devices (like TVs, Apple TVs, most DVD player, i.e. device with built in > Netflix) don't know where they are and it cannot easily be added (indoor > GPS is still difficult/expensive) and even if they could should they be > believed. I think the bigger issue is whether any kind of regional > controls are enforceable or effective any more. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] > On Behalf Of Cryptographrix > Sent: Friday, June 03, 2016 3:21 PM > To: Spencer Ryan > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > Come now, content providers really just care that they have access to > regional controls more so than their ability to blanket-deny access (ok, > minus the MLB who are just insane). > > And part of those regional controls deal with the accuracy of the location > information. > > If their app can request my device's precise location, it doesn't need to > infer my location from my IP any more. > > As a matter of fact, it's only detrimental to them for it to do so, > because of the lack of accuracy from geo databases and the various reasons > that people use VPNs nowadays (i.e. for some devices that you can't even > turn VPN connections off for - OR in the case of IPv6, when you can't reach > a segment of the Internet without it). > > > On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan sryan at arbor.net>> wrote: > > > There is a large difference between "the VPN run at your house" and > > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > > > If it were up to the content providers, they probably would block any > > IP they saw a VPN server listening on. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net sryan at arbor.net> *Arbor > > Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > > > > wrote: > > > >> I have a VPN connection at my house. There's no way for them to know > >> the difference between me using my home network connection from Hong > >> Kong or my home network connection from my house. > >> > >> Are they going to disable connectivity from everywhere they can > >> detect an open VPN port to, also? > >> > >> If they trust my v4 address, they can use that to establish > >> historical reference. Additionally, they can fail over to v4 if they > >> do not trust the > >> v6 address. > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan sryan at arbor.net>> wrote: > >> > >>> There is no way for Netflix to know the difference between you being > >>> in NY and using the tunnel, and you living in Hong Kong and using the > tunnel. > >>> > >>> > >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > >>> *Arbor Networks* > >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>> www.arbornetworks.com > >>> > >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > >>> > >>> > wrote: > >>> > >>>> Same, but until there's a real IPv6 presence in the US, it's really > >>>> annoying that they haven't come up with some fix for this. > >>>> > >>>> I have no plans to turn off IPv6 at home - I actually have many > >>>> uses for it, and as much as I dislike the controversy around it, > >>>> think that adoption needs to be prioritized, not penalized. > >>>> > >>>> Additionally, I think that discussing content provider control over > >>>> regional decisions isn't productive to the conversation, as they > >>>> didn't build the banhammer (wouldn't you want to control your own > >>>> content if you had made content specific to regional laws etc?). > >>>> > >>>> I.e. - not all shows need to have regional restrictions between New > >>>> York (where I live) and California (where my IPv6 /64 says I live). > >>>> > >>>> I'm able to watch House in the any state in the U.S.? Great - > >>>> ignore my intra-US proxy connection. > >>>> > >>>> My Netflix account randomly tries to connect from Tokyo because I > >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn > >>>> *that* off. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan sryan at arbor.net>> wrote: > >>>> > >>>>> I don't blame them for blocking a (effectively) anonymous tunnel > >>>>> broker. I'm sure their content providers are forcing their hand. > >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" > >>>>> > > >>>>> wrote: > >>>>> > >>>>>> Netflix needs to figure out a fix for this until ISPs actually > >>>>>> provide IPv6 natively. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > >>>>>> > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked > >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to > >>>>>> > take a > >>>>>> crack at > >>>>>> > this? > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, mike.hyde1 at gmail.com>> wrote: > >>>>>> > > >>>>>> > > Had the same problem at my house, but it was caused by the > >>>>>> > > IPv6 > >>>>>> > connection > >>>>>> > > to HE. Turned of V6 and the device worked. > >>>>>> > > > >>>>>> > > > >>>>>> > > -- > >>>>>> > > > >>>>>> > > Sent with Airmail > >>>>>> > > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( > >>>>>> matthew at matthew.at) > >>>>>> > > wrote: > >>>>>> > > > >>>>>> > > Every device in my house is blocked from Netflix this evening > >>>>>> > > due > >>>>>> to > >>>>>> > > their new "VPN blocker". My house is on my own IP space, and > >>>>>> > > the > >>>>>> outside > >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, > >>>>>> announced > >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my > >>>>>> house > >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as > >>>>>> microwaves > >>>>>> > > fly. > >>>>>> > > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about > >>>>>> > > this, > >>>>>> the > >>>>>> > > only response is to say "call your ISP and have them turn off > >>>>>> > > the > >>>>>> VPN > >>>>>> > > software they've added to your account". And they absolutely > >>>>>> refuse to > >>>>>> > > escalate. Even if you tell them that you are essentially your > >>>>>> > > own > >>>>>> ISP. > >>>>>> > > > >>>>>> > > So... where's the Netflix network engineer on the list who > >>>>>> > > all of > >>>>>> us can > >>>>>> > > send these issues to directly? > >>>>>> > > > >>>>>> > > Matthew Kaufman > >>>>>> > > > >>>>>> > > >>>>>> > >>>>> > >>> > > > From nanog at ics-il.net Fri Jun 3 22:00:08 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 3 Jun 2016 17:00:08 -0500 (CDT) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> Message-ID: <2032482050.6202.1464991206628.JavaMail.mhammett@ThunderFuck> It might be a few years yet before the new channels have that much power. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Friday, June 3, 2016 4:51:38 PM Subject: RE: Netflix VPN detection - actual engineer needed Actually it's time for Netflix to get out of the network transport business and tell the content providers to get over it or not get carried on Netflix. It used to be that Netflix needed content providers, now I am starting to believe it might be the other way around. Netflix might have to take a page from the satellite guys and start calling them out publicly. i.e. "Netflix will no longer be able to provide you with Warner Bros. content because they are dinosaurs that are worried that someone might be watching in the wrong country. We are pleased to offer you content from producers that are not complete morons...." As the content producers lose more and more control over the distribution channel they are going to take whatever terms are necessary to get them on Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not on any or all of those platforms, you are going to be dead meat. Who would be hurt worse, Netflix or the movie producer that got seen nowhere on their latest film. To me, this is the last gasp of an industry that lost control of its distribution channel years ago and is still trying to impose that control. Steven Naslund -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Friday, June 03, 2016 4:28 PM To: Laszlo Hanyecz Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed It's time for Netflix to offer IPv6 tunnels. That way they can correlate IPv4 and IPv6 addresses. Longest match will result is the correct source address being selected if they do the job correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cryptographrix at gmail.com Fri Jun 3 22:00:53 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 22:00:53 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160603212808.61A794AC8EC8@rock.dv.isc.org> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> Message-ID: +1 to this idea. On Fri, Jun 3, 2016 at 5:29 PM Mark Andrews wrote: > > It's time for Netflix to offer IPv6 tunnels. That way they can > correlate IPv4 and IPv6 addresses. Longest match will result is > the correct source address being selected if they do the job > correctly. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From SNaslund at medline.com Fri Jun 3 22:03:28 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 22:03:28 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> That is true. The problem is that traditionally the ISPs have to deal with customers that can?t get to the content they want. Netflix ridiculous detection schemes do nothing but create tons of work for the service provider which in turn creates stupid work-arounds and network configurations that are ill conceived. Myself, I had to shut off IPv6 at home to get things to work reliably several times for dumb reasons. Kind of hard to preach the v6 message when I had to shut it off myself several time to get my own stuff to work Ok. Netflix just decided that creating issues for a subset of their customers was better than having the real fight with the content providers. My point is that there is no reliable geo-location method for Netflix to use, at least there never has been yet. Good luck ever getting that to work behind the great firewall of China. Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 4:56 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Oh I'm not suggesting for a microsecond that any provenance of location can not be hacked, but I totally think that - until the content providers change their business model to not rely on regional controls - they could at least use a more accurate source for that information than my IP(4 or 6) address. I just don't think that this is an appropriate venue to discuss the value of their business model as that's something their business needs to work on changing internally, and fighting it (at least for the moment) will only land Netflix in court. In short, I'm pointing the finger at Netflix's developers for coming up with such a lazy control for geolocation. On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve > wrote: Wifi location depends on a bunch of problematic things. First, your SSID needs to get collected and put in a database somewhere. That itself is a crap shoot. Next, you can stop google (and some other wifi databases) from collecting the data by putting _nomap at the end of your SSID. Lastly, not everyone has wifi or iOS or GPS or whatever location method you can think of. BTW, my apple TV is on a wired Ethernet, not wifi. Point is, for whatever location technology you want to use be it IP, GPS, WiFi location, sextant?..they can be inaccurate and they can be faked and there are privacy concerns with all of them. What the content producers need to figure out is that regionalization DOES NOT WORK ANYMORE! The original point was that they could have different release dates in different areas at different prices and availability. They are going to have to get over it because they will lose the technological arms race. There is no reason you could not beat all of the location systems with a simple proxy. A proxy makes a Netflix connection from an allowed IP, location or whatever and then builds a new video/audio stream out the back end to the client anywhere in the world. Simple to implement and damn near impossible to beat. Ever hear of Slingbox? Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 3:42 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve >> wrote: Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org>] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan >> wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net> *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > >> > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan >> wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net> >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> > >>> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan >> wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> >> >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> > >>>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, >> wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at>) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From eric.kuhnke at gmail.com Fri Jun 3 22:03:49 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 3 Jun 2016 15:03:49 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> Message-ID: >From a network operational perspective we are only seeing the tip of the iceberg. There are vast hordes of lawyers and MBA types employed by the largest content creators (TV channels, movie studios) which negotiate agreements with Netflix and similar services. Unless you happen to be a sysadmin inside one of these entities with access to the contracts and documents, all of this is totally opaque from a network engineering viewpoint. I do not think the contractual requirement to *attempt* to block VPN traffic will change until a significantly larger percentage of US customers abandon paying for their cable TV & satellite TV monthly packages. On Fri, Jun 3, 2016 at 2:56 PM, Cryptographrix wrote: > I just don't think that this is an appropriate venue to discuss the value > of their business model as that's something their business needs to work on > changing internally, and fighting it (at least for the moment) will only > land Netflix in court. > > From cryptographrix at gmail.com Fri Jun 3 22:06:07 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 22:06:07 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> Message-ID: There's really no point in whining about content providers and regionalization as long as TV channels are still a thing. I get that the internet totally annihilated borders of all kind (including the book store), but some businesses change slower than others, and content production is still back in the black-and-white TV days because even new content producers don't have that new of a business model. But nor are ISPs coming up with novel ways for distributors to offer more reliable regionalization services (and most of them were in the content regionalization business long before the Internet came around). Pick one of those two problems and make a business to solve them. Until then, Netflix's developers could at least use the "novel" solution of tiering the most accurate forms of location before hitting IP geolocation. On Fri, Jun 3, 2016 at 5:52 PM Naslund, Steve wrote: > Actually it's time for Netflix to get out of the network transport > business and tell the content providers to get over it or not get carried > on Netflix. It used to be that Netflix needed content providers, now I am > starting to believe it might be the other way around. Netflix might have > to take a page from the satellite guys and start calling them out > publicly. i.e. "Netflix will no longer be able to provide you with Warner > Bros. content because they are dinosaurs that are worried that someone > might be watching in the wrong country. We are pleased to offer you > content from producers that are not complete morons...." > > As the content producers lose more and more control over the distribution > channel they are going to take whatever terms are necessary to get them on > Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not > on any or all of those platforms, you are going to be dead meat. Who > would be hurt worse, Netflix or the movie producer that got seen nowhere on > their latest film. To me, this is the last gasp of an industry that lost > control of its distribution channel years ago and is still trying to impose > that control. > > Steven Naslund > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews > Sent: Friday, June 03, 2016 4:28 PM > To: Laszlo Hanyecz > Cc: nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > > It's time for Netflix to offer IPv6 tunnels. That way they can correlate > IPv4 and IPv6 addresses. Longest match will result is the correct source > address being selected if they do the job correctly. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From SNaslund at medline.com Fri Jun 3 22:06:48 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 22:06:48 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2032482050.6202.1464991206628.JavaMail.mhammett@ThunderFuck> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <2032482050.6202.1464991206628.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A112@MUNPRDMBXA1.medline.com> I kind of doubt it. If any major studio knew that their movie would not be on one of those platforms I think it would be a major problem for them right now. One theater out of thousands is not a problem. iTunes or Netflix has to be what....50% of online distribution today. That's gotta hurt. iTunes already changed the music game and was able to impose their will concerning producer side DRM and other policies. I'm sure Apple and Netflix have at least that much power in the movie space already. Steven Naslund -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Friday, June 03, 2016 5:00 PM Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed It might be a few years yet before the new channels have that much power. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Friday, June 3, 2016 4:51:38 PM Subject: RE: Netflix VPN detection - actual engineer needed Actually it's time for Netflix to get out of the network transport business and tell the content providers to get over it or not get carried on Netflix. It used to be that Netflix needed content providers, now I am starting to believe it might be the other way around. Netflix might have to take a page from the satellite guys and start calling them out publicly. i.e. "Netflix will no longer be able to provide you with Warner Bros. content because they are dinosaurs that are worried that someone might be watching in the wrong country. We are pleased to offer you content from producers that are not complete morons...." As the content producers lose more and more control over the distribution channel they are going to take whatever terms are necessary to get them on Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not on any or all of those platforms, you are going to be dead meat. Who would be hurt worse, Netflix or the movie producer that got seen nowhere on their latest film. To me, this is the last gasp of an industry that lost control of its distribution channel years ago and is still trying to impose that control. Steven Naslund -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Friday, June 03, 2016 4:28 PM To: Laszlo Hanyecz Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed It's time for Netflix to offer IPv6 tunnels. That way they can correlate IPv4 and IPv6 addresses. Longest match will result is the correct source address being selected if they do the job correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cryptographrix at gmail.com Fri Jun 3 22:18:29 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 22:18:29 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> Message-ID: "there is no reliable geo-location method for Netflix to use" Any microprocessor that is connected to the Internet is subject to being hacked - let's just turn off all of our computers, since we're talking in absolutes. >From the perspective of the "lawyers and MBA types that negotiate agreements with Netflix and similar services" (to quote Eric), there *are* reliable methods within a specific risk profile, and those include (thanks to Google and Apple, whom most of the content providers *also* have agreements with) AGPS based on Wifi and other industry now-standard methods. I don't think there _is_ a contractual requirement to attempt to block VPN traffic. I think there's a contractual requirement to provide geographic controls for content, which is a completely different discussion, and is what those same cable and satellite TV providers (many of which _are_ the ISPs for Netflix's customer base) provide. As has been pointed out, Slingbox is an excellent proxy for over-the-air and cable-tv video, but you don't see content providers pressuring regulation on them because they limit their risk with the station or cable TV provider. On Fri, Jun 3, 2016 at 6:08 PM Naslund, Steve wrote: > That is true. The problem is that traditionally the ISPs have to deal > with customers that can?t get to the content they want. Netflix ridiculous > detection schemes do nothing but create tons of work for the service > provider which in turn creates stupid work-arounds and network > configurations that are ill conceived. Myself, I had to shut off IPv6 at > home to get things to work reliably several times for dumb reasons. Kind > of hard to preach the v6 message when I had to shut it off myself several > time to get my own stuff to work Ok. Netflix just decided that creating > issues for a subset of their customers was better than having the real > fight with the content providers. > > My point is that there is no reliable geo-location method for Netflix to > use, at least there never has been yet. Good luck ever getting that to > work behind the great firewall of China. > > Steven Naslund > Chicago IL > > From: Cryptographrix [mailto:cryptographrix at gmail.com] > Sent: Friday, June 03, 2016 4:56 PM > To: Naslund, Steve; nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > Oh I'm not suggesting for a microsecond that any provenance of location > can not be hacked, but I totally think that - until the content providers > change their business model to not rely on regional controls - they could > at least use a more accurate source for that information than my IP(4 or 6) > address. > > I just don't think that this is an appropriate venue to discuss the value > of their business model as that's something their business needs to work on > changing internally, and fighting it (at least for the moment) will only > land Netflix in court. > > In short, I'm pointing the finger at Netflix's developers for coming up > with such a lazy control for geolocation. > > On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve > wrote: > Wifi location depends on a bunch of problematic things. First, your SSID > needs to get collected and put in a database somewhere. That itself is a > crap shoot. Next, you can stop google (and some other wifi databases) from > collecting the data by putting _nomap at the end of your SSID. Lastly, not > everyone has wifi or iOS or GPS or whatever location method you can think > of. BTW, my apple TV is on a wired Ethernet, not wifi. > > Point is, for whatever location technology you want to use be it IP, GPS, > WiFi location, sextant?..they can be inaccurate and they can be faked and > there are privacy concerns with all of them. What the content producers > need to figure out is that regionalization DOES NOT WORK ANYMORE! The > original point was that they could have different release dates in > different areas at different prices and availability. They are going to > have to get over it because they will lose the technological arms race. > > There is no reason you could not beat all of the location systems with a > simple proxy. A proxy makes a Netflix connection from an allowed IP, > location or whatever and then builds a new video/audio stream out the back > end to the client anywhere in the world. Simple to implement and damn near > impossible to beat. Ever hear of Slingbox? > > Steven Naslund > Chicago IL > > From: Cryptographrix [mailto:cryptographrix at gmail.com cryptographrix at gmail.com>] > Sent: Friday, June 03, 2016 3:42 PM > To: Naslund, Steve; nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > Apple TVs get their location indoors using the same method they use for > other iOS devices when indoors - wifi ssid/Mac scanning. > > Non-iOS devices are often capable of this as well. > > (As someone that spends >67% of his time underground and whose Apple TV > requests my location from my underground bedroom and is very accurate) > > On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve SNaslund at medline.com>>> wrote: > Their app could request your devices location. Problem is a lot of > devices (like TVs, Apple TVs, most DVD player, i.e. device with built in > Netflix) don't know where they are and it cannot easily be added (indoor > GPS is still difficult/expensive) and even if they could should they be > believed. I think the bigger issue is whether any kind of regional > controls are enforceable or effective any more. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org >>] On > Behalf Of Cryptographrix > Sent: Friday, June 03, 2016 3:21 PM > To: Spencer Ryan > Cc: North American Network Operators' Group > Subject: Re: Netflix VPN detection - actual engineer needed > > Come now, content providers really just care that they have access to > regional controls more so than their ability to blanket-deny access (ok, > minus the MLB who are just insane). > > And part of those regional controls deal with the accuracy of the location > information. > > If their app can request my device's precise location, it doesn't need to > infer my location from my IP any more. > > As a matter of fact, it's only detrimental to them for it to do so, > because of the lack of accuracy from geo databases and the various reasons > that people use VPNs nowadays (i.e. for some devices that you can't even > turn VPN connections off for - OR in the case of IPv6, when you can't reach > a segment of the Internet without it). > > > On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan sryan at arbor.net>>> wrote: > > > There is a large difference between "the VPN run at your house" and > > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > > > If it were up to the content providers, they probably would block any > > IP they saw a VPN server listening on. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net sryan at arbor.net>> *Arbor > > Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com< > http://www.arbornetworks.com> > > > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > > cryptographrix at gmail.com>> > > wrote: > > > >> I have a VPN connection at my house. There's no way for them to know > >> the difference between me using my home network connection from Hong > >> Kong or my home network connection from my house. > >> > >> Are they going to disable connectivity from everywhere they can > >> detect an open VPN port to, also? > >> > >> If they trust my v4 address, they can use that to establish > >> historical reference. Additionally, they can fail over to v4 if they > >> do not trust the > >> v6 address. > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan sryan at arbor.net>>> wrote: > >> > >>> There is no way for Netflix to know the difference between you being > >>> in NY and using the tunnel, and you living in Hong Kong and using the > tunnel. > >>> > >>> > >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > > >>> *Arbor Networks* > >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>> www.arbornetworks.com< > http://www.arbornetworks.com> > >>> > >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix > >>> cryptographrix at gmail.com> > >>> > wrote: > >>> > >>>> Same, but until there's a real IPv6 presence in the US, it's really > >>>> annoying that they haven't come up with some fix for this. > >>>> > >>>> I have no plans to turn off IPv6 at home - I actually have many > >>>> uses for it, and as much as I dislike the controversy around it, > >>>> think that adoption needs to be prioritized, not penalized. > >>>> > >>>> Additionally, I think that discussing content provider control over > >>>> regional decisions isn't productive to the conversation, as they > >>>> didn't build the banhammer (wouldn't you want to control your own > >>>> content if you had made content specific to regional laws etc?). > >>>> > >>>> I.e. - not all shows need to have regional restrictions between New > >>>> York (where I live) and California (where my IPv6 /64 says I live). > >>>> > >>>> I'm able to watch House in the any state in the U.S.? Great - > >>>> ignore my intra-US proxy connection. > >>>> > >>>> My Netflix account randomly tries to connect from Tokyo because I > >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn > >>>> *that* off. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan sryan at arbor.net>>> wrote: > >>>> > >>>>> I don't blame them for blocking a (effectively) anonymous tunnel > >>>>> broker. I'm sure their content providers are forcing their hand. > >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" > >>>>> cryptographrix at gmail.com>> > >>>>> wrote: > >>>>> > >>>>>> Netflix needs to figure out a fix for this until ISPs actually > >>>>>> provide IPv6 natively. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper > >>>>>> blair.trosper at gmail.com> > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked > >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to > >>>>>> > take a > >>>>>> crack at > >>>>>> > this? > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, mike.hyde1 at gmail.com> mike.hyde1 at gmail.com>>> wrote: > >>>>>> > > >>>>>> > > Had the same problem at my house, but it was caused by the > >>>>>> > > IPv6 > >>>>>> > connection > >>>>>> > > to HE. Turned of V6 and the device worked. > >>>>>> > > > >>>>>> > > > >>>>>> > > -- > >>>>>> > > > >>>>>> > > Sent with Airmail > >>>>>> > > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( > >>>>>> matthew at matthew.at matthew at matthew.at>) > >>>>>> > > wrote: > >>>>>> > > > >>>>>> > > Every device in my house is blocked from Netflix this evening > >>>>>> > > due > >>>>>> to > >>>>>> > > their new "VPN blocker". My house is on my own IP space, and > >>>>>> > > the > >>>>>> outside > >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, > >>>>>> announced > >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my > >>>>>> house > >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as > >>>>>> microwaves > >>>>>> > > fly. > >>>>>> > > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about > >>>>>> > > this, > >>>>>> the > >>>>>> > > only response is to say "call your ISP and have them turn off > >>>>>> > > the > >>>>>> VPN > >>>>>> > > software they've added to your account". And they absolutely > >>>>>> refuse to > >>>>>> > > escalate. Even if you tell them that you are essentially your > >>>>>> > > own > >>>>>> ISP. > >>>>>> > > > >>>>>> > > So... where's the Netflix network engineer on the list who > >>>>>> > > all of > >>>>>> us can > >>>>>> > > send these issues to directly? > >>>>>> > > > >>>>>> > > Matthew Kaufman > >>>>>> > > > >>>>>> > > >>>>>> > >>>>> > >>> > > > From SNaslund at medline.com Fri Jun 3 22:18:46 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 22:18:46 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> ISPs should not be in the business of helping distributors come up with ?novel ways? to help them regionalize. It?s counterproductive to the ISPs main purpose which is to get their customers ?the whole Internet?, from anywhere to anywhere no matter where you are. As far as TV channels, that is an unrelated issue because they have their own distribution network, they can freely choose what cable systems and what satellite systems they want to license to. What you are NOT allowed to do is impose new requirements on our Internet to support your business licensing models and make it our problem. This is no different than someone like Microsoft saying ?hey service providers, we don?t want you to carry any network traffic from illegal copies of Outlook? and expecting us to figure it out. I know as service providers we have to be sensitive to our customers but Netflix is also a service provider and should be taking the heat from their own customers. Netflix authored a broken process and now we should be expected to re-engineer the network to eliminate V6 tunnel brokers?!?!?! I don?t think so Netflix. If I was still an ISP today, I would be sending all of my customers a memo explaining how badly Netflix VPN detection works and why it is so hard for us to help with it and why they should be complaining to Netflix. Steven Naslund From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 5:06 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed There's really no point in whining about content providers and regionalization as long as TV channels are still a thing. I get that the internet totally annihilated borders of all kind (including the book store), but some businesses change slower than others, and content production is still back in the black-and-white TV days because even new content producers don't have that new of a business model. But nor are ISPs coming up with novel ways for distributors to offer more reliable regionalization services (and most of them were in the content regionalization business long before the Internet came around). Pick one of those two problems and make a business to solve them. Until then, Netflix's developers could at least use the "novel" solution of tiering the most accurate forms of location before hitting IP geolocation. On Fri, Jun 3, 2016 at 5:52 PM Naslund, Steve > wrote: Actually it's time for Netflix to get out of the network transport business and tell the content providers to get over it or not get carried on Netflix. It used to be that Netflix needed content providers, now I am starting to believe it might be the other way around. Netflix might have to take a page from the satellite guys and start calling them out publicly. i.e. "Netflix will no longer be able to provide you with Warner Bros. content because they are dinosaurs that are worried that someone might be watching in the wrong country. We are pleased to offer you content from producers that are not complete morons...." As the content producers lose more and more control over the distribution channel they are going to take whatever terms are necessary to get them on Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not on any or all of those platforms, you are going to be dead meat. Who would be hurt worse, Netflix or the movie producer that got seen nowhere on their latest film. To me, this is the last gasp of an industry that lost control of its distribution channel years ago and is still trying to impose that control. Steven Naslund -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Friday, June 03, 2016 4:28 PM To: Laszlo Hanyecz Cc: nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed It's time for Netflix to offer IPv6 tunnels. That way they can correlate IPv4 and IPv6 addresses. Longest match will result is the correct source address being selected if they do the job correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From SNaslund at medline.com Fri Jun 3 22:30:35 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 3 Jun 2016 22:30:35 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401E661A186@MUNPRDMBXA1.medline.com> Fine, tell the lawyers and MBA types that if their reliable methods become unreliable they are not the ISPs problem and that their ?risk profile? is the number of customer they lose. I would like to see some sort of statistic that says AGPS is more reliable than IP location. I really doubt it for the following reasons. 1. Device needs to have GPS, WiFi, or both. A lot don?t. 2. SSID needs to be in a database. What is the ratio of SSIDs in the databases vs total SSIDs worldwide. Bet a large percentage are not there. 3. People can change an SSID or WiFi AP at any time. How long exactly until I get my database entry updated. 4. Any indoor area that does not have WiFi coverage cannot be located, period, end of story. I guarantee you that Apple does not know where my Apple TV units or any of my Sony TVs are because they are on hard Ethernet cables with WiFi disabled so if they told the lawyers that, they lied. Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 5:18 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed "there is no reliable geo-location method for Netflix to use" Any microprocessor that is connected to the Internet is subject to being hacked - let's just turn off all of our computers, since we're talking in absolutes. From the perspective of the "lawyers and MBA types that negotiate agreements with Netflix and similar services" (to quote Eric), there are reliable methods within a specific risk profile, and those include (thanks to Google and Apple, whom most of the content providers also have agreements with) AGPS based on Wifi and other industry now-standard methods. I don't think there _is_ a contractual requirement to attempt to block VPN traffic. I think there's a contractual requirement to provide geographic controls for content, which is a completely different discussion, and is what those same cable and satellite TV providers (many of which _are_ the ISPs for Netflix's customer base) provide. As has been pointed out, Slingbox is an excellent proxy for over-the-air and cable-tv video, but you don't see content providers pressuring regulation on them because they limit their risk with the station or cable TV provider. On Fri, Jun 3, 2016 at 6:08 PM Naslund, Steve > wrote: That is true. The problem is that traditionally the ISPs have to deal with customers that can?t get to the content they want. Netflix ridiculous detection schemes do nothing but create tons of work for the service provider which in turn creates stupid work-arounds and network configurations that are ill conceived. Myself, I had to shut off IPv6 at home to get things to work reliably several times for dumb reasons. Kind of hard to preach the v6 message when I had to shut it off myself several time to get my own stuff to work Ok. Netflix just decided that creating issues for a subset of their customers was better than having the real fight with the content providers. My point is that there is no reliable geo-location method for Netflix to use, at least there never has been yet. Good luck ever getting that to work behind the great firewall of China. Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com] Sent: Friday, June 03, 2016 4:56 PM To: Naslund, Steve; nanog at nanog.org Subject: Re: Netflix VPN detection - actual engineer needed Oh I'm not suggesting for a microsecond that any provenance of location can not be hacked, but I totally think that - until the content providers change their business model to not rely on regional controls - they could at least use a more accurate source for that information than my IP(4 or 6) address. I just don't think that this is an appropriate venue to discuss the value of their business model as that's something their business needs to work on changing internally, and fighting it (at least for the moment) will only land Netflix in court. In short, I'm pointing the finger at Netflix's developers for coming up with such a lazy control for geolocation. On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve >> wrote: Wifi location depends on a bunch of problematic things. First, your SSID needs to get collected and put in a database somewhere. That itself is a crap shoot. Next, you can stop google (and some other wifi databases) from collecting the data by putting _nomap at the end of your SSID. Lastly, not everyone has wifi or iOS or GPS or whatever location method you can think of. BTW, my apple TV is on a wired Ethernet, not wifi. Point is, for whatever location technology you want to use be it IP, GPS, WiFi location, sextant?..they can be inaccurate and they can be faked and there are privacy concerns with all of them. What the content producers need to figure out is that regionalization DOES NOT WORK ANYMORE! The original point was that they could have different release dates in different areas at different prices and availability. They are going to have to get over it because they will lose the technological arms race. There is no reason you could not beat all of the location systems with a simple proxy. A proxy makes a Netflix connection from an allowed IP, location or whatever and then builds a new video/audio stream out the back end to the client anywhere in the world. Simple to implement and damn near impossible to beat. Ever hear of Slingbox? Steven Naslund Chicago IL From: Cryptographrix [mailto:cryptographrix at gmail.com>] Sent: Friday, June 03, 2016 3:42 PM To: Naslund, Steve; nanog at nanog.org> Subject: Re: Netflix VPN detection - actual engineer needed Apple TVs get their location indoors using the same method they use for other iOS devices when indoors - wifi ssid/Mac scanning. Non-iOS devices are often capable of this as well. (As someone that spends >67% of his time underground and whose Apple TV requests my location from my underground bedroom and is very accurate) On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve >>>> wrote: Their app could request your devices location. Problem is a lot of devices (like TVs, Apple TVs, most DVD player, i.e. device with built in Netflix) don't know where they are and it cannot easily be added (indoor GPS is still difficult/expensive) and even if they could should they be believed. I think the bigger issue is whether any kind of regional controls are enforceable or effective any more. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org>>>] On Behalf Of Cryptographrix Sent: Friday, June 03, 2016 3:21 PM To: Spencer Ryan Cc: North American Network Operators' Group Subject: Re: Netflix VPN detection - actual engineer needed Come now, content providers really just care that they have access to regional controls more so than their ability to blanket-deny access (ok, minus the MLB who are just insane). And part of those regional controls deal with the accuracy of the location information. If their app can request my device's precise location, it doesn't need to infer my location from my IP any more. As a matter of fact, it's only detrimental to them for it to do so, because of the lack of accuracy from geo databases and the various reasons that people use VPNs nowadays (i.e. for some devices that you can't even turn VPN connections off for - OR in the case of IPv6, when you can't reach a segment of the Internet without it). On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan >>>> wrote: > There is a large difference between "the VPN run at your house" and > "Arguably the most popular, free, mostly anonymous tunnel broker service" > > If it were up to the content providers, they probably would block any > IP they saw a VPN server listening on. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net>>> *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix > >>>> > wrote: > >> I have a VPN connection at my house. There's no way for them to know >> the difference between me using my home network connection from Hong >> Kong or my home network connection from my house. >> >> Are they going to disable connectivity from everywhere they can >> detect an open VPN port to, also? >> >> If they trust my v4 address, they can use that to establish >> historical reference. Additionally, they can fail over to v4 if they >> do not trust the >> v6 address. >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan >>>> wrote: >> >>> There is no way for Netflix to know the difference between you being >>> in NY and using the tunnel, and you living in Hong Kong and using the tunnel. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net>>> >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >>> >>> > wrote: >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>>> annoying that they haven't come up with some fix for this. >>>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>>> uses for it, and as much as I dislike the controversy around it, >>>> think that adoption needs to be prioritized, not penalized. >>>> >>>> Additionally, I think that discussing content provider control over >>>> regional decisions isn't productive to the conversation, as they >>>> didn't build the banhammer (wouldn't you want to control your own >>>> content if you had made content specific to regional laws etc?). >>>> >>>> I.e. - not all shows need to have regional restrictions between New >>>> York (where I live) and California (where my IPv6 /64 says I live). >>>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>>> ignore my intra-US proxy connection. >>>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>>> *that* off. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan >>>> wrote: >>>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>>>> broker. I'm sure their content providers are forcing their hand. >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>>>> >>>> >>>>> wrote: >>>>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>>>>> provide IPv6 natively. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>>>>> >>> >>>>>> > >>>>>> wrote: >>>>>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>>>>> > take a >>>>>> crack at >>>>>> > this? >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, >>>> wrote: >>>>>> > >>>>>> > > Had the same problem at my house, but it was caused by the >>>>>> > > IPv6 >>>>>> > connection >>>>>> > > to HE. Turned of V6 and the device worked. >>>>>> > > >>>>>> > > >>>>>> > > -- >>>>>> > > >>>>>> > > Sent with Airmail >>>>>> > > >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>>>>> matthew at matthew.at>>>) >>>>>> > > wrote: >>>>>> > > >>>>>> > > Every device in my house is blocked from Netflix this evening >>>>>> > > due >>>>>> to >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>>>>> > > the >>>>>> outside >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>>>>> announced >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>>>>> house >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>>>>> microwaves >>>>>> > > fly. >>>>>> > > >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>>>>> > > this, >>>>>> the >>>>>> > > only response is to say "call your ISP and have them turn off >>>>>> > > the >>>>>> VPN >>>>>> > > software they've added to your account". And they absolutely >>>>>> refuse to >>>>>> > > escalate. Even if you tell them that you are essentially your >>>>>> > > own >>>>>> ISP. >>>>>> > > >>>>>> > > So... where's the Netflix network engineer on the list who >>>>>> > > all of >>>>>> us can >>>>>> > > send these issues to directly? >>>>>> > > >>>>>> > > Matthew Kaufman >>>>>> > > >>>>>> > >>>>>> >>>>> >>> > From cryptographrix at gmail.com Fri Jun 3 22:34:57 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 22:34:57 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> Message-ID: But wait, content providers *do that.* *Microsoft too...for illegal copies of Outlook, even...* How do we know they do that? Because your ISP can be held liable if they are contacted by a content provider and do not follow graduated response guidelines either issued by the nation the ISP resides in or governed by industry agreements and *do not* shut off your service if you are found to be pirating content. But all of this is moot against the point you mentioned: Netflix authored a broken process. There are at least 3 much more accurate ways to establish regional provenance for any packet - and of course all of them can be hacked - but those same content providers have established in their audit requirements that they're perfectly willing to accept the risks involved. On Fri, Jun 3, 2016 at 6:18 PM Cryptographrix wrote: > " > there is no reliable geo-location method for Netflix to use" > > Any microprocessor that is connected to the Internet is subject to being > hacked - let's just turn off all of our computers, since we're talking in > absolutes. > > From the perspective of the "lawyers and MBA types that negotiate > agreements with Netflix and similar services" (to quote Eric), there *are* reliable > methods within a specific risk profile, and those include (thanks to Google > and Apple, whom most of the content providers *also* have agreements > with) AGPS based on Wifi and other industry now-standard methods. > > I don't think there _is_ a contractual requirement to attempt to block VPN > traffic. I think there's a contractual requirement to provide geographic > controls for content, which is a completely different discussion, and is > what those same cable and satellite TV providers (many of which _are_ the > ISPs for Netflix's customer base) provide. > > As has been pointed out, Slingbox is an excellent proxy for over-the-air > and cable-tv video, but you don't see content providers pressuring > regulation on them because they limit their risk with the station or cable > TV provider. > > > > > On Fri, Jun 3, 2016 at 6:08 PM Naslund, Steve > wrote: > >> That is true. The problem is that traditionally the ISPs have to deal >> with customers that can?t get to the content they want. Netflix ridiculous >> detection schemes do nothing but create tons of work for the service >> provider which in turn creates stupid work-arounds and network >> configurations that are ill conceived. Myself, I had to shut off IPv6 at >> home to get things to work reliably several times for dumb reasons. Kind >> of hard to preach the v6 message when I had to shut it off myself several >> time to get my own stuff to work Ok. Netflix just decided that creating >> issues for a subset of their customers was better than having the real >> fight with the content providers. >> >> My point is that there is no reliable geo-location method for Netflix to >> use, at least there never has been yet. Good luck ever getting that to >> work behind the great firewall of China. >> >> Steven Naslund >> Chicago IL >> >> From: Cryptographrix [mailto:cryptographrix at gmail.com] >> Sent: Friday, June 03, 2016 4:56 PM >> To: Naslund, Steve; nanog at nanog.org >> Subject: Re: Netflix VPN detection - actual engineer needed >> >> Oh I'm not suggesting for a microsecond that any provenance of location >> can not be hacked, but I totally think that - until the content providers >> change their business model to not rely on regional controls - they could >> at least use a more accurate source for that information than my IP(4 or 6) >> address. >> >> I just don't think that this is an appropriate venue to discuss the value >> of their business model as that's something their business needs to work on >> changing internally, and fighting it (at least for the moment) will only >> land Netflix in court. >> >> In short, I'm pointing the finger at Netflix's developers for coming up >> with such a lazy control for geolocation. >> >> On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve > > wrote: >> Wifi location depends on a bunch of problematic things. First, your SSID >> needs to get collected and put in a database somewhere. That itself is a >> crap shoot. Next, you can stop google (and some other wifi databases) from >> collecting the data by putting _nomap at the end of your SSID. Lastly, not >> everyone has wifi or iOS or GPS or whatever location method you can think >> of. BTW, my apple TV is on a wired Ethernet, not wifi. >> >> Point is, for whatever location technology you want to use be it IP, GPS, >> WiFi location, sextant?..they can be inaccurate and they can be faked and >> there are privacy concerns with all of them. What the content producers >> need to figure out is that regionalization DOES NOT WORK ANYMORE! The >> original point was that they could have different release dates in >> different areas at different prices and availability. They are going to >> have to get over it because they will lose the technological arms race. >> >> There is no reason you could not beat all of the location systems with a >> simple proxy. A proxy makes a Netflix connection from an allowed IP, >> location or whatever and then builds a new video/audio stream out the back >> end to the client anywhere in the world. Simple to implement and damn near >> impossible to beat. Ever hear of Slingbox? >> >> Steven Naslund >> Chicago IL >> >> From: Cryptographrix [mailto:cryptographrix at gmail.com> cryptographrix at gmail.com>] >> Sent: Friday, June 03, 2016 3:42 PM >> To: Naslund, Steve; nanog at nanog.org >> Subject: Re: Netflix VPN detection - actual engineer needed >> >> Apple TVs get their location indoors using the same method they use for >> other iOS devices when indoors - wifi ssid/Mac scanning. >> >> Non-iOS devices are often capable of this as well. >> >> (As someone that spends >67% of his time underground and whose Apple TV >> requests my location from my underground bedroom and is very accurate) >> >> On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve > > SNaslund at medline.com>>> wrote: >> Their app could request your devices location. Problem is a lot of >> devices (like TVs, Apple TVs, most DVD player, i.e. device with built in >> Netflix) don't know where they are and it cannot easily be added (indoor >> GPS is still difficult/expensive) and even if they could should they be >> believed. I think the bigger issue is whether any kind of regional >> controls are enforceable or effective any more. >> >> Steven Naslund >> Chicago IL >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org> nanog-bounces at nanog.org>> nanog-bounces at nanog.org>>] On Behalf Of Cryptographrix >> Sent: Friday, June 03, 2016 3:21 PM >> To: Spencer Ryan >> Cc: North American Network Operators' Group >> Subject: Re: Netflix VPN detection - actual engineer needed >> >> Come now, content providers really just care that they have access to >> regional controls more so than their ability to blanket-deny access (ok, >> minus the MLB who are just insane). >> >> And part of those regional controls deal with the accuracy of the >> location information. >> >> If their app can request my device's precise location, it doesn't need to >> infer my location from my IP any more. >> >> As a matter of fact, it's only detrimental to them for it to do so, >> because of the lack of accuracy from geo databases and the various reasons >> that people use VPNs nowadays (i.e. for some devices that you can't even >> turn VPN connections off for - OR in the case of IPv6, when you can't reach >> a segment of the Internet without it). >> >> >> On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan > sryan at arbor.net>>> wrote: >> >> > There is a large difference between "the VPN run at your house" and >> > "Arguably the most popular, free, mostly anonymous tunnel broker >> service" >> > >> > If it were up to the content providers, they probably would block any >> > IP they saw a VPN server listening on. >> > >> > >> > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net> sryan at arbor.net>> *Arbor >> > Networks* >> > +1.734.794.5033 (d) | +1.734.846.2053 (m) >> > www.arbornetworks.com< >> http://www.arbornetworks.com> >> > >> > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix >> > > cryptographrix at gmail.com>> >> > wrote: >> > >> >> I have a VPN connection at my house. There's no way for them to know >> >> the difference between me using my home network connection from Hong >> >> Kong or my home network connection from my house. >> >> >> >> Are they going to disable connectivity from everywhere they can >> >> detect an open VPN port to, also? >> >> >> >> If they trust my v4 address, they can use that to establish >> >> historical reference. Additionally, they can fail over to v4 if they >> >> do not trust the >> >> v6 address. >> >> >> >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan > sryan at arbor.net>>> wrote: >> >> >> >>> There is no way for Netflix to know the difference between you being >> >>> in NY and using the tunnel, and you living in Hong Kong and using the >> tunnel. >> >>> >> >>> >> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> > >> >>> *Arbor Networks* >> >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> >>> www.arbornetworks.com< >> http://www.arbornetworks.com> >> >>> >> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >> >>> > cryptographrix at gmail.com> >> >>> > wrote: >> >>> >> >>>> Same, but until there's a real IPv6 presence in the US, it's really >> >>>> annoying that they haven't come up with some fix for this. >> >>>> >> >>>> I have no plans to turn off IPv6 at home - I actually have many >> >>>> uses for it, and as much as I dislike the controversy around it, >> >>>> think that adoption needs to be prioritized, not penalized. >> >>>> >> >>>> Additionally, I think that discussing content provider control over >> >>>> regional decisions isn't productive to the conversation, as they >> >>>> didn't build the banhammer (wouldn't you want to control your own >> >>>> content if you had made content specific to regional laws etc?). >> >>>> >> >>>> I.e. - not all shows need to have regional restrictions between New >> >>>> York (where I live) and California (where my IPv6 /64 says I live). >> >>>> >> >>>> I'm able to watch House in the any state in the U.S.? Great - >> >>>> ignore my intra-US proxy connection. >> >>>> >> >>>> My Netflix account randomly tries to connect from Tokyo because I >> >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >> >>>> *that* off. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan > sryan at arbor.net>>> wrote: >> >>>> >> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >> >>>>> broker. I'm sure their content providers are forcing their hand. >> >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >> >>>>> > cryptographrix at gmail.com>> >> >>>>> wrote: >> >>>>> >> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >> >>>>>> provide IPv6 natively. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >> >>>>>> > blair.trosper at gmail.com> >> >>>>>> > >> >>>>>> wrote: >> >>>>>> >> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >> >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >> >>>>>> > take a >> >>>>>> crack at >> >>>>>> > this? >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, > mike.hyde1 at gmail.com>> mike.hyde1 at gmail.com>>> wrote: >> >>>>>> > >> >>>>>> > > Had the same problem at my house, but it was caused by the >> >>>>>> > > IPv6 >> >>>>>> > connection >> >>>>>> > > to HE. Turned of V6 and the device worked. >> >>>>>> > > >> >>>>>> > > >> >>>>>> > > -- >> >>>>>> > > >> >>>>>> > > Sent with Airmail >> >>>>>> > > >> >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >> >>>>>> matthew at matthew.at> matthew at matthew.at>) >> >>>>>> > > wrote: >> >>>>>> > > >> >>>>>> > > Every device in my house is blocked from Netflix this evening >> >>>>>> > > due >> >>>>>> to >> >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >> >>>>>> > > the >> >>>>>> outside >> >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >> >>>>>> announced >> >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >> >>>>>> house >> >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >> >>>>>> microwaves >> >>>>>> > > fly. >> >>>>>> > > >> >>>>>> > > Unfortunately, when one calls Netflix support to talk about >> >>>>>> > > this, >> >>>>>> the >> >>>>>> > > only response is to say "call your ISP and have them turn off >> >>>>>> > > the >> >>>>>> VPN >> >>>>>> > > software they've added to your account". And they absolutely >> >>>>>> refuse to >> >>>>>> > > escalate. Even if you tell them that you are essentially your >> >>>>>> > > own >> >>>>>> ISP. >> >>>>>> > > >> >>>>>> > > So... where's the Netflix network engineer on the list who >> >>>>>> > > all of >> >>>>>> us can >> >>>>>> > > send these issues to directly? >> >>>>>> > > >> >>>>>> > > Matthew Kaufman >> >>>>>> > > >> >>>>>> > >> >>>>>> >> >>>>> >> >>> >> > >> > From cryptographrix at gmail.com Fri Jun 3 22:52:18 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 22:52:18 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> Message-ID: > 1. Device needs to have GPS, WiFi, or both. A lot don?t. Doesn't need to be mandatory, but it's elective to use and yes - AGPS/Wifi is much more accurate than IP geolocation where available, by a long shot https://gigaom.com/2012/08/17/how-much-better-is-gps-over-wi-fi-positioning-yelp-knows/ IP Geolocation is accurate to the city, at best, and is often completely off if you live in a metropolitan area > 2. SSID needs to be in a database. What is the ratio of SSIDs in the databases vs total SSIDs worldwide. Bet a large percentage are not there. This isn't even an issue in the US - what do you think those Google cars collect besides pictures?: https://www.wired.com/2014/04/threatlevel_0401_streetview/ > 3. People can change an SSID or WiFi AP at any time. How long exactly until I get my database entry updated. Yes they can change SSIDs, which is why Wifi-based geolocation doesn't profile a location based on individual SSIDs or *just* SSIDs (many also include MAC addresses to - see the aforementioned court case). > 4. Any indoor area that does not have WiFi coverage cannot be located, period, end of story. Wireless-ISPs are now a thing. You can be in the mountains of Colorado and have your location established better with Wifi than your IP geolocation will provide. You'd be surprised how many wireless SSIDs you'll receive in the most remote places. Then again, there are places in metropolitan areas where there is absolutely no wifi. Sure, fall back to IP geolocation there. You're trying to find edge cases - I get it - but in most places your edge cases don't exist. If you have a device with wifi on it and it is connected to the internet even with Ethernet, in the US you have no assurance that it can not use Wifi to determine your location much more precisely than IP geolocation. Period. On Fri, Jun 3, 2016 at 6:35 PM Cryptographrix wrote: > But wait, content providers *do that.* > > *Microsoft too...for illegal copies of Outlook, even...* > > How do we know they do that? > > Because your ISP can be held liable if they are contacted by a content > provider and do not follow graduated response guidelines either issued by > the nation the ISP resides in or governed by industry agreements and *do > not* shut off your service if you are found to be pirating content. > > But all of this is moot against the point you mentioned: Netflix authored > a broken process. > > There are at least 3 much more accurate ways to establish regional > provenance for any packet - and of course all of them can be hacked - but > those same content providers have established in their audit requirements > that they're perfectly willing to accept the risks involved. > > > > > > On Fri, Jun 3, 2016 at 6:18 PM Cryptographrix > wrote: > >> " >> there is no reliable geo-location method for Netflix to use" >> >> Any microprocessor that is connected to the Internet is subject to being >> hacked - let's just turn off all of our computers, since we're talking in >> absolutes. >> >> From the perspective of the "lawyers and MBA types that negotiate >> agreements with Netflix and similar services" (to quote Eric), there >> *are* reliable methods within a specific risk profile, and those include >> (thanks to Google and Apple, whom most of the content providers *also* have >> agreements with) AGPS based on Wifi and other industry now-standard methods. >> >> I don't think there _is_ a contractual requirement to attempt to block >> VPN traffic. I think there's a contractual requirement to provide >> geographic controls for content, which is a completely different >> discussion, and is what those same cable and satellite TV providers (many >> of which _are_ the ISPs for Netflix's customer base) provide. >> >> As has been pointed out, Slingbox is an excellent proxy for over-the-air >> and cable-tv video, but you don't see content providers pressuring >> regulation on them because they limit their risk with the station or cable >> TV provider. >> >> >> >> >> On Fri, Jun 3, 2016 at 6:08 PM Naslund, Steve >> wrote: >> >>> That is true. The problem is that traditionally the ISPs have to deal >>> with customers that can?t get to the content they want. Netflix ridiculous >>> detection schemes do nothing but create tons of work for the service >>> provider which in turn creates stupid work-arounds and network >>> configurations that are ill conceived. Myself, I had to shut off IPv6 at >>> home to get things to work reliably several times for dumb reasons. Kind >>> of hard to preach the v6 message when I had to shut it off myself several >>> time to get my own stuff to work Ok. Netflix just decided that creating >>> issues for a subset of their customers was better than having the real >>> fight with the content providers. >>> >>> My point is that there is no reliable geo-location method for Netflix to >>> use, at least there never has been yet. Good luck ever getting that to >>> work behind the great firewall of China. >>> >>> Steven Naslund >>> Chicago IL >>> >>> From: Cryptographrix [mailto:cryptographrix at gmail.com] >>> Sent: Friday, June 03, 2016 4:56 PM >>> To: Naslund, Steve; nanog at nanog.org >>> Subject: Re: Netflix VPN detection - actual engineer needed >>> >>> Oh I'm not suggesting for a microsecond that any provenance of location >>> can not be hacked, but I totally think that - until the content providers >>> change their business model to not rely on regional controls - they could >>> at least use a more accurate source for that information than my IP(4 or 6) >>> address. >>> >>> I just don't think that this is an appropriate venue to discuss the >>> value of their business model as that's something their business needs to >>> work on changing internally, and fighting it (at least for the moment) will >>> only land Netflix in court. >>> >>> In short, I'm pointing the finger at Netflix's developers for coming up >>> with such a lazy control for geolocation. >>> >>> On Fri, Jun 3, 2016 at 4:58 PM Naslund, Steve >> > wrote: >>> Wifi location depends on a bunch of problematic things. First, your >>> SSID needs to get collected and put in a database somewhere. That itself >>> is a crap shoot. Next, you can stop google (and some other wifi databases) >>> from collecting the data by putting _nomap at the end of your SSID. >>> Lastly, not everyone has wifi or iOS or GPS or whatever location method you >>> can think of. BTW, my apple TV is on a wired Ethernet, not wifi. >>> >>> Point is, for whatever location technology you want to use be it IP, >>> GPS, WiFi location, sextant?..they can be inaccurate and they can be faked >>> and there are privacy concerns with all of them. What the content >>> producers need to figure out is that regionalization DOES NOT WORK >>> ANYMORE! The original point was that they could have different release >>> dates in different areas at different prices and availability. They are >>> going to have to get over it because they will lose the technological arms >>> race. >>> >>> There is no reason you could not beat all of the location systems with a >>> simple proxy. A proxy makes a Netflix connection from an allowed IP, >>> location or whatever and then builds a new video/audio stream out the back >>> end to the client anywhere in the world. Simple to implement and damn near >>> impossible to beat. Ever hear of Slingbox? >>> >>> Steven Naslund >>> Chicago IL >>> >>> From: Cryptographrix [mailto:cryptographrix at gmail.com>> cryptographrix at gmail.com>] >>> Sent: Friday, June 03, 2016 3:42 PM >>> To: Naslund, Steve; nanog at nanog.org >>> Subject: Re: Netflix VPN detection - actual engineer needed >>> >>> Apple TVs get their location indoors using the same method they use for >>> other iOS devices when indoors - wifi ssid/Mac scanning. >>> >>> Non-iOS devices are often capable of this as well. >>> >>> (As someone that spends >67% of his time underground and whose Apple TV >>> requests my location from my underground bedroom and is very accurate) >>> >>> On Fri, Jun 3, 2016 at 4:36 PM Naslund, Steve >> >> SNaslund at medline.com>>> wrote: >>> Their app could request your devices location. Problem is a lot of >>> devices (like TVs, Apple TVs, most DVD player, i.e. device with built in >>> Netflix) don't know where they are and it cannot easily be added (indoor >>> GPS is still difficult/expensive) and even if they could should they be >>> believed. I think the bigger issue is whether any kind of regional >>> controls are enforceable or effective any more. >>> >>> Steven Naslund >>> Chicago IL >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org>> nanog-bounces at nanog.org>>> nanog-bounces at nanog.org>>] On Behalf Of Cryptographrix >>> Sent: Friday, June 03, 2016 3:21 PM >>> To: Spencer Ryan >>> Cc: North American Network Operators' Group >>> Subject: Re: Netflix VPN detection - actual engineer needed >>> >>> Come now, content providers really just care that they have access to >>> regional controls more so than their ability to blanket-deny access (ok, >>> minus the MLB who are just insane). >>> >>> And part of those regional controls deal with the accuracy of the >>> location information. >>> >>> If their app can request my device's precise location, it doesn't need >>> to infer my location from my IP any more. >>> >>> As a matter of fact, it's only detrimental to them for it to do so, >>> because of the lack of accuracy from geo databases and the various reasons >>> that people use VPNs nowadays (i.e. for some devices that you can't even >>> turn VPN connections off for - OR in the case of IPv6, when you can't reach >>> a segment of the Internet without it). >>> >>> >>> On Fri, Jun 3, 2016 at 4:17 PM Spencer Ryan >> sryan at arbor.net>>> wrote: >>> >>> > There is a large difference between "the VPN run at your house" and >>> > "Arguably the most popular, free, mostly anonymous tunnel broker >>> service" >>> > >>> > If it were up to the content providers, they probably would block any >>> > IP they saw a VPN server listening on. >>> > >>> > >>> > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> > >>> *Arbor >>> > Networks* >>> > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> > www.arbornetworks.com< >>> http://www.arbornetworks.com> >>> > >>> > On Fri, Jun 3, 2016 at 4:09 PM, Cryptographrix >>> > >> cryptographrix at gmail.com>> >>> > wrote: >>> > >>> >> I have a VPN connection at my house. There's no way for them to know >>> >> the difference between me using my home network connection from Hong >>> >> Kong or my home network connection from my house. >>> >> >>> >> Are they going to disable connectivity from everywhere they can >>> >> detect an open VPN port to, also? >>> >> >>> >> If they trust my v4 address, they can use that to establish >>> >> historical reference. Additionally, they can fail over to v4 if they >>> >> do not trust the >>> >> v6 address. >>> >> >>> >> >>> >> >>> >> >>> >> On Fri, Jun 3, 2016 at 4:05 PM Spencer Ryan >> sryan at arbor.net>>> wrote: >>> >> >>> >>> There is no way for Netflix to know the difference between you being >>> >>> in NY and using the tunnel, and you living in Hong Kong and using >>> the tunnel. >>> >>> >>> >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> > >>> >>> *Arbor Networks* >>> >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> >>> www.arbornetworks.com< >>> http://www.arbornetworks.com> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 4:03 PM, Cryptographrix >>> >>> >> cryptographrix at gmail.com> >>> >>> > wrote: >>> >>> >>> >>>> Same, but until there's a real IPv6 presence in the US, it's really >>> >>>> annoying that they haven't come up with some fix for this. >>> >>>> >>> >>>> I have no plans to turn off IPv6 at home - I actually have many >>> >>>> uses for it, and as much as I dislike the controversy around it, >>> >>>> think that adoption needs to be prioritized, not penalized. >>> >>>> >>> >>>> Additionally, I think that discussing content provider control over >>> >>>> regional decisions isn't productive to the conversation, as they >>> >>>> didn't build the banhammer (wouldn't you want to control your own >>> >>>> content if you had made content specific to regional laws etc?). >>> >>>> >>> >>>> I.e. - not all shows need to have regional restrictions between New >>> >>>> York (where I live) and California (where my IPv6 /64 says I live). >>> >>>> >>> >>>> I'm able to watch House in the any state in the U.S.? Great - >>> >>>> ignore my intra-US proxy connection. >>> >>>> >>> >>>> My Netflix account randomly tries to connect from Tokyo because I >>> >>>> forgot to shut off my work VPN? Fine....let me know and I'll turn >>> >>>> *that* off. >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Jun 3, 2016 at 3:49 PM Spencer Ryan >> >> >>> wrote: >>> >>>> >>> >>>>> I don't blame them for blocking a (effectively) anonymous tunnel >>> >>>>> broker. I'm sure their content providers are forcing their hand. >>> >>>>> On Jun 3, 2016 3:46 PM, "Cryptographrix" >>> >>>>> >> cryptographrix at gmail.com>> >>> >>>>> wrote: >>> >>>>> >>> >>>>>> Netflix needs to figure out a fix for this until ISPs actually >>> >>>>>> provide IPv6 natively. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On Fri, Jun 3, 2016 at 3:13 PM Blair Trosper >>> >>>>>> >> blair.trosper at gmail.com> >>> >>>>>> > >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>> > Confirmed that Hurricane Electric's TunnelBroker is now blocked >>> >>>>>> > by Netflix. Anyone nice people from Netflix perhaps want to >>> >>>>>> > take a >>> >>>>>> crack at >>> >>>>>> > this? >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > On Thu, Jun 2, 2016 at 2:15 PM, >> mike.hyde1 at gmail.com>>> mike.hyde1 at gmail.com>>> wrote: >>> >>>>>> > >>> >>>>>> > > Had the same problem at my house, but it was caused by the >>> >>>>>> > > IPv6 >>> >>>>>> > connection >>> >>>>>> > > to HE. Turned of V6 and the device worked. >>> >>>>>> > > >>> >>>>>> > > >>> >>>>>> > > -- >>> >>>>>> > > >>> >>>>>> > > Sent with Airmail >>> >>>>>> > > >>> >>>>>> > > On June 1, 2016 at 10:29:03 PM, Matthew Kaufman ( >>> >>>>>> matthew at matthew.at>> matthew at matthew.at>) >>> >>>>>> > > wrote: >>> >>>>>> > > >>> >>>>>> > > Every device in my house is blocked from Netflix this evening >>> >>>>>> > > due >>> >>>>>> to >>> >>>>>> > > their new "VPN blocker". My house is on my own IP space, and >>> >>>>>> > > the >>> >>>>>> outside >>> >>>>>> > > of the NAT that the family devices are on is 198.202.199.254, >>> >>>>>> announced >>> >>>>>> > > by AS 11994. A simple ping from Netflix HQ in Los Gatos to my >>> >>>>>> house >>> >>>>>> > > should show that I'm no farther away than Santa Cruz, CA as >>> >>>>>> microwaves >>> >>>>>> > > fly. >>> >>>>>> > > >>> >>>>>> > > Unfortunately, when one calls Netflix support to talk about >>> >>>>>> > > this, >>> >>>>>> the >>> >>>>>> > > only response is to say "call your ISP and have them turn off >>> >>>>>> > > the >>> >>>>>> VPN >>> >>>>>> > > software they've added to your account". And they absolutely >>> >>>>>> refuse to >>> >>>>>> > > escalate. Even if you tell them that you are essentially your >>> >>>>>> > > own >>> >>>>>> ISP. >>> >>>>>> > > >>> >>>>>> > > So... where's the Netflix network engineer on the list who >>> >>>>>> > > all of >>> >>>>>> us can >>> >>>>>> > > send these issues to directly? >>> >>>>>> > > >>> >>>>>> > > Matthew Kaufman >>> >>>>>> > > >>> >>>>>> > >>> >>>>>> >>> >>>>> >>> >>> >>> > >>> >> From cryptographrix at gmail.com Fri Jun 3 23:00:02 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 23:00:02 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: "What you are NOT allowed to do is impose new requirements on our Internet to support your business licensing models and make it our problem" They're not imposing *new* regulation on *your* internet to support their business licensing models - they're imposing *existing* (and international) regulations on someone else's business that *existing* distributors provide controls for. And that many *existing* online distributors provide controls for - hence why they should be using the *most local* method of locating a person - ask for permission to get the location from their *device first* (as is possible nowadays), then try to get the location from any one of other fallback methods (namely, IP geolocation). On Fri, Jun 3, 2016 at 6:22 PM Naslund, Steve wrote: > ISPs should not be in the business of helping distributors come up with > ?novel ways? to help them regionalize. It?s counterproductive to the ISPs > main purpose which is to get their customers ?the whole Internet?, from > anywhere to anywhere no matter where you are. > > As far as TV channels, that is an unrelated issue because they have their > own distribution network, they can freely choose what cable systems and > what satellite systems they want to license to. What you are NOT allowed > to do is impose new requirements on our Internet to support your business > licensing models and make it our problem. This is no different than > someone like Microsoft saying ?hey service providers, we don?t want you to > carry any network traffic from illegal copies of Outlook? and expecting us > to figure it out. I know as service providers we have to be sensitive to > our customers but Netflix is also a service provider and should be taking > the heat from their own customers. Netflix authored a broken process and > now we should be expected to re-engineer the network to eliminate V6 tunnel > brokers?!?!?! I don?t think so Netflix. > > If I was still an ISP today, I would be sending all of my customers a memo > explaining how badly Netflix VPN detection works and why it is so hard for > us to help with it and why they should be complaining to Netflix. > > Steven Naslund > > From: Cryptographrix [mailto:cryptographrix at gmail.com] > Sent: Friday, June 03, 2016 5:06 PM > To: Naslund, Steve; nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > There's really no point in whining about content providers and > regionalization as long as TV channels are still a thing. > > I get that the internet totally annihilated borders of all kind (including > the book store), but some businesses change slower than others, and content > production is still back in the black-and-white TV days because even new > content producers don't have that new of a business model. > > But nor are ISPs coming up with novel ways for distributors to offer more > reliable regionalization services (and most of them were in the content > regionalization business long before the Internet came around). > > Pick one of those two problems and make a business to solve them. > > Until then, Netflix's developers could at least use the "novel" solution > of tiering the most accurate forms of location before hitting IP > geolocation. > > > > > On Fri, Jun 3, 2016 at 5:52 PM Naslund, Steve > wrote: > Actually it's time for Netflix to get out of the network transport > business and tell the content providers to get over it or not get carried > on Netflix. It used to be that Netflix needed content providers, now I am > starting to believe it might be the other way around. Netflix might have > to take a page from the satellite guys and start calling them out > publicly. i.e. "Netflix will no longer be able to provide you with Warner > Bros. content because they are dinosaurs that are worried that someone > might be watching in the wrong country. We are pleased to offer you > content from producers that are not complete morons...." > > As the content producers lose more and more control over the distribution > channel they are going to take whatever terms are necessary to get them on > Netflix, Apple TV, Comcast, Time Warner, DirecTV and Dish. If you are not > on any or all of those platforms, you are going to be dead meat. Who > would be hurt worse, Netflix or the movie producer that got seen nowhere on > their latest film. To me, this is the last gasp of an industry that lost > control of its distribution channel years ago and is still trying to impose > that control. > > Steven Naslund > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] > On Behalf Of Mark Andrews > Sent: Friday, June 03, 2016 4:28 PM > To: Laszlo Hanyecz > Cc: nanog at nanog.org > Subject: Re: Netflix VPN detection - actual engineer needed > > > It's time for Netflix to offer IPv6 tunnels. That way they can correlate > IPv4 and IPv6 addresses. Longest match will result is the correct source > address being selected if they do the job correctly. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org marka at isc.org> > From cryptographrix at gmail.com Fri Jun 3 23:15:12 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 23:15:12 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: > "What you are NOT allowed to do is impose new requirements on our Internet to support your business licensing models and make it our problem" They're not imposing new regulation on your internet to support their business licensing models - they're imposing existing (and international) regulations on someone else's business that existing distributors provide controls for. And that many existing online distributors provide controls for - hence why they should be using the most local method of locating a person - ask for permission to get the location from their device first (as is possible nowadays), then try to get the location from any one of other fallback methods (namely, IP geolocation). From cryptographrix at gmail.com Fri Jun 3 23:25:29 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 23:25:29 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: The information I'm getting from Netflix support now is explicitly telling me to turn off IPv6 - someone might want to stop them before they completely kill US IPv6 adoption. On Fri, Jun 3, 2016 at 7:15 PM Cryptographrix wrote: > > "What you are NOT allowed to do is impose new requirements on our > Internet to support your business licensing models and make it our problem" > > They're not imposing new regulation on your internet to support their > business licensing models - they're imposing existing (and international) > regulations on someone else's business that existing distributors provide > controls for. > > And that many existing online distributors provide controls for - hence > why they should be using the most local method of locating a person - ask > for permission to get the location from their device first (as is possible > nowadays), then try to get the location from any one of other fallback > methods (namely, IP geolocation). > From baldur.norddahl at gmail.com Fri Jun 3 23:43:55 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 4 Jun 2016 01:43:55 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Den 4. jun. 2016 01.26 skrev "Cryptographrix" : > > The information I'm getting from Netflix support now is explicitly telling > me to turn off IPv6 - someone might want to stop them before they > completely kill US IPv6 adoption. Not allowing he.net tunnels is not killing ipv6. You just need need native ipv6. On the other hand it would be nice if Netflix would try the other protocol before blocking. From matthew at matthew.at Fri Jun 3 23:48:35 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 3 Jun 2016 16:48:35 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <1E86B178-EF5D-48E2-B2F3-2355431E5F53@matthew.at> Good for them. For things like Apple TV you need to turn it off at the router of course. Matthew Kaufman (Sent from my iPhone) > On Jun 3, 2016, at 4:25 PM, Cryptographrix wrote: > > The information I'm getting from Netflix support now is explicitly telling > me to turn off IPv6 - someone might want to stop them before they > completely kill US IPv6 adoption. > > > On Fri, Jun 3, 2016 at 7:15 PM Cryptographrix > wrote: > >>> "What you are NOT allowed to do is impose new requirements on our >> Internet to support your business licensing models and make it our problem" >> >> They're not imposing new regulation on your internet to support their >> business licensing models - they're imposing existing (and international) >> regulations on someone else's business that existing distributors provide >> controls for. >> >> And that many existing online distributors provide controls for - hence >> why they should be using the most local method of locating a person - ask >> for permission to get the location from their device first (as is possible >> nowadays), then try to get the location from any one of other fallback >> methods (namely, IP geolocation). >> From cryptographrix at gmail.com Fri Jun 3 23:49:36 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 23:49:36 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Depends - how many US users have native IPv6 through their ISPs? If I remember correctly (I can't find the source at the moment), HE.net represents something like 70% of IPv6 traffic in the US. And yeah, not doing that - actually in the middle of an IPv6 project at work at the moment that's a bit important to me. On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl wrote: > Den 4. jun. 2016 01.26 skrev "Cryptographrix" : > > > > The information I'm getting from Netflix support now is explicitly > telling > > me to turn off IPv6 - someone might want to stop them before they > > completely kill US IPv6 adoption. > > Not allowing he.net tunnels is not killing ipv6. You just need need native > ipv6. > > On the other hand it would be nice if Netflix would try the other protocol > before blocking. > From cryptographrix at gmail.com Fri Jun 3 23:51:08 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 03 Jun 2016 23:51:08 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: (and this is coming from someone that has serious issues with IPv6 but understands that we need to move forward) On Fri, Jun 3, 2016 at 7:49 PM Cryptographrix wrote: > Depends - how many US users have native IPv6 through their ISPs? > > If I remember correctly (I can't find the source at the moment), HE.net > represents something like 70% of IPv6 traffic in the US. > > And yeah, not doing that - actually in the middle of an IPv6 project at > work at the moment that's a bit important to me. > > > > > On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > wrote: > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" : >> > >> > The information I'm getting from Netflix support now is explicitly >> telling >> > me to turn off IPv6 - someone might want to stop them before they >> > completely kill US IPv6 adoption. >> >> Not allowing he.net tunnels is not killing ipv6. You just need need >> native >> ipv6. >> >> On the other hand it would be nice if Netflix would try the other protocol >> before blocking. >> > From deleskie at gmail.com Fri Jun 3 23:59:07 2016 From: deleskie at gmail.com (jim deleskie) Date: Fri, 3 Jun 2016 20:59:07 -0300 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: I don't suspect many folks that are outside of this list would likely have any idea how to set up a v6 tunnel. Those of us on the list, likely have a much greater ability to influence v6 adoption or not via day job deployments then Netflix supporting v6 tunnels or not. On Fri, Jun 3, 2016 at 8:49 PM, Cryptographrix wrote: > Depends - how many US users have native IPv6 through their ISPs? > > If I remember correctly (I can't find the source at the moment), HE.net > represents something like 70% of IPv6 traffic in the US. > > And yeah, not doing that - actually in the middle of an IPv6 project at > work at the moment that's a bit important to me. > > > > > On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > wrote: > > > Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > > > > > > The information I'm getting from Netflix support now is explicitly > > telling > > > me to turn off IPv6 - someone might want to stop them before they > > > completely kill US IPv6 adoption. > > > > Not allowing he.net tunnels is not killing ipv6. You just need need > native > > ipv6. > > > > On the other hand it would be nice if Netflix would try the other > protocol > > before blocking. > > > From sryan at arbor.net Sat Jun 4 00:03:36 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 20:03:36 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Comcast is near 100% on their DOCSIS network (Busniess and residential). That should be the largest single ISP for IPv6 for end users in the USA. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix wrote: > Depends - how many US users have native IPv6 through their ISPs? > > If I remember correctly (I can't find the source at the moment), HE.net > represents something like 70% of IPv6 traffic in the US. > > And yeah, not doing that - actually in the middle of an IPv6 project at > work at the moment that's a bit important to me. > > > > > On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > wrote: > > > Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > > > > > > The information I'm getting from Netflix support now is explicitly > > telling > > > me to turn off IPv6 - someone might want to stop them before they > > > completely kill US IPv6 adoption. > > > > Not allowing he.net tunnels is not killing ipv6. You just need need > native > > ipv6. > > > > On the other hand it would be nice if Netflix would try the other > protocol > > before blocking. > > > From cryptographrix at gmail.com Sat Jun 4 00:07:45 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 00:07:45 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: I don't remember the source, but I do remember that even with Comcast's deployment, HE still represented the majority of IPv6 traffic in the US. Of course, it could just be a bunch of us heavy IPv6 users. On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: > Comcast is near 100% on their DOCSIS network (Busniess and residential). > That should be the largest single ISP for IPv6 for end users in the USA. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix > wrote: > >> Depends - how many US users have native IPv6 through their ISPs? >> >> If I remember correctly (I can't find the source at the moment), HE.net >> represents something like 70% of IPv6 traffic in the US. >> >> And yeah, not doing that - actually in the middle of an IPv6 project at >> work at the moment that's a bit important to me. >> >> >> >> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > > >> wrote: >> >> > Den 4. jun. 2016 01.26 skrev "Cryptographrix" > >: >> > > >> > > The information I'm getting from Netflix support now is explicitly >> > telling >> > > me to turn off IPv6 - someone might want to stop them before they >> > > completely kill US IPv6 adoption. >> > >> > Not allowing he.net tunnels is not killing ipv6. You just need need >> native >> > ipv6. >> > >> > On the other hand it would be nice if Netflix would try the other >> protocol >> > before blocking. >> > >> > > From sryan at arbor.net Sat Jun 4 00:13:03 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 20:13:03 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Yes but HE doesn't serve residential users directly. To a normal person HE is no different than NTT/GTT/Verizon/Sprint/Any other transit carrier. They may move the most v6 traffic, but Comcast is the largest ISP actually getting v6 to end users. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 8:07 PM, Cryptographrix wrote: > I don't remember the source, but I do remember that even with Comcast's > deployment, HE still represented the majority of IPv6 traffic in the US. > > Of course, it could just be a bunch of us heavy IPv6 users. > > > > On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: > >> Comcast is near 100% on their DOCSIS network (Busniess and residential). >> That should be the largest single ISP for IPv6 for end users in the USA. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix >> wrote: >> >>> Depends - how many US users have native IPv6 through their ISPs? >>> >>> If I remember correctly (I can't find the source at the moment), HE.net >>> represents something like 70% of IPv6 traffic in the US. >>> >>> And yeah, not doing that - actually in the middle of an IPv6 project at >>> work at the moment that's a bit important to me. >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>> baldur.norddahl at gmail.com> >>> wrote: >>> >>> > Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>> cryptographrix at gmail.com>: >>> > > >>> > > The information I'm getting from Netflix support now is explicitly >>> > telling >>> > > me to turn off IPv6 - someone might want to stop them before they >>> > > completely kill US IPv6 adoption. >>> > >>> > Not allowing he.net tunnels is not killing ipv6. You just need need >>> native >>> > ipv6. >>> > >>> > On the other hand it would be nice if Netflix would try the other >>> protocol >>> > before blocking. >>> > >>> >> >> From cryptographrix at gmail.com Sat Jun 4 00:17:24 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 00:17:24 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Very true. Telling people to turn off IPv6 support through their customer service portal is completely infuriating for those that can't get IPv6 through their ISP and need it. On Fri, Jun 3, 2016 at 8:13 PM Spencer Ryan wrote: > Yes but HE doesn't serve residential users directly. To a normal person HE > is no different than NTT/GTT/Verizon/Sprint/Any other transit carrier. They > may move the most v6 traffic, but Comcast is the largest ISP actually > getting v6 to end users. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 8:07 PM, Cryptographrix > wrote: > >> I don't remember the source, but I do remember that even with Comcast's >> deployment, HE still represented the majority of IPv6 traffic in the US. >> >> Of course, it could just be a bunch of us heavy IPv6 users. >> >> >> >> On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: >> >>> Comcast is near 100% on their DOCSIS network (Busniess and residential). >>> That should be the largest single ISP for IPv6 for end users in the USA. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix >> > wrote: >>> >>>> Depends - how many US users have native IPv6 through their ISPs? >>>> >>>> If I remember correctly (I can't find the source at the moment), HE.net >>>> represents something like 70% of IPv6 traffic in the US. >>>> >>>> And yeah, not doing that - actually in the middle of an IPv6 project at >>>> work at the moment that's a bit important to me. >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>> baldur.norddahl at gmail.com> >>>> wrote: >>>> >>>> > Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>> cryptographrix at gmail.com>: >>>> > > >>>> > > The information I'm getting from Netflix support now is explicitly >>>> > telling >>>> > > me to turn off IPv6 - someone might want to stop them before they >>>> > > completely kill US IPv6 adoption. >>>> > >>>> > Not allowing he.net tunnels is not killing ipv6. You just need need >>>> native >>>> > ipv6. >>>> > >>>> > On the other hand it would be nice if Netflix would try the other >>>> protocol >>>> > before blocking. >>>> > >>>> >>> >>> > From blair.trosper at gmail.com Sat Jun 4 00:21:16 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 3 Jun 2016 17:21:16 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: ...IF (and that's a big IF in the Bay Area at least) you can get the newest modems. Easier said than done. On Fri, Jun 3, 2016 at 5:03 PM, Spencer Ryan wrote: > Comcast is near 100% on their DOCSIS network (Busniess and residential). > That should be the largest single ISP for IPv6 for end users in the USA. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix > wrote: > > > Depends - how many US users have native IPv6 through their ISPs? > > > > If I remember correctly (I can't find the source at the moment), HE.net > > represents something like 70% of IPv6 traffic in the US. > > > > And yeah, not doing that - actually in the middle of an IPv6 project at > > work at the moment that's a bit important to me. > > > > > > > > > > On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > baldur.norddahl at gmail.com> > > wrote: > > > > > Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > cryptographrix at gmail.com > > >: > > > > > > > > The information I'm getting from Netflix support now is explicitly > > > telling > > > > me to turn off IPv6 - someone might want to stop them before they > > > > completely kill US IPv6 adoption. > > > > > > Not allowing he.net tunnels is not killing ipv6. You just need need > > native > > > ipv6. > > > > > > On the other hand it would be nice if Netflix would try the other > > protocol > > > before blocking. > > > > > > From gem at rellim.com Sat Jun 4 00:29:14 2016 From: gem at rellim.com (Gary E. Miller) Date: Fri, 3 Jun 2016 17:29:14 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <20160603172914.5bb93412@spidey.rellim.com> Yo Spencer! On Fri, 3 Jun 2016 20:13:03 -0400 Spencer Ryan wrote: > Yes but HE doesn't serve residential users directly. Really? I am the only one? Doubtful. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Sat Jun 4 00:35:33 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2016 17:35:33 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: I think the day that Netflix tells me to turn off IPv6 or doesn?t serve me content because one of my routes to the internet for IPv6 is via an HE tunnel (the other two are different tunnels, but all of my IPv4 also goes through tunnels) will be the day I tell Netflix that I will turn them off instead. Let?s face it folks, if we want to encourage Netflix to tell the content providers to give up the silly geo-shit, then we have to stop patronizing channels that do silly geo-shit. The only real impact is to vote with your $$$ and tell the companies you are unsubscribing from exactly why you are unsubscribing. So far, I haven?t run into an issue where I couldn?t get what I wanted to watch via a tunnel I was able to set up. When/If Netflix gets good enough to detect and block my tunnel, I?ll stop using Netflix and stop paying them. I?ll also make sure that they know why. I?m sure if they lose enough customers for this reason, they?ll choose to do something about it with their content providers. After all, the fewer subscribers Netflix has, the less they pay the content providers, too. Sure, nobody cares about my $10/month or whatever it?s up to these days, but if a few thousand of us start walking off and it starts to look like a trend, it can change things. Owen > On Jun 3, 2016, at 17:17 , Cryptographrix wrote: > > Very true. Telling people to turn off IPv6 support through their customer > service portal is completely infuriating for those that can't get IPv6 > through their ISP and need it. > > > On Fri, Jun 3, 2016 at 8:13 PM Spencer Ryan wrote: > >> Yes but HE doesn't serve residential users directly. To a normal person HE >> is no different than NTT/GTT/Verizon/Sprint/Any other transit carrier. They >> may move the most v6 traffic, but Comcast is the largest ISP actually >> getting v6 to end users. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 8:07 PM, Cryptographrix >> wrote: >> >>> I don't remember the source, but I do remember that even with Comcast's >>> deployment, HE still represented the majority of IPv6 traffic in the US. >>> >>> Of course, it could just be a bunch of us heavy IPv6 users. >>> >>> >>> >>> On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: >>> >>>> Comcast is near 100% on their DOCSIS network (Busniess and residential). >>>> That should be the largest single ISP for IPv6 for end users in the USA. >>>> >>>> >>>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>>> *Arbor Networks* >>>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>> www.arbornetworks.com >>>> >>>> On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix >>>> wrote: >>>> >>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>> >>>>> If I remember correctly (I can't find the source at the moment), HE.net >>>>> represents something like 70% of IPv6 traffic in the US. >>>>> >>>>> And yeah, not doing that - actually in the middle of an IPv6 project at >>>>> work at the moment that's a bit important to me. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>> baldur.norddahl at gmail.com> >>>>> wrote: >>>>> >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>> cryptographrix at gmail.com>: >>>>>>> >>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>> telling >>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>> completely kill US IPv6 adoption. >>>>>> >>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need >>>>> native >>>>>> ipv6. >>>>>> >>>>>> On the other hand it would be nice if Netflix would try the other >>>>> protocol >>>>>> before blocking. >>>>>> >>>>> >>>> >>>> >> From cryptographrix at gmail.com Sat Jun 4 00:39:37 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 00:39:37 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Yeah today I cancelled Netflix for exactly this reason. On Fri, Jun 3, 2016 at 8:35 PM Owen DeLong wrote: > I think the day that Netflix tells me to turn off IPv6 or doesn?t serve me > content > because one of my routes to the internet for IPv6 is via an HE tunnel (the > other > two are different tunnels, but all of my IPv4 also goes through tunnels) > will be the > day I tell Netflix that I will turn them off instead. > > Let?s face it folks, if we want to encourage Netflix to tell the content > providers > to give up the silly geo-shit, then we have to stop patronizing channels > that do > silly geo-shit. > > The only real impact is to vote with your $$$ and tell the companies you > are > unsubscribing from exactly why you are unsubscribing. > > So far, I haven?t run into an issue where I couldn?t get what I wanted to > watch > via a tunnel I was able to set up. When/If Netflix gets good enough to > detect > and block my tunnel, I?ll stop using Netflix and stop paying them. I?ll > also > make sure that they know why. > > I?m sure if they lose enough customers for this reason, they?ll choose to > do something > about it with their content providers. After all, the fewer subscribers > Netflix has, > the less they pay the content providers, too. > > Sure, nobody cares about my $10/month or whatever it?s up to these days, > but if a > few thousand of us start walking off and it starts to look like a trend, > it can > change things. > > Owen > > > On Jun 3, 2016, at 17:17 , Cryptographrix > wrote: > > > > Very true. Telling people to turn off IPv6 support through their customer > > service portal is completely infuriating for those that can't get IPv6 > > through their ISP and need it. > > > > > > On Fri, Jun 3, 2016 at 8:13 PM Spencer Ryan wrote: > > > >> Yes but HE doesn't serve residential users directly. To a normal person > HE > >> is no different than NTT/GTT/Verizon/Sprint/Any other transit carrier. > They > >> may move the most v6 traffic, but Comcast is the largest ISP actually > >> getting v6 to end users. > >> > >> > >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >> *Arbor Networks* > >> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >> www.arbornetworks.com > >> > >> On Fri, Jun 3, 2016 at 8:07 PM, Cryptographrix < > cryptographrix at gmail.com> > >> wrote: > >> > >>> I don't remember the source, but I do remember that even with Comcast's > >>> deployment, HE still represented the majority of IPv6 traffic in the > US. > >>> > >>> Of course, it could just be a bunch of us heavy IPv6 users. > >>> > >>> > >>> > >>> On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: > >>> > >>>> Comcast is near 100% on their DOCSIS network (Busniess and > residential). > >>>> That should be the largest single ISP for IPv6 for end users in the > USA. > >>>> > >>>> > >>>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >>>> *Arbor Networks* > >>>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>>> www.arbornetworks.com > >>>> > >>>> On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix < > cryptographrix at gmail.com > >>>>> wrote: > >>>> > >>>>> Depends - how many US users have native IPv6 through their ISPs? > >>>>> > >>>>> If I remember correctly (I can't find the source at the moment), > HE.net > >>>>> represents something like 70% of IPv6 traffic in the US. > >>>>> > >>>>> And yeah, not doing that - actually in the middle of an IPv6 project > at > >>>>> work at the moment that's a bit important to me. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >>>>> baldur.norddahl at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >>>>> cryptographrix at gmail.com>: > >>>>>>> > >>>>>>> The information I'm getting from Netflix support now is explicitly > >>>>>> telling > >>>>>>> me to turn off IPv6 - someone might want to stop them before they > >>>>>>> completely kill US IPv6 adoption. > >>>>>> > >>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need > >>>>> native > >>>>>> ipv6. > >>>>>> > >>>>>> On the other hand it would be nice if Netflix would try the other > >>>>> protocol > >>>>>> before blocking. > >>>>>> > >>>>> > >>>> > >>>> > >> > > From magicsata at gmail.com Sat Jun 4 00:41:13 2016 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sat, 4 Jun 2016 01:41:13 +0100 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: +1 On 4 June 2016 at 01:35, Owen DeLong wrote: > I think the day that Netflix tells me to turn off IPv6 or doesn?t serve me > content > because one of my routes to the internet for IPv6 is via an HE tunnel (the > other > two are different tunnels, but all of my IPv4 also goes through tunnels) > will be the > day I tell Netflix that I will turn them off instead. > > Let?s face it folks, if we want to encourage Netflix to tell the content > providers > to give up the silly geo-shit, then we have to stop patronizing channels > that do > silly geo-shit. > > The only real impact is to vote with your $$$ and tell the companies you > are > unsubscribing from exactly why you are unsubscribing. > > So far, I haven?t run into an issue where I couldn?t get what I wanted to > watch > via a tunnel I was able to set up. When/If Netflix gets good enough to > detect > and block my tunnel, I?ll stop using Netflix and stop paying them. I?ll > also > make sure that they know why. > > I?m sure if they lose enough customers for this reason, they?ll choose to > do something > about it with their content providers. After all, the fewer subscribers > Netflix has, > the less they pay the content providers, too. > > Sure, nobody cares about my $10/month or whatever it?s up to these days, > but if a > few thousand of us start walking off and it starts to look like a trend, > it can > change things. > > Owen > > > On Jun 3, 2016, at 17:17 , Cryptographrix > wrote: > > > > Very true. Telling people to turn off IPv6 support through their customer > > service portal is completely infuriating for those that can't get IPv6 > > through their ISP and need it. > > > > > > On Fri, Jun 3, 2016 at 8:13 PM Spencer Ryan wrote: > > > >> Yes but HE doesn't serve residential users directly. To a normal person > HE > >> is no different than NTT/GTT/Verizon/Sprint/Any other transit carrier. > They > >> may move the most v6 traffic, but Comcast is the largest ISP actually > >> getting v6 to end users. > >> > >> > >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >> *Arbor Networks* > >> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >> www.arbornetworks.com > >> > >> On Fri, Jun 3, 2016 at 8:07 PM, Cryptographrix < > cryptographrix at gmail.com> > >> wrote: > >> > >>> I don't remember the source, but I do remember that even with Comcast's > >>> deployment, HE still represented the majority of IPv6 traffic in the > US. > >>> > >>> Of course, it could just be a bunch of us heavy IPv6 users. > >>> > >>> > >>> > >>> On Fri, Jun 3, 2016 at 8:03 PM Spencer Ryan wrote: > >>> > >>>> Comcast is near 100% on their DOCSIS network (Busniess and > residential). > >>>> That should be the largest single ISP for IPv6 for end users in the > USA. > >>>> > >>>> > >>>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >>>> *Arbor Networks* > >>>> +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>>> www.arbornetworks.com > >>>> > >>>> On Fri, Jun 3, 2016 at 7:49 PM, Cryptographrix < > cryptographrix at gmail.com > >>>>> wrote: > >>>> > >>>>> Depends - how many US users have native IPv6 through their ISPs? > >>>>> > >>>>> If I remember correctly (I can't find the source at the moment), > HE.net > >>>>> represents something like 70% of IPv6 traffic in the US. > >>>>> > >>>>> And yeah, not doing that - actually in the middle of an IPv6 project > at > >>>>> work at the moment that's a bit important to me. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >>>>> baldur.norddahl at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >>>>> cryptographrix at gmail.com>: > >>>>>>> > >>>>>>> The information I'm getting from Netflix support now is explicitly > >>>>>> telling > >>>>>>> me to turn off IPv6 - someone might want to stop them before they > >>>>>>> completely kill US IPv6 adoption. > >>>>>> > >>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need > >>>>> native > >>>>>> ipv6. > >>>>>> > >>>>>> On the other hand it would be nice if Netflix would try the other > >>>>> protocol > >>>>>> before blocking. > >>>>>> > >>>>> > >>>> > >>>> > >> > > From lyndon at orthanc.ca Sat Jun 4 00:42:28 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 3 Jun 2016 17:42:28 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <0912F1A7-1DBC-4488-B4E0-BB85FBE7378A@orthanc.ca> > On Jun 3, 2016, at 4:59 PM, jim deleskie wrote: > > I don't suspect many folks that are outside of this list would likely have > any idea how to set up a v6 tunnel. Those of us on the list, likely have a > much greater ability to influence v6 adoption or not via day job > deployments then Netflix supporting v6 tunnels or not. In western Canada, Telus is on a big push to deploy IPv6. TekSavvy less so. But it's happening. I cancelled my Netflix subscription last summer. I needed native IPv6 more than I needed Grace and Frankie. Which isn't to say I didn't want to watch Grace and Frankie more than having IPv6 access to machines I need to have access to in order to earn the money I need to pay to (not) watch Grace and Frankie ... --lyndon From josh at kyneticwifi.com Sat Jun 4 00:46:30 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 3 Jun 2016 19:46:30 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160603172914.5bb93412@spidey.rellim.com> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> Message-ID: You might be one of a handful. On Jun 3, 2016 7:35 PM, "Gary E. Miller" wrote: > Yo Spencer! > > On Fri, 3 Jun 2016 20:13:03 -0400 > Spencer Ryan wrote: > > > Yes but HE doesn't serve residential users directly. > > Really? I am the only one? Doubtful. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > From ganzer at spawar.navy.mil Sat Jun 4 00:54:46 2016 From: ganzer at spawar.navy.mil (Mark T. Ganzer) Date: Fri, 3 Jun 2016 17:54:46 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> So far I am not seeing a Netflix block on my he.net tunnel yet. I connect to the Los Angeles node, so maybe not all of HE's address space is being blocked. Not going to be disabling IPv6 here either. + HAD native IPv6 from Time Warner, but they decided to in their wisdom to disable IPv6 service for anyone that has an Arris SB6183 due to an Arris firmware bug. And they are taking their sweet time pushing out the fixed firmware update that Comcast and Cox seemed to be able to push to their customers last fall. -Mark Ganzer On 6/3/2016 4:49 PM, Cryptographrix wrote: > Depends - how many US users have native IPv6 through their ISPs? > > If I remember correctly (I can't find the source at the moment), HE.net > represents something like 70% of IPv6 traffic in the US. > > And yeah, not doing that - actually in the middle of an IPv6 project at > work at the moment that's a bit important to me. > > > > > On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > wrote: > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" : >>> The information I'm getting from Netflix support now is explicitly >> telling >>> me to turn off IPv6 - someone might want to stop them before they >>> completely kill US IPv6 adoption. >> Not allowing he.net tunnels is not killing ipv6. You just need need native >> ipv6. >> >> On the other hand it would be nice if Netflix would try the other protocol >> before blocking. >> From raymond.beaudoin at icarustech.com Sat Jun 4 01:07:14 2016 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Fri, 3 Jun 2016 20:07:14 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: I wasn't originally affected on my he.net tunnel, but this evening it started blocking. The recommended ACLs are a functional temporary workaround, but I've also opened a request with Netflix. On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer wrote: > So far I am not seeing a Netflix block on my he.net tunnel yet. I connect > to the Los Angeles node, so maybe not all of HE's address space is being > blocked. > > Not going to be disabling IPv6 here either. + HAD native IPv6 from Time > Warner, but they decided to in their wisdom to disable IPv6 service for > anyone that has an Arris SB6183 due to an Arris firmware bug. And they are > taking their sweet time pushing out the fixed firmware update that Comcast > and Cox seemed to be able to push to their customers last fall. > > -Mark Ganzer > > > On 6/3/2016 4:49 PM, Cryptographrix wrote: > >> Depends - how many US users have native IPv6 through their ISPs? >> >> If I remember correctly (I can't find the source at the moment), HE.net >> represents something like 70% of IPv6 traffic in the US. >> >> And yeah, not doing that - actually in the middle of an IPv6 project at >> work at the moment that's a bit important to me. >> >> >> >> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl > > >> wrote: >> >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" : >>> >>>> The information I'm getting from Netflix support now is explicitly >>>> >>> telling >>> >>>> me to turn off IPv6 - someone might want to stop them before they >>>> completely kill US IPv6 adoption. >>>> >>> Not allowing he.net tunnels is not killing ipv6. You just need need >>> native >>> ipv6. >>> >>> On the other hand it would be nice if Netflix would try the other >>> protocol >>> before blocking. >>> >>> > From cryptographrix at gmail.com Sat Jun 4 01:15:33 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 01:15:33 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: Yeah I RAWRed to them pretty hard whilst being as understanding to the CS rep that it wasn't their fault. They thought I was weird as anything. If there are any Verizon FiOS network engineers on the thread, a fellow Verizon employee would thank you kindly for an off-thread email regarding BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you configure my account to listen for route advertisement). Strange that it has to come to this to get "legit" IPv6 service. On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < raymond.beaudoin at icarustech.com> wrote: > I wasn't originally affected on my he.net tunnel, but this evening it > started blocking. The recommended ACLs are a functional temporary > workaround, but I've also opened a request with Netflix. > > On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer > wrote: > > > So far I am not seeing a Netflix block on my he.net tunnel yet. I > connect > > to the Los Angeles node, so maybe not all of HE's address space is being > > blocked. > > > > Not going to be disabling IPv6 here either. + HAD native IPv6 from Time > > Warner, but they decided to in their wisdom to disable IPv6 service for > > anyone that has an Arris SB6183 due to an Arris firmware bug. And they > are > > taking their sweet time pushing out the fixed firmware update that > Comcast > > and Cox seemed to be able to push to their customers last fall. > > > > -Mark Ganzer > > > > > > On 6/3/2016 4:49 PM, Cryptographrix wrote: > > > >> Depends - how many US users have native IPv6 through their ISPs? > >> > >> If I remember correctly (I can't find the source at the moment), HE.net > >> represents something like 70% of IPv6 traffic in the US. > >> > >> And yeah, not doing that - actually in the middle of an IPv6 project at > >> work at the moment that's a bit important to me. > >> > >> > >> > >> > >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > baldur.norddahl at gmail.com > >> > > >> wrote: > >> > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > >>> > >>>> The information I'm getting from Netflix support now is explicitly > >>>> > >>> telling > >>> > >>>> me to turn off IPv6 - someone might want to stop them before they > >>>> completely kill US IPv6 adoption. > >>>> > >>> Not allowing he.net tunnels is not killing ipv6. You just need need > >>> native > >>> ipv6. > >>> > >>> On the other hand it would be nice if Netflix would try the other > >>> protocol > >>> before blocking. > >>> > >>> > > > From raymond.beaudoin at icarustech.com Sat Jun 4 01:24:47 2016 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Fri, 3 Jun 2016 20:24:47 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: As an alternative, there are multiple cloud service offerings that will advertise your IPv6 allocations on your behalf direct to a server in their data centers. It seems pretty tongue-in-cheek, and satisfying, to turn up a * *and then route through it. The Internet is such an amazing place. On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix wrote: > Yeah I RAWRed to them pretty hard whilst being as understanding to the CS > rep that it wasn't their fault. > > They thought I was weird as anything. > > If there are any Verizon FiOS network engineers on the thread, a fellow > Verizon employee would thank you kindly for an off-thread email regarding > BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you > configure my account to listen for route advertisement). > > Strange that it has to come to this to get "legit" IPv6 service. > > > > > On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > >> I wasn't originally affected on my he.net tunnel, but this evening it >> started blocking. The recommended ACLs are a functional temporary >> workaround, but I've also opened a request with Netflix. >> >> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >> wrote: >> >> > So far I am not seeing a Netflix block on my he.net tunnel yet. I >> connect >> > to the Los Angeles node, so maybe not all of HE's address space is being >> > blocked. >> > >> > Not going to be disabling IPv6 here either. + HAD native IPv6 from Time >> > Warner, but they decided to in their wisdom to disable IPv6 service for >> > anyone that has an Arris SB6183 due to an Arris firmware bug. And they >> are >> > taking their sweet time pushing out the fixed firmware update that >> Comcast >> > and Cox seemed to be able to push to their customers last fall. >> > >> > -Mark Ganzer >> > >> > >> > On 6/3/2016 4:49 PM, Cryptographrix wrote: >> > >> >> Depends - how many US users have native IPv6 through their ISPs? >> >> >> >> If I remember correctly (I can't find the source at the moment), HE.net >> >> represents something like 70% of IPv6 traffic in the US. >> >> >> >> And yeah, not doing that - actually in the middle of an IPv6 project at >> >> work at the moment that's a bit important to me. >> >> >> >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >> baldur.norddahl at gmail.com >> >> > >> >> wrote: >> >> >> >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >> cryptographrix at gmail.com>: >> >>> >> >>>> The information I'm getting from Netflix support now is explicitly >> >>>> >> >>> telling >> >>> >> >>>> me to turn off IPv6 - someone might want to stop them before they >> >>>> completely kill US IPv6 adoption. >> >>>> >> >>> Not allowing he.net tunnels is not killing ipv6. You just need need >> >>> native >> >>> ipv6. >> >>> >> >>> On the other hand it would be nice if Netflix would try the other >> >>> protocol >> >>> before blocking. >> >>> >> >>> >> > >> > From sryan at arbor.net Sat Jun 4 01:27:03 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 21:27:03 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: Well if you have PI space just use HE's BGP tunnel offerings. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < raymond.beaudoin at icarustech.com> wrote: > As an alternative, there are multiple cloud service offerings that will > advertise your IPv6 allocations on your behalf direct to a server in their > data centers. It seems pretty tongue-in-cheek, and satisfying, to turn > up a * favorite virtual router instance> *and then route through it. The Internet > is such an amazing place. > > On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix > wrote: > > > Yeah I RAWRed to them pretty hard whilst being as understanding to the CS > > rep that it wasn't their fault. > > > > They thought I was weird as anything. > > > > If there are any Verizon FiOS network engineers on the thread, a fellow > > Verizon employee would thank you kindly for an off-thread email regarding > > BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you > > configure my account to listen for route advertisement). > > > > Strange that it has to come to this to get "legit" IPv6 service. > > > > > > > > > > On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > > raymond.beaudoin at icarustech.com> wrote: > > > >> I wasn't originally affected on my he.net tunnel, but this evening it > >> started blocking. The recommended ACLs are a functional temporary > >> workaround, but I've also opened a request with Netflix. > >> > >> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer > >> wrote: > >> > >> > So far I am not seeing a Netflix block on my he.net tunnel yet. I > >> connect > >> > to the Los Angeles node, so maybe not all of HE's address space is > being > >> > blocked. > >> > > >> > Not going to be disabling IPv6 here either. + HAD native IPv6 from > Time > >> > Warner, but they decided to in their wisdom to disable IPv6 service > for > >> > anyone that has an Arris SB6183 due to an Arris firmware bug. And > they > >> are > >> > taking their sweet time pushing out the fixed firmware update that > >> Comcast > >> > and Cox seemed to be able to push to their customers last fall. > >> > > >> > -Mark Ganzer > >> > > >> > > >> > On 6/3/2016 4:49 PM, Cryptographrix wrote: > >> > > >> >> Depends - how many US users have native IPv6 through their ISPs? > >> >> > >> >> If I remember correctly (I can't find the source at the moment), > HE.net > >> >> represents something like 70% of IPv6 traffic in the US. > >> >> > >> >> And yeah, not doing that - actually in the middle of an IPv6 project > at > >> >> work at the moment that's a bit important to me. > >> >> > >> >> > >> >> > >> >> > >> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >> baldur.norddahl at gmail.com > >> >> > > >> >> wrote: > >> >> > >> >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >> cryptographrix at gmail.com>: > >> >>> > >> >>>> The information I'm getting from Netflix support now is explicitly > >> >>>> > >> >>> telling > >> >>> > >> >>>> me to turn off IPv6 - someone might want to stop them before they > >> >>>> completely kill US IPv6 adoption. > >> >>>> > >> >>> Not allowing he.net tunnels is not killing ipv6. You just need need > >> >>> native > >> >>> ipv6. > >> >>> > >> >>> On the other hand it would be nice if Netflix would try the other > >> >>> protocol > >> >>> before blocking. > >> >>> > >> >>> > >> > > >> > > > From cryptographrix at gmail.com Sat Jun 4 01:31:27 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 01:31:27 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: Honestly I was trying to make that sound like a "missed connections" ad there for a moment, but seriously I'd buy a /40 right now if possible to have non-tunneled IPv6 if I could. It's so weird being on US internet - your content distributor makes you feel like a criminal because their content provider has standing orders to deny you from viewing the content they provide and the only other thing you can do about it is turn off the thing that gives you access to the way you make the money to pay for their stuff. On Fri, Jun 3, 2016 at 9:25 PM Raymond Beaudoin < raymond.beaudoin at icarustech.com> wrote: > As an alternative, there are multiple cloud service offerings that will > advertise your IPv6 allocations on your behalf direct to a server in their > data centers. It seems pretty tongue-in-cheek, and satisfying, to turn up a * favorite virtual router instance> *and then route through it. The > Internet is such an amazing place. > > On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix > wrote: > >> Yeah I RAWRed to them pretty hard whilst being as understanding to the CS >> rep that it wasn't their fault. >> >> They thought I was weird as anything. >> >> If there are any Verizon FiOS network engineers on the thread, a fellow >> Verizon employee would thank you kindly for an off-thread email regarding >> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >> configure my account to listen for route advertisement). >> >> Strange that it has to come to this to get "legit" IPv6 service. >> >> >> >> >> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >> raymond.beaudoin at icarustech.com> wrote: >> >>> I wasn't originally affected on my he.net tunnel, but this evening it >>> started blocking. The recommended ACLs are a functional temporary >>> workaround, but I've also opened a request with Netflix. >>> >>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >>> wrote: >>> >>> > So far I am not seeing a Netflix block on my he.net tunnel yet. I >>> connect >>> > to the Los Angeles node, so maybe not all of HE's address space is >>> being >>> > blocked. >>> > >>> > Not going to be disabling IPv6 here either. + HAD native IPv6 from Time >>> > Warner, but they decided to in their wisdom to disable IPv6 service for >>> > anyone that has an Arris SB6183 due to an Arris firmware bug. And >>> they are >>> > taking their sweet time pushing out the fixed firmware update that >>> Comcast >>> > and Cox seemed to be able to push to their customers last fall. >>> > >>> > -Mark Ganzer >>> > >>> > >>> > On 6/3/2016 4:49 PM, Cryptographrix wrote: >>> > >>> >> Depends - how many US users have native IPv6 through their ISPs? >>> >> >>> >> If I remember correctly (I can't find the source at the moment), >>> HE.net >>> >> represents something like 70% of IPv6 traffic in the US. >>> >> >>> >> And yeah, not doing that - actually in the middle of an IPv6 project >>> at >>> >> work at the moment that's a bit important to me. >>> >> >>> >> >>> >> >>> >> >>> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>> baldur.norddahl at gmail.com >>> >> > >>> >> wrote: >>> >> >>> >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>> cryptographrix at gmail.com>: >>> >>> >>> >>>> The information I'm getting from Netflix support now is explicitly >>> >>>> >>> >>> telling >>> >>> >>> >>>> me to turn off IPv6 - someone might want to stop them before they >>> >>>> completely kill US IPv6 adoption. >>> >>>> >>> >>> Not allowing he.net tunnels is not killing ipv6. You just need need >>> >>> native >>> >>> ipv6. >>> >>> >>> >>> On the other hand it would be nice if Netflix would try the other >>> >>> protocol >>> >>> before blocking. >>> >>> >>> >>> >>> > >>> >> > From raymond.beaudoin at icarustech.com Sat Jun 4 01:32:45 2016 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Fri, 3 Jun 2016 20:32:45 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: Fair point, Spencer! Only Netflix engineers could tell us how they're determining networks to be blocked, but I'm paranoid they're dynamically updating based AS PATH. I figured HE's ASN may have made the naughty list. Admittedly, that would be pretty drastic. Time to do some testing. :> On Fri, Jun 3, 2016 at 8:27 PM, Spencer Ryan wrote: > Well if you have PI space just use HE's BGP tunnel offerings. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > >> As an alternative, there are multiple cloud service offerings that will >> advertise your IPv6 allocations on your behalf direct to a server in their >> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn >> up a *> favorite virtual router instance> *and then route through it. The Internet >> >> is such an amazing place. >> >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix >> wrote: >> >> > Yeah I RAWRed to them pretty hard whilst being as understanding to the >> CS >> > rep that it wasn't their fault. >> > >> > They thought I was weird as anything. >> > >> > If there are any Verizon FiOS network engineers on the thread, a fellow >> > Verizon employee would thank you kindly for an off-thread email >> regarding >> > BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >> > configure my account to listen for route advertisement). >> > >> > Strange that it has to come to this to get "legit" IPv6 service. >> > >> > >> > >> > >> > On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >> > raymond.beaudoin at icarustech.com> wrote: >> > >> >> I wasn't originally affected on my he.net tunnel, but this evening it >> >> started blocking. The recommended ACLs are a functional temporary >> >> workaround, but I've also opened a request with Netflix. >> >> >> >> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer > > >> >> wrote: >> >> >> >> > So far I am not seeing a Netflix block on my he.net tunnel yet. I >> >> connect >> >> > to the Los Angeles node, so maybe not all of HE's address space is >> being >> >> > blocked. >> >> > >> >> > Not going to be disabling IPv6 here either. + HAD native IPv6 from >> Time >> >> > Warner, but they decided to in their wisdom to disable IPv6 service >> for >> >> > anyone that has an Arris SB6183 due to an Arris firmware bug. And >> they >> >> are >> >> > taking their sweet time pushing out the fixed firmware update that >> >> Comcast >> >> > and Cox seemed to be able to push to their customers last fall. >> >> > >> >> > -Mark Ganzer >> >> > >> >> > >> >> > On 6/3/2016 4:49 PM, Cryptographrix wrote: >> >> > >> >> >> Depends - how many US users have native IPv6 through their ISPs? >> >> >> >> >> >> If I remember correctly (I can't find the source at the moment), >> HE.net >> >> >> represents something like 70% of IPv6 traffic in the US. >> >> >> >> >> >> And yeah, not doing that - actually in the middle of an IPv6 >> project at >> >> >> work at the moment that's a bit important to me. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >> >> baldur.norddahl at gmail.com >> >> >> > >> >> >> wrote: >> >> >> >> >> >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >> >> cryptographrix at gmail.com>: >> >> >>> >> >> >>>> The information I'm getting from Netflix support now is explicitly >> >> >>>> >> >> >>> telling >> >> >>> >> >> >>>> me to turn off IPv6 - someone might want to stop them before they >> >> >>>> completely kill US IPv6 adoption. >> >> >>>> >> >> >>> Not allowing he.net tunnels is not killing ipv6. You just need >> need >> >> >>> native >> >> >>> ipv6. >> >> >>> >> >> >>> On the other hand it would be nice if Netflix would try the other >> >> >>> protocol >> >> >>> before blocking. >> >> >>> >> >> >>> >> >> > >> >> >> > >> > > From matthew at matthew.at Sat Jun 4 01:33:02 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 3 Jun 2016 18:33:02 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3db-0524-7 9dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: If early adopter PI IPv6 was the same price as early adopter PI v4 space, my wife would be totally on board with this solution. Matthew Kaufman (Sent from my iPhone) > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: > > Well if you have PI space just use HE's BGP tunnel offerings. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > >> As an alternative, there are multiple cloud service offerings that will >> advertise your IPv6 allocations on your behalf direct to a server in their >> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn >> up a *> favorite virtual router instance> *and then route through it. The Internet >> is such an amazing place. >> >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix >> wrote: >> >>> Yeah I RAWRed to them pretty hard whilst being as understanding to the CS >>> rep that it wasn't their fault. >>> >>> They thought I was weird as anything. >>> >>> If there are any Verizon FiOS network engineers on the thread, a fellow >>> Verizon employee would thank you kindly for an off-thread email regarding >>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >>> configure my account to listen for route advertisement). >>> >>> Strange that it has to come to this to get "legit" IPv6 service. >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>> raymond.beaudoin at icarustech.com> wrote: >>> >>>> I wasn't originally affected on my he.net tunnel, but this evening it >>>> started blocking. The recommended ACLs are a functional temporary >>>> workaround, but I've also opened a request with Netflix. >>>> >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >>>> wrote: >>>> >>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >>>> connect >>>>> to the Los Angeles node, so maybe not all of HE's address space is >> being >>>>> blocked. >>>>> >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from >> Time >>>>> Warner, but they decided to in their wisdom to disable IPv6 service >> for >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >> they >>>> are >>>>> taking their sweet time pushing out the fixed firmware update that >>>> Comcast >>>>> and Cox seemed to be able to push to their customers last fall. >>>>> >>>>> -Mark Ganzer >>>>> >>>>> >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>>> >>>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>>> >>>>>> If I remember correctly (I can't find the source at the moment), >> HE.net >>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>> >>>>>> And yeah, not doing that - actually in the middle of an IPv6 project >> at >>>>>> work at the moment that's a bit important to me. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>> baldur.norddahl at gmail.com >>>>>> wrote: >>>>>> >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>> cryptographrix at gmail.com>: >>>>>>> >>>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>>> telling >>>>>>> >>>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>>> completely kill US IPv6 adoption. >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need >>>>>>> native >>>>>>> ipv6. >>>>>>> >>>>>>> On the other hand it would be nice if Netflix would try the other >>>>>>> protocol >>>>>>> before blocking. >> From cryptographrix at gmail.com Sat Jun 4 01:40:45 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 01:40:45 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: We should crowdsource a /40 and split it up into /64's for each of us. On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman wrote: > If early adopter PI IPv6 was the same price as early adopter PI v4 space, > my wife would be totally on board with this solution. > > Matthew Kaufman > > (Sent from my iPhone) > > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: > > > > Well if you have PI space just use HE's BGP tunnel offerings. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > *Arbor Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > > raymond.beaudoin at icarustech.com> wrote: > > > >> As an alternative, there are multiple cloud service offerings that will > >> advertise your IPv6 allocations on your behalf direct to a server in > their > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn > >> up a * >> favorite virtual router instance> *and then route through it. The > Internet > >> is such an amazing place. > >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < > cryptographrix at gmail.com> > >> wrote: > >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding to the > CS > >>> rep that it wasn't their fault. > >>> > >>> They thought I was weird as anything. > >>> > >>> If there are any Verizon FiOS network engineers on the thread, a fellow > >>> Verizon employee would thank you kindly for an off-thread email > regarding > >>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you > >>> configure my account to listen for route advertisement). > >>> > >>> Strange that it has to come to this to get "legit" IPv6 service. > >>> > >>> > >>> > >>> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > >>> raymond.beaudoin at icarustech.com> wrote: > >>> > >>>> I wasn't originally affected on my he.net tunnel, but this evening it > >>>> started blocking. The recommended ACLs are a functional temporary > >>>> workaround, but I've also opened a request with Netflix. > >>>> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < > ganzer at spawar.navy.mil> > >>>> wrote: > >>>> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I > >>>> connect > >>>>> to the Los Angeles node, so maybe not all of HE's address space is > >> being > >>>>> blocked. > >>>>> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from > >> Time > >>>>> Warner, but they decided to in their wisdom to disable IPv6 service > >> for > >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And > >> they > >>>> are > >>>>> taking their sweet time pushing out the fixed firmware update that > >>>> Comcast > >>>>> and Cox seemed to be able to push to their customers last fall. > >>>>> > >>>>> -Mark Ganzer > >>>>> > >>>>> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: > >>>>>> > >>>>>> Depends - how many US users have native IPv6 through their ISPs? > >>>>>> > >>>>>> If I remember correctly (I can't find the source at the moment), > >> HE.net > >>>>>> represents something like 70% of IPv6 traffic in the US. > >>>>>> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 project > >> at > >>>>>> work at the moment that's a bit important to me. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >>>> baldur.norddahl at gmail.com > >>>>>> wrote: > >>>>>> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >>>> cryptographrix at gmail.com>: > >>>>>>> > >>>>>>>> The information I'm getting from Netflix support now is explicitly > >>>>>>> telling > >>>>>>> > >>>>>>>> me to turn off IPv6 - someone might want to stop them before they > >>>>>>>> completely kill US IPv6 adoption. > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need > need > >>>>>>> native > >>>>>>> ipv6. > >>>>>>> > >>>>>>> On the other hand it would be nice if Netflix would try the other > >>>>>>> protocol > >>>>>>> before blocking. > >> > > From raymond.beaudoin at icarustech.com Sat Jun 4 01:48:16 2016 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Fri, 3 Jun 2016 20:48:16 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Make it a /56 each and you've got a deal. Hell, I'll throw in a round of drinks. On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix wrote: > We should crowdsource a /40 and split it up into /64's for each of us. > > > On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman wrote: > > > If early adopter PI IPv6 was the same price as early adopter PI v4 space, > > my wife would be totally on board with this solution. > > > > Matthew Kaufman > > > > (Sent from my iPhone) > > > > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: > > > > > > Well if you have PI space just use HE's BGP tunnel offerings. > > > > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > > *Arbor Networks* > > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > > www.arbornetworks.com > > > > > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > > > raymond.beaudoin at icarustech.com> wrote: > > > > > >> As an alternative, there are multiple cloud service offerings that > will > > >> advertise your IPv6 allocations on your behalf direct to a server in > > their > > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn > > >> up a * > >> favorite virtual router instance> *and then route through it. The > > Internet > > >> is such an amazing place. > > >> > > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < > > cryptographrix at gmail.com> > > >> wrote: > > >> > > >>> Yeah I RAWRed to them pretty hard whilst being as understanding to > the > > CS > > >>> rep that it wasn't their fault. > > >>> > > >>> They thought I was weird as anything. > > >>> > > >>> If there are any Verizon FiOS network engineers on the thread, a > fellow > > >>> Verizon employee would thank you kindly for an off-thread email > > regarding > > >>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, > you > > >>> configure my account to listen for route advertisement). > > >>> > > >>> Strange that it has to come to this to get "legit" IPv6 service. > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > > >>> raymond.beaudoin at icarustech.com> wrote: > > >>> > > >>>> I wasn't originally affected on my he.net tunnel, but this evening > it > > >>>> started blocking. The recommended ACLs are a functional temporary > > >>>> workaround, but I've also opened a request with Netflix. > > >>>> > > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < > > ganzer at spawar.navy.mil> > > >>>> wrote: > > >>>> > > >>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I > > >>>> connect > > >>>>> to the Los Angeles node, so maybe not all of HE's address space is > > >> being > > >>>>> blocked. > > >>>>> > > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from > > >> Time > > >>>>> Warner, but they decided to in their wisdom to disable IPv6 service > > >> for > > >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And > > >> they > > >>>> are > > >>>>> taking their sweet time pushing out the fixed firmware update that > > >>>> Comcast > > >>>>> and Cox seemed to be able to push to their customers last fall. > > >>>>> > > >>>>> -Mark Ganzer > > >>>>> > > >>>>> > > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: > > >>>>>> > > >>>>>> Depends - how many US users have native IPv6 through their ISPs? > > >>>>>> > > >>>>>> If I remember correctly (I can't find the source at the moment), > > >> HE.net > > >>>>>> represents something like 70% of IPv6 traffic in the US. > > >>>>>> > > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 > project > > >> at > > >>>>>> work at the moment that's a bit important to me. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > > >>>> baldur.norddahl at gmail.com > > >>>>>> wrote: > > >>>>>> > > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > > >>>> cryptographrix at gmail.com>: > > >>>>>>> > > >>>>>>>> The information I'm getting from Netflix support now is > explicitly > > >>>>>>> telling > > >>>>>>> > > >>>>>>>> me to turn off IPv6 - someone might want to stop them before > they > > >>>>>>>> completely kill US IPv6 adoption. > > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need > > need > > >>>>>>> native > > >>>>>>> ipv6. > > >>>>>>> > > >>>>>>> On the other hand it would be nice if Netflix would try the other > > >>>>>>> protocol > > >>>>>>> before blocking. > > >> > > > > > From cryptographrix at gmail.com Sat Jun 4 01:49:39 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 01:49:39 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: This is a good idea. We should do this. On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < raymond.beaudoin at icarustech.com> wrote: > Make it a /56 each and you've got a deal. Hell, I'll throw in a round of > drinks. > > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix > wrote: > >> We should crowdsource a /40 and split it up into /64's for each of us. >> >> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >> wrote: >> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >> space, >> > my wife would be totally on board with this solution. >> > >> > Matthew Kaufman >> > >> > (Sent from my iPhone) >> > >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >> > > >> > > Well if you have PI space just use HE's BGP tunnel offerings. >> > > >> > > >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> > > *Arbor Networks* >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >> > > www.arbornetworks.com >> > > >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >> > > raymond.beaudoin at icarustech.com> wrote: >> > > >> > >> As an alternative, there are multiple cloud service offerings that >> will >> > >> advertise your IPv6 allocations on your behalf direct to a server in >> > their >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to >> turn >> > >> up a *> > >> favorite virtual router instance> *and then route through it. The >> > Internet >> > >> is such an amazing place. >> > >> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >> > cryptographrix at gmail.com> >> > >> wrote: >> > >> >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding to >> the >> > CS >> > >>> rep that it wasn't their fault. >> > >>> >> > >>> They thought I was weird as anything. >> > >>> >> > >>> If there are any Verizon FiOS network engineers on the thread, a >> fellow >> > >>> Verizon employee would thank you kindly for an off-thread email >> > regarding >> > >>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, >> you >> > >>> configure my account to listen for route advertisement). >> > >>> >> > >>> Strange that it has to come to this to get "legit" IPv6 service. >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >> > >>> raymond.beaudoin at icarustech.com> wrote: >> > >>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >> evening it >> > >>>> started blocking. The recommended ACLs are a functional temporary >> > >>>> workaround, but I've also opened a request with Netflix. >> > >>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >> > ganzer at spawar.navy.mil> >> > >>>> wrote: >> > >>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >> > >>>> connect >> > >>>>> to the Los Angeles node, so maybe not all of HE's address space is >> > >> being >> > >>>>> blocked. >> > >>>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from >> > >> Time >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >> service >> > >> for >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >> > >> they >> > >>>> are >> > >>>>> taking their sweet time pushing out the fixed firmware update that >> > >>>> Comcast >> > >>>>> and Cox seemed to be able to push to their customers last fall. >> > >>>>> >> > >>>>> -Mark Ganzer >> > >>>>> >> > >>>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >> > >>>>>> >> > >>>>>> Depends - how many US users have native IPv6 through their ISPs? >> > >>>>>> >> > >>>>>> If I remember correctly (I can't find the source at the moment), >> > >> HE.net >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >> > >>>>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >> project >> > >> at >> > >>>>>> work at the moment that's a bit important to me. >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >> > >>>> baldur.norddahl at gmail.com >> > >>>>>> wrote: >> > >>>>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >> > >>>> cryptographrix at gmail.com>: >> > >>>>>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >> explicitly >> > >>>>>>> telling >> > >>>>>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them before >> they >> > >>>>>>>> completely kill US IPv6 adoption. >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need >> > need >> > >>>>>>> native >> > >>>>>>> ipv6. >> > >>>>>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >> other >> > >>>>>>> protocol >> > >>>>>>> before blocking. >> > >> >> > >> > >> > > From mnathani.lists at gmail.com Sat Jun 4 02:09:35 2016 From: mnathani.lists at gmail.com (Mansoor Nathani) Date: Fri, 3 Jun 2016 22:09:35 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Wouldn't the /56 get blocked as soon as Netflix detects multiple accounts logging in from the same IPv6 range? On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix wrote: > This is a good idea. We should do this. > > > > On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > > > Make it a /56 each and you've got a deal. Hell, I'll throw in a round of > > drinks. > > > > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix > > > wrote: > > > >> We should crowdsource a /40 and split it up into /64's for each of us. > >> > >> > >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman > >> wrote: > >> > >> > If early adopter PI IPv6 was the same price as early adopter PI v4 > >> space, > >> > my wife would be totally on board with this solution. > >> > > >> > Matthew Kaufman > >> > > >> > (Sent from my iPhone) > >> > > >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: > >> > > > >> > > Well if you have PI space just use HE's BGP tunnel offerings. > >> > > > >> > > > >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >> > > *Arbor Networks* > >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > >> > > www.arbornetworks.com > >> > > > >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > >> > > raymond.beaudoin at icarustech.com> wrote: > >> > > > >> > >> As an alternative, there are multiple cloud service offerings that > >> will > >> > >> advertise your IPv6 allocations on your behalf direct to a server > in > >> > their > >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to > >> turn > >> > >> up a * >> > >> favorite virtual router instance> *and then route through it. The > >> > Internet > >> > >> is such an amazing place. > >> > >> > >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < > >> > cryptographrix at gmail.com> > >> > >> wrote: > >> > >> > >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding to > >> the > >> > CS > >> > >>> rep that it wasn't their fault. > >> > >>> > >> > >>> They thought I was weird as anything. > >> > >>> > >> > >>> If there are any Verizon FiOS network engineers on the thread, a > >> fellow > >> > >>> Verizon employee would thank you kindly for an off-thread email > >> > regarding > >> > >>> BGP advertisement (I'll buy the IPv6 block and the > drink-of-choice, > >> you > >> > >>> configure my account to listen for route advertisement). > >> > >>> > >> > >>> Strange that it has to come to this to get "legit" IPv6 service. > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > >> > >>> raymond.beaudoin at icarustech.com> wrote: > >> > >>> > >> > >>>> I wasn't originally affected on my he.net tunnel, but this > >> evening it > >> > >>>> started blocking. The recommended ACLs are a functional temporary > >> > >>>> workaround, but I've also opened a request with Netflix. > >> > >>>> > >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < > >> > ganzer at spawar.navy.mil> > >> > >>>> wrote: > >> > >>>> > >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel > yet. I > >> > >>>> connect > >> > >>>>> to the Los Angeles node, so maybe not all of HE's address space > is > >> > >> being > >> > >>>>> blocked. > >> > >>>>> > >> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 > from > >> > >> Time > >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 > >> service > >> > >> for > >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. > And > >> > >> they > >> > >>>> are > >> > >>>>> taking their sweet time pushing out the fixed firmware update > that > >> > >>>> Comcast > >> > >>>>> and Cox seemed to be able to push to their customers last fall. > >> > >>>>> > >> > >>>>> -Mark Ganzer > >> > >>>>> > >> > >>>>> > >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: > >> > >>>>>> > >> > >>>>>> Depends - how many US users have native IPv6 through their > ISPs? > >> > >>>>>> > >> > >>>>>> If I remember correctly (I can't find the source at the > moment), > >> > >> HE.net > >> > >>>>>> represents something like 70% of IPv6 traffic in the US. > >> > >>>>>> > >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 > >> project > >> > >> at > >> > >>>>>> work at the moment that's a bit important to me. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >> > >>>> baldur.norddahl at gmail.com > >> > >>>>>> wrote: > >> > >>>>>> > >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >> > >>>> cryptographrix at gmail.com>: > >> > >>>>>>> > >> > >>>>>>>> The information I'm getting from Netflix support now is > >> explicitly > >> > >>>>>>> telling > >> > >>>>>>> > >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them before > >> they > >> > >>>>>>>> completely kill US IPv6 adoption. > >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just > need > >> > need > >> > >>>>>>> native > >> > >>>>>>> ipv6. > >> > >>>>>>> > >> > >>>>>>> On the other hand it would be nice if Netflix would try the > >> other > >> > >>>>>>> protocol > >> > >>>>>>> before blocking. > >> > >> > >> > > >> > > >> > > > > > From cryptographrix at gmail.com Sat Jun 4 02:11:16 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 02:11:16 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Nope - You'd have the /56 and only people within your /56 (or /64 if you sliced it up nicely) would be able to do things with it routed by your ISP. Of course this means we'll have to get our ISPs to listen for our BGP advertisement... On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani wrote: > Wouldn't the /56 get blocked as soon as Netflix detects multiple accounts > logging in from the same IPv6 range? > > On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix > wrote: > >> This is a good idea. We should do this. >> >> >> >> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >> raymond.beaudoin at icarustech.com> wrote: >> >> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round of >> > drinks. >> > >> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >> cryptographrix at gmail.com> >> > wrote: >> > >> >> We should crowdsource a /40 and split it up into /64's for each of us. >> >> >> >> >> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >> >> wrote: >> >> >> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >> >> space, >> >> > my wife would be totally on board with this solution. >> >> > >> >> > Matthew Kaufman >> >> > >> >> > (Sent from my iPhone) >> >> > >> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >> >> > > >> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >> >> > > >> >> > > >> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> >> > > *Arbor Networks* >> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >> >> > > www.arbornetworks.com >> >> > > >> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >> >> > > raymond.beaudoin at icarustech.com> wrote: >> >> > > >> >> > >> As an alternative, there are multiple cloud service offerings that >> >> will >> >> > >> advertise your IPv6 allocations on your behalf direct to a server >> in >> >> > their >> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to >> >> turn >> >> > >> up a *> >> > >> favorite virtual router instance> *and then route through it. The >> >> > Internet >> >> > >> is such an amazing place. >> >> > >> >> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >> >> > cryptographrix at gmail.com> >> >> > >> wrote: >> >> > >> >> >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding >> to >> >> the >> >> > CS >> >> > >>> rep that it wasn't their fault. >> >> > >>> >> >> > >>> They thought I was weird as anything. >> >> > >>> >> >> > >>> If there are any Verizon FiOS network engineers on the thread, a >> >> fellow >> >> > >>> Verizon employee would thank you kindly for an off-thread email >> >> > regarding >> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >> drink-of-choice, >> >> you >> >> > >>> configure my account to listen for route advertisement). >> >> > >>> >> >> > >>> Strange that it has to come to this to get "legit" IPv6 service. >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >> >> > >>> raymond.beaudoin at icarustech.com> wrote: >> >> > >>> >> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >> >> evening it >> >> > >>>> started blocking. The recommended ACLs are a functional >> temporary >> >> > >>>> workaround, but I've also opened a request with Netflix. >> >> > >>>> >> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >> >> > ganzer at spawar.navy.mil> >> >> > >>>> wrote: >> >> > >>>> >> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >> yet. I >> >> > >>>> connect >> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >> space is >> >> > >> being >> >> > >>>>> blocked. >> >> > >>>>> >> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 >> from >> >> > >> Time >> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >> >> service >> >> > >> for >> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. >> And >> >> > >> they >> >> > >>>> are >> >> > >>>>> taking their sweet time pushing out the fixed firmware update >> that >> >> > >>>> Comcast >> >> > >>>>> and Cox seemed to be able to push to their customers last fall. >> >> > >>>>> >> >> > >>>>> -Mark Ganzer >> >> > >>>>> >> >> > >>>>> >> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >> >> > >>>>>> >> >> > >>>>>> Depends - how many US users have native IPv6 through their >> ISPs? >> >> > >>>>>> >> >> > >>>>>> If I remember correctly (I can't find the source at the >> moment), >> >> > >> HE.net >> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >> >> > >>>>>> >> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >> >> project >> >> > >> at >> >> > >>>>>> work at the moment that's a bit important to me. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >> >> > >>>> baldur.norddahl at gmail.com >> >> > >>>>>> wrote: >> >> > >>>>>> >> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >> >> > >>>> cryptographrix at gmail.com>: >> >> > >>>>>>> >> >> > >>>>>>>> The information I'm getting from Netflix support now is >> >> explicitly >> >> > >>>>>>> telling >> >> > >>>>>>> >> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them before >> >> they >> >> > >>>>>>>> completely kill US IPv6 adoption. >> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just >> need >> >> > need >> >> > >>>>>>> native >> >> > >>>>>>> ipv6. >> >> > >>>>>>> >> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >> >> other >> >> > >>>>>>> protocol >> >> > >>>>>>> before blocking. >> >> > >> >> >> > >> >> > >> >> >> > >> > >> > > From mnathani.lists at gmail.com Sat Jun 4 02:15:18 2016 From: mnathani.lists at gmail.com (Mansoor Nathani) Date: Fri, 3 Jun 2016 22:15:18 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: The smallest IPv6 prefix for advertising on the Internet via BGP is a /48, isn't it? On Fri, Jun 3, 2016 at 10:11 PM, Cryptographrix wrote: > Nope - You'd have the /56 and only people within your /56 (or /64 if you > sliced it up nicely) would be able to do things with it routed by your ISP. > > Of course this means we'll have to get our ISPs to listen for our BGP > advertisement... > > > On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani > wrote: > >> Wouldn't the /56 get blocked as soon as Netflix detects multiple accounts >> logging in from the same IPv6 range? >> >> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix >> wrote: >> >>> This is a good idea. We should do this. >>> >>> >>> >>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>> raymond.beaudoin at icarustech.com> wrote: >>> >>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round >>> of >>> > drinks. >>> > >>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>> cryptographrix at gmail.com> >>> > wrote: >>> > >>> >> We should crowdsource a /40 and split it up into /64's for each of us. >>> >> >>> >> >>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>> >> wrote: >>> >> >>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>> >> space, >>> >> > my wife would be totally on board with this solution. >>> >> > >>> >> > Matthew Kaufman >>> >> > >>> >> > (Sent from my iPhone) >>> >> > >>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >>> >> > > >>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>> >> > > >>> >> > > >>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> >> > > *Arbor Networks* >>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> >> > > www.arbornetworks.com >>> >> > > >>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>> >> > > raymond.beaudoin at icarustech.com> wrote: >>> >> > > >>> >> > >> As an alternative, there are multiple cloud service offerings >>> that >>> >> will >>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>> server in >>> >> > their >>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to >>> >> turn >>> >> > >> up a *>> >> > >> favorite virtual router instance> *and then route through it. The >>> >> > Internet >>> >> > >> is such an amazing place. >>> >> > >> >>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>> >> > cryptographrix at gmail.com> >>> >> > >> wrote: >>> >> > >> >>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding >>> to >>> >> the >>> >> > CS >>> >> > >>> rep that it wasn't their fault. >>> >> > >>> >>> >> > >>> They thought I was weird as anything. >>> >> > >>> >>> >> > >>> If there are any Verizon FiOS network engineers on the thread, a >>> >> fellow >>> >> > >>> Verizon employee would thank you kindly for an off-thread email >>> >> > regarding >>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>> drink-of-choice, >>> >> you >>> >> > >>> configure my account to listen for route advertisement). >>> >> > >>> >>> >> > >>> Strange that it has to come to this to get "legit" IPv6 service. >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>> >> > >>> >>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>> >> evening it >>> >> > >>>> started blocking. The recommended ACLs are a functional >>> temporary >>> >> > >>>> workaround, but I've also opened a request with Netflix. >>> >> > >>>> >>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>> >> > ganzer at spawar.navy.mil> >>> >> > >>>> wrote: >>> >> > >>>> >>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>> yet. I >>> >> > >>>> connect >>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>> space is >>> >> > >> being >>> >> > >>>>> blocked. >>> >> > >>>>> >>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 >>> from >>> >> > >> Time >>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>> >> service >>> >> > >> for >>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>> bug. And >>> >> > >> they >>> >> > >>>> are >>> >> > >>>>> taking their sweet time pushing out the fixed firmware update >>> that >>> >> > >>>> Comcast >>> >> > >>>>> and Cox seemed to be able to push to their customers last >>> fall. >>> >> > >>>>> >>> >> > >>>>> -Mark Ganzer >>> >> > >>>>> >>> >> > >>>>> >>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>> >> > >>>>>> >>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>> ISPs? >>> >> > >>>>>> >>> >> > >>>>>> If I remember correctly (I can't find the source at the >>> moment), >>> >> > >> HE.net >>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>> >> > >>>>>> >>> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >>> >> project >>> >> > >> at >>> >> > >>>>>> work at the moment that's a bit important to me. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>> >> > >>>> baldur.norddahl at gmail.com >>> >> > >>>>>> wrote: >>> >> > >>>>>> >>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>> >> > >>>> cryptographrix at gmail.com>: >>> >> > >>>>>>> >>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>> >> explicitly >>> >> > >>>>>>> telling >>> >> > >>>>>>> >>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>> before >>> >> they >>> >> > >>>>>>>> completely kill US IPv6 adoption. >>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just >>> need >>> >> > need >>> >> > >>>>>>> native >>> >> > >>>>>>> ipv6. >>> >> > >>>>>>> >>> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >>> >> other >>> >> > >>>>>>> protocol >>> >> > >>>>>>> before blocking. >>> >> > >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> From sryan at arbor.net Sat Jun 4 02:18:30 2016 From: sryan at arbor.net (Spencer Ryan) Date: Fri, 3 Jun 2016 22:18:30 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Typically, yes. On Jun 3, 2016 10:15 PM, "Mansoor Nathani" wrote: > The smallest IPv6 prefix for advertising on the Internet via BGP is a /48, > isn't it? > > On Fri, Jun 3, 2016 at 10:11 PM, Cryptographrix > wrote: > > > Nope - You'd have the /56 and only people within your /56 (or /64 if you > > sliced it up nicely) would be able to do things with it routed by your > ISP. > > > > Of course this means we'll have to get our ISPs to listen for our BGP > > advertisement... > > > > > > On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani < > mnathani.lists at gmail.com> > > wrote: > > > >> Wouldn't the /56 get blocked as soon as Netflix detects multiple > accounts > >> logging in from the same IPv6 range? > >> > >> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix < > cryptographrix at gmail.com> > >> wrote: > >> > >>> This is a good idea. We should do this. > >>> > >>> > >>> > >>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < > >>> raymond.beaudoin at icarustech.com> wrote: > >>> > >>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round > >>> of > >>> > drinks. > >>> > > >>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < > >>> cryptographrix at gmail.com> > >>> > wrote: > >>> > > >>> >> We should crowdsource a /40 and split it up into /64's for each of > us. > >>> >> > >>> >> > >>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman > >>> >> wrote: > >>> >> > >>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 > >>> >> space, > >>> >> > my wife would be totally on board with this solution. > >>> >> > > >>> >> > Matthew Kaufman > >>> >> > > >>> >> > (Sent from my iPhone) > >>> >> > > >>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan > wrote: > >>> >> > > > >>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. > >>> >> > > > >>> >> > > > >>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > >>> >> > > *Arbor Networks* > >>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > >>> >> > > www.arbornetworks.com > >>> >> > > > >>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < > >>> >> > > raymond.beaudoin at icarustech.com> wrote: > >>> >> > > > >>> >> > >> As an alternative, there are multiple cloud service offerings > >>> that > >>> >> will > >>> >> > >> advertise your IPv6 allocations on your behalf direct to a > >>> server in > >>> >> > their > >>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, > to > >>> >> turn > >>> >> > >> up a * >>> >> > >> favorite virtual router instance> *and then route through it. > The > >>> >> > Internet > >>> >> > >> is such an amazing place. > >>> >> > >> > >>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < > >>> >> > cryptographrix at gmail.com> > >>> >> > >> wrote: > >>> >> > >> > >>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as > understanding > >>> to > >>> >> the > >>> >> > CS > >>> >> > >>> rep that it wasn't their fault. > >>> >> > >>> > >>> >> > >>> They thought I was weird as anything. > >>> >> > >>> > >>> >> > >>> If there are any Verizon FiOS network engineers on the > thread, a > >>> >> fellow > >>> >> > >>> Verizon employee would thank you kindly for an off-thread > email > >>> >> > regarding > >>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the > >>> drink-of-choice, > >>> >> you > >>> >> > >>> configure my account to listen for route advertisement). > >>> >> > >>> > >>> >> > >>> Strange that it has to come to this to get "legit" IPv6 > service. > >>> >> > >>> > >>> >> > >>> > >>> >> > >>> > >>> >> > >>> > >>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < > >>> >> > >>> raymond.beaudoin at icarustech.com> wrote: > >>> >> > >>> > >>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this > >>> >> evening it > >>> >> > >>>> started blocking. The recommended ACLs are a functional > >>> temporary > >>> >> > >>>> workaround, but I've also opened a request with Netflix. > >>> >> > >>>> > >>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < > >>> >> > ganzer at spawar.navy.mil> > >>> >> > >>>> wrote: > >>> >> > >>>> > >>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel > >>> yet. I > >>> >> > >>>> connect > >>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address > >>> space is > >>> >> > >> being > >>> >> > >>>>> blocked. > >>> >> > >>>>> > >>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native > IPv6 > >>> from > >>> >> > >> Time > >>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 > >>> >> service > >>> >> > >> for > >>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware > >>> bug. And > >>> >> > >> they > >>> >> > >>>> are > >>> >> > >>>>> taking their sweet time pushing out the fixed firmware > update > >>> that > >>> >> > >>>> Comcast > >>> >> > >>>>> and Cox seemed to be able to push to their customers last > >>> fall. > >>> >> > >>>>> > >>> >> > >>>>> -Mark Ganzer > >>> >> > >>>>> > >>> >> > >>>>> > >>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: > >>> >> > >>>>>> > >>> >> > >>>>>> Depends - how many US users have native IPv6 through their > >>> ISPs? > >>> >> > >>>>>> > >>> >> > >>>>>> If I remember correctly (I can't find the source at the > >>> moment), > >>> >> > >> HE.net > >>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. > >>> >> > >>>>>> > >>> >> > >>>>>> And yeah, not doing that - actually in the middle of an > IPv6 > >>> >> project > >>> >> > >> at > >>> >> > >>>>>> work at the moment that's a bit important to me. > >>> >> > >>>>>> > >>> >> > >>>>>> > >>> >> > >>>>>> > >>> >> > >>>>>> > >>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < > >>> >> > >>>> baldur.norddahl at gmail.com > >>> >> > >>>>>> wrote: > >>> >> > >>>>>> > >>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < > >>> >> > >>>> cryptographrix at gmail.com>: > >>> >> > >>>>>>> > >>> >> > >>>>>>>> The information I'm getting from Netflix support now is > >>> >> explicitly > >>> >> > >>>>>>> telling > >>> >> > >>>>>>> > >>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them > >>> before > >>> >> they > >>> >> > >>>>>>>> completely kill US IPv6 adoption. > >>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just > >>> need > >>> >> > need > >>> >> > >>>>>>> native > >>> >> > >>>>>>> ipv6. > >>> >> > >>>>>>> > >>> >> > >>>>>>> On the other hand it would be nice if Netflix would try > the > >>> >> other > >>> >> > >>>>>>> protocol > >>> >> > >>>>>>> before blocking. > >>> >> > >> > >>> >> > > >>> >> > > >>> >> > >>> > > >>> > > >>> > >> > >> > From cryptographrix at gmail.com Sat Jun 4 02:19:44 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 02:19:44 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: "A /48 is officially the smallest"...but apparently smaller gets advertised all over, and I imagine esp for private ASNs...sooooo we buy a /40 and 256 people here get /48s? That would also be hilarious if Netflix blocking HE resulted in 256-some people each getting a /48. On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix wrote: > Nope - You'd have the /56 and only people within your /56 (or /64 if you > sliced it up nicely) would be able to do things with it routed by your ISP. > > Of course this means we'll have to get our ISPs to listen for our BGP > advertisement... > > > On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani > wrote: > >> Wouldn't the /56 get blocked as soon as Netflix detects multiple accounts >> logging in from the same IPv6 range? >> >> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix >> wrote: >> >>> This is a good idea. We should do this. >>> >>> >>> >>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>> raymond.beaudoin at icarustech.com> wrote: >>> >>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round >>> of >>> > drinks. >>> > >>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>> cryptographrix at gmail.com> >>> > wrote: >>> > >>> >> We should crowdsource a /40 and split it up into /64's for each of us. >>> >> >>> >> >>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>> >> wrote: >>> >> >>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>> >> space, >>> >> > my wife would be totally on board with this solution. >>> >> > >>> >> > Matthew Kaufman >>> >> > >>> >> > (Sent from my iPhone) >>> >> > >>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >>> >> > > >>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>> >> > > >>> >> > > >>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> >> > > *Arbor Networks* >>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> >> > > www.arbornetworks.com >>> >> > > >>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>> >> > > raymond.beaudoin at icarustech.com> wrote: >>> >> > > >>> >> > >> As an alternative, there are multiple cloud service offerings >>> that >>> >> will >>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>> server in >>> >> > their >>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, to >>> >> turn >>> >> > >> up a *>> >> > >> favorite virtual router instance> *and then route through it. The >>> >> > Internet >>> >> > >> is such an amazing place. >>> >> > >> >>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>> >> > cryptographrix at gmail.com> >>> >> > >> wrote: >>> >> > >> >>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as understanding >>> to >>> >> the >>> >> > CS >>> >> > >>> rep that it wasn't their fault. >>> >> > >>> >>> >> > >>> They thought I was weird as anything. >>> >> > >>> >>> >> > >>> If there are any Verizon FiOS network engineers on the thread, a >>> >> fellow >>> >> > >>> Verizon employee would thank you kindly for an off-thread email >>> >> > regarding >>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>> drink-of-choice, >>> >> you >>> >> > >>> configure my account to listen for route advertisement). >>> >> > >>> >>> >> > >>> Strange that it has to come to this to get "legit" IPv6 service. >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>> >> > >>> >>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>> >> evening it >>> >> > >>>> started blocking. The recommended ACLs are a functional >>> temporary >>> >> > >>>> workaround, but I've also opened a request with Netflix. >>> >> > >>>> >>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>> >> > ganzer at spawar.navy.mil> >>> >> > >>>> wrote: >>> >> > >>>> >>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>> yet. I >>> >> > >>>> connect >>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>> space is >>> >> > >> being >>> >> > >>>>> blocked. >>> >> > >>>>> >>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 >>> from >>> >> > >> Time >>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>> >> service >>> >> > >> for >>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>> bug. And >>> >> > >> they >>> >> > >>>> are >>> >> > >>>>> taking their sweet time pushing out the fixed firmware update >>> that >>> >> > >>>> Comcast >>> >> > >>>>> and Cox seemed to be able to push to their customers last >>> fall. >>> >> > >>>>> >>> >> > >>>>> -Mark Ganzer >>> >> > >>>>> >>> >> > >>>>> >>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>> >> > >>>>>> >>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>> ISPs? >>> >> > >>>>>> >>> >> > >>>>>> If I remember correctly (I can't find the source at the >>> moment), >>> >> > >> HE.net >>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>> >> > >>>>>> >>> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >>> >> project >>> >> > >> at >>> >> > >>>>>> work at the moment that's a bit important to me. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>> >> > >>>> baldur.norddahl at gmail.com >>> >> > >>>>>> wrote: >>> >> > >>>>>> >>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>> >> > >>>> cryptographrix at gmail.com>: >>> >> > >>>>>>> >>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>> >> explicitly >>> >> > >>>>>>> telling >>> >> > >>>>>>> >>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>> before >>> >> they >>> >> > >>>>>>>> completely kill US IPv6 adoption. >>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just >>> need >>> >> > need >>> >> > >>>>>>> native >>> >> > >>>>>>> ipv6. >>> >> > >>>>>>> >>> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >>> >> other >>> >> > >>>>>>> protocol >>> >> > >>>>>>> before blocking. >>> >> > >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> From cryptographrix at gmail.com Sat Jun 4 02:21:25 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 02:21:25 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: "Hello Time Warner?....I happen to have 1.2Septillion IPv6 IPs I need to advertise...." On Fri, Jun 3, 2016 at 10:19 PM Cryptographrix wrote: > "A /48 is officially the smallest"...but apparently smaller gets > advertised all over, and I imagine esp for private ASNs...sooooo we buy a > /40 and 256 people here get /48s? > > That would also be hilarious if Netflix blocking HE resulted in 256-some > people each getting a /48. > > > > On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix > wrote: > >> Nope - You'd have the /56 and only people within your /56 (or /64 if you >> sliced it up nicely) would be able to do things with it routed by your ISP. >> >> Of course this means we'll have to get our ISPs to listen for our BGP >> advertisement... >> >> >> On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani >> wrote: >> >>> Wouldn't the /56 get blocked as soon as Netflix detects multiple >>> accounts logging in from the same IPv6 range? >>> >>> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix >> > wrote: >>> >>>> This is a good idea. We should do this. >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>>> raymond.beaudoin at icarustech.com> wrote: >>>> >>>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round >>>> of >>>> > drinks. >>>> > >>>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>>> cryptographrix at gmail.com> >>>> > wrote: >>>> > >>>> >> We should crowdsource a /40 and split it up into /64's for each of >>>> us. >>>> >> >>>> >> >>>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>>> >> wrote: >>>> >> >>>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>>> >> space, >>>> >> > my wife would be totally on board with this solution. >>>> >> > >>>> >> > Matthew Kaufman >>>> >> > >>>> >> > (Sent from my iPhone) >>>> >> > >>>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan >>>> wrote: >>>> >> > > >>>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>>> >> > > >>>> >> > > >>>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>>> >> > > *Arbor Networks* >>>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>> >> > > www.arbornetworks.com >>>> >> > > >>>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>>> >> > > raymond.beaudoin at icarustech.com> wrote: >>>> >> > > >>>> >> > >> As an alternative, there are multiple cloud service offerings >>>> that >>>> >> will >>>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>>> server in >>>> >> > their >>>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, >>>> to >>>> >> turn >>>> >> > >> up a *>>> >> > >> favorite virtual router instance> *and then route through it. >>>> The >>>> >> > Internet >>>> >> > >> is such an amazing place. >>>> >> > >> >>>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>>> >> > cryptographrix at gmail.com> >>>> >> > >> wrote: >>>> >> > >> >>>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as >>>> understanding to >>>> >> the >>>> >> > CS >>>> >> > >>> rep that it wasn't their fault. >>>> >> > >>> >>>> >> > >>> They thought I was weird as anything. >>>> >> > >>> >>>> >> > >>> If there are any Verizon FiOS network engineers on the thread, >>>> a >>>> >> fellow >>>> >> > >>> Verizon employee would thank you kindly for an off-thread email >>>> >> > regarding >>>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>>> drink-of-choice, >>>> >> you >>>> >> > >>> configure my account to listen for route advertisement). >>>> >> > >>> >>>> >> > >>> Strange that it has to come to this to get "legit" IPv6 >>>> service. >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>>> >> > >>> >>>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>>> >> evening it >>>> >> > >>>> started blocking. The recommended ACLs are a functional >>>> temporary >>>> >> > >>>> workaround, but I've also opened a request with Netflix. >>>> >> > >>>> >>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>>> >> > ganzer at spawar.navy.mil> >>>> >> > >>>> wrote: >>>> >> > >>>> >>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>>> yet. I >>>> >> > >>>> connect >>>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>>> space is >>>> >> > >> being >>>> >> > >>>>> blocked. >>>> >> > >>>>> >>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native >>>> IPv6 from >>>> >> > >> Time >>>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>>> >> service >>>> >> > >> for >>>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>>> bug. And >>>> >> > >> they >>>> >> > >>>> are >>>> >> > >>>>> taking their sweet time pushing out the fixed firmware >>>> update that >>>> >> > >>>> Comcast >>>> >> > >>>>> and Cox seemed to be able to push to their customers last >>>> fall. >>>> >> > >>>>> >>>> >> > >>>>> -Mark Ganzer >>>> >> > >>>>> >>>> >> > >>>>> >>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>> >> > >>>>>> >>>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>>> ISPs? >>>> >> > >>>>>> >>>> >> > >>>>>> If I remember correctly (I can't find the source at the >>>> moment), >>>> >> > >> HE.net >>>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>>> >> > >>>>>> >>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >>>> >> project >>>> >> > >> at >>>> >> > >>>>>> work at the moment that's a bit important to me. >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>> >> > >>>> baldur.norddahl at gmail.com >>>> >> > >>>>>> wrote: >>>> >> > >>>>>> >>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>> >> > >>>> cryptographrix at gmail.com>: >>>> >> > >>>>>>> >>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>>> >> explicitly >>>> >> > >>>>>>> telling >>>> >> > >>>>>>> >>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>>> before >>>> >> they >>>> >> > >>>>>>>> completely kill US IPv6 adoption. >>>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just >>>> need >>>> >> > need >>>> >> > >>>>>>> native >>>> >> > >>>>>>> ipv6. >>>> >> > >>>>>>> >>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >>>> >> other >>>> >> > >>>>>>> protocol >>>> >> > >>>>>>> before blocking. >>>> >> > >> >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>> >>> From cryptographrix at gmail.com Sat Jun 4 02:23:29 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 02:23:29 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: "Yeah, I'm actually only going to use 6 of them, between all of my phones, my Roku, and my laptop, but I'll advertise for all 1.2Septillion" On Fri, Jun 3, 2016 at 10:21 PM Cryptographrix wrote: > "Hello Time Warner?....I happen to have 1.2Septillion IPv6 IPs I need to > advertise...." > > > On Fri, Jun 3, 2016 at 10:19 PM Cryptographrix > wrote: > >> "A /48 is officially the smallest"...but apparently smaller gets >> advertised all over, and I imagine esp for private ASNs...sooooo we buy a >> /40 and 256 people here get /48s? >> >> That would also be hilarious if Netflix blocking HE resulted in 256-some >> people each getting a /48. >> >> >> >> On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix >> wrote: >> >>> Nope - You'd have the /56 and only people within your /56 (or /64 if you >>> sliced it up nicely) would be able to do things with it routed by your ISP. >>> >>> Of course this means we'll have to get our ISPs to listen for our BGP >>> advertisement... >>> >>> >>> On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani < >>> mnathani.lists at gmail.com> wrote: >>> >>>> Wouldn't the /56 get blocked as soon as Netflix detects multiple >>>> accounts logging in from the same IPv6 range? >>>> >>>> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix < >>>> cryptographrix at gmail.com> wrote: >>>> >>>>> This is a good idea. We should do this. >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>>>> raymond.beaudoin at icarustech.com> wrote: >>>>> >>>>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a >>>>> round of >>>>> > drinks. >>>>> > >>>>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>>>> cryptographrix at gmail.com> >>>>> > wrote: >>>>> > >>>>> >> We should crowdsource a /40 and split it up into /64's for each of >>>>> us. >>>>> >> >>>>> >> >>>>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>>>> >> wrote: >>>>> >> >>>>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>>>> >> space, >>>>> >> > my wife would be totally on board with this solution. >>>>> >> > >>>>> >> > Matthew Kaufman >>>>> >> > >>>>> >> > (Sent from my iPhone) >>>>> >> > >>>>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan >>>>> wrote: >>>>> >> > > >>>>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>>>> >> > > >>>>> >> > > >>>>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>>>> >> > > *Arbor Networks* >>>>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>>> >> > > www.arbornetworks.com >>>>> >> > > >>>>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>>>> >> > > raymond.beaudoin at icarustech.com> wrote: >>>>> >> > > >>>>> >> > >> As an alternative, there are multiple cloud service offerings >>>>> that >>>>> >> will >>>>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>>>> server in >>>>> >> > their >>>>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, >>>>> to >>>>> >> turn >>>>> >> > >> up a *>>>> >> > >> favorite virtual router instance> *and then route through it. >>>>> The >>>>> >> > Internet >>>>> >> > >> is such an amazing place. >>>>> >> > >> >>>>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>>>> >> > cryptographrix at gmail.com> >>>>> >> > >> wrote: >>>>> >> > >> >>>>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as >>>>> understanding to >>>>> >> the >>>>> >> > CS >>>>> >> > >>> rep that it wasn't their fault. >>>>> >> > >>> >>>>> >> > >>> They thought I was weird as anything. >>>>> >> > >>> >>>>> >> > >>> If there are any Verizon FiOS network engineers on the >>>>> thread, a >>>>> >> fellow >>>>> >> > >>> Verizon employee would thank you kindly for an off-thread >>>>> email >>>>> >> > regarding >>>>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>>>> drink-of-choice, >>>>> >> you >>>>> >> > >>> configure my account to listen for route advertisement). >>>>> >> > >>> >>>>> >> > >>> Strange that it has to come to this to get "legit" IPv6 >>>>> service. >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>>>> >> > >>> >>>>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>>>> >> evening it >>>>> >> > >>>> started blocking. The recommended ACLs are a functional >>>>> temporary >>>>> >> > >>>> workaround, but I've also opened a request with Netflix. >>>>> >> > >>>> >>>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>>>> >> > ganzer at spawar.navy.mil> >>>>> >> > >>>> wrote: >>>>> >> > >>>> >>>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>>>> yet. I >>>>> >> > >>>> connect >>>>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>>>> space is >>>>> >> > >> being >>>>> >> > >>>>> blocked. >>>>> >> > >>>>> >>>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native >>>>> IPv6 from >>>>> >> > >> Time >>>>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>>>> >> service >>>>> >> > >> for >>>>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>>>> bug. And >>>>> >> > >> they >>>>> >> > >>>> are >>>>> >> > >>>>> taking their sweet time pushing out the fixed firmware >>>>> update that >>>>> >> > >>>> Comcast >>>>> >> > >>>>> and Cox seemed to be able to push to their customers last >>>>> fall. >>>>> >> > >>>>> >>>>> >> > >>>>> -Mark Ganzer >>>>> >> > >>>>> >>>>> >> > >>>>> >>>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>> >> > >>>>>> >>>>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>>>> ISPs? >>>>> >> > >>>>>> >>>>> >> > >>>>>> If I remember correctly (I can't find the source at the >>>>> moment), >>>>> >> > >> HE.net >>>>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>>>> >> > >>>>>> >>>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an >>>>> IPv6 >>>>> >> project >>>>> >> > >> at >>>>> >> > >>>>>> work at the moment that's a bit important to me. >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>> >> > >>>> baldur.norddahl at gmail.com >>>>> >> > >>>>>> wrote: >>>>> >> > >>>>>> >>>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>> >> > >>>> cryptographrix at gmail.com>: >>>>> >> > >>>>>>> >>>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>>>> >> explicitly >>>>> >> > >>>>>>> telling >>>>> >> > >>>>>>> >>>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>>>> before >>>>> >> they >>>>> >> > >>>>>>>> completely kill US IPv6 adoption. >>>>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You >>>>> just need >>>>> >> > need >>>>> >> > >>>>>>> native >>>>> >> > >>>>>>> ipv6. >>>>> >> > >>>>>>> >>>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try >>>>> the >>>>> >> other >>>>> >> > >>>>>>> protocol >>>>> >> > >>>>>>> before blocking. >>>>> >> > >> >>>>> >> > >>>>> >> > >>>>> >> >>>>> > >>>>> > >>>>> >>>> >>>> From mysidia at gmail.com Sat Jun 4 02:39:16 2016 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 3 Jun 2016 21:39:16 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: On Fri, Jun 3, 2016 at 3:05 PM, Spencer Ryan wrote: > There is no way for Netflix to know the difference between you being in NY > and using the tunnel, and you living in Hong Kong and using the tunnel. No way, really? Come now. The latency difference between New York and Hong Kong are very different. If your minimum/bottomed-out RTT is less than 100ms away from a Netflix server, which can be measured using TCP protocol-based metrics, then you are not using a VPN. This could be used as a filter to reduce false positives. Also, if you are using a tunnel service, then it is Unlikely your only connectivity is IPv6, therefore, when they suspect an IPv6 VPN, they could use methods of figuring out your IPv4 address.... it could be an option simply do something along the lines of a background HTTP request along the lines of $.ajax({type: "GET", url: "http://ipv4onlyhostname.netflix.example.com/x.cgi"}, data: { timestamp:blah, action: 'get_proof_of_IPv4_address', blahblah_sessionid: blah } ) Then analyze the IPv4 connection before returning a proof of IP address as a signed token. Within the main page or system, allow the connection. This method proves your device is not merely circumventing region controls through a simple VPN. You at least have access to a computer in the allowed region a few seconds before initiating the connection. Or you know.... just redirect the IPV6 tunnel-provider connections at Netflix' end to an IPv4-only hostname period, so V6 is not used for these users. Furthermore, they could make a USB dongle with a GPS receiver on it that will answer a location-based challenge request, that you're expected to hook up to your computer feed from an outside antenna. I don't let them off the hook, too easily. > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com -- -JH From mnathani.lists at gmail.com Sat Jun 4 02:58:13 2016 From: mnathani.lists at gmail.com (Mansoor Nathani) Date: Fri, 3 Jun 2016 22:58:13 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: How is this better than getting native IPv6 from a provider? If they are willing to run a BGP session with you (that too with a private ASN), surely they can offer native IPv6 as well. On Fri, Jun 3, 2016 at 10:19 PM, Cryptographrix wrote: > "A /48 is officially the smallest"...but apparently smaller gets > advertised all over, and I imagine esp for private ASNs...sooooo we buy a > /40 and 256 people here get /48s? > > That would also be hilarious if Netflix blocking HE resulted in 256-some > people each getting a /48. > > > > On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix > wrote: > >> Nope - You'd have the /56 and only people within your /56 (or /64 if you >> sliced it up nicely) would be able to do things with it routed by your ISP. >> >> Of course this means we'll have to get our ISPs to listen for our BGP >> advertisement... >> >> >> On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani >> wrote: >> >>> Wouldn't the /56 get blocked as soon as Netflix detects multiple >>> accounts logging in from the same IPv6 range? >>> >>> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix >> > wrote: >>> >>>> This is a good idea. We should do this. >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>>> raymond.beaudoin at icarustech.com> wrote: >>>> >>>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a round >>>> of >>>> > drinks. >>>> > >>>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>>> cryptographrix at gmail.com> >>>> > wrote: >>>> > >>>> >> We should crowdsource a /40 and split it up into /64's for each of >>>> us. >>>> >> >>>> >> >>>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>>> >> wrote: >>>> >> >>>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>>> >> space, >>>> >> > my wife would be totally on board with this solution. >>>> >> > >>>> >> > Matthew Kaufman >>>> >> > >>>> >> > (Sent from my iPhone) >>>> >> > >>>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan >>>> wrote: >>>> >> > > >>>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>>> >> > > >>>> >> > > >>>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>>> >> > > *Arbor Networks* >>>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>> >> > > www.arbornetworks.com >>>> >> > > >>>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>>> >> > > raymond.beaudoin at icarustech.com> wrote: >>>> >> > > >>>> >> > >> As an alternative, there are multiple cloud service offerings >>>> that >>>> >> will >>>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>>> server in >>>> >> > their >>>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, >>>> to >>>> >> turn >>>> >> > >> up a *>>> >> > >> favorite virtual router instance> *and then route through it. >>>> The >>>> >> > Internet >>>> >> > >> is such an amazing place. >>>> >> > >> >>>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>>> >> > cryptographrix at gmail.com> >>>> >> > >> wrote: >>>> >> > >> >>>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as >>>> understanding to >>>> >> the >>>> >> > CS >>>> >> > >>> rep that it wasn't their fault. >>>> >> > >>> >>>> >> > >>> They thought I was weird as anything. >>>> >> > >>> >>>> >> > >>> If there are any Verizon FiOS network engineers on the thread, >>>> a >>>> >> fellow >>>> >> > >>> Verizon employee would thank you kindly for an off-thread email >>>> >> > regarding >>>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>>> drink-of-choice, >>>> >> you >>>> >> > >>> configure my account to listen for route advertisement). >>>> >> > >>> >>>> >> > >>> Strange that it has to come to this to get "legit" IPv6 >>>> service. >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>>> >> > >>> >>>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>>> >> evening it >>>> >> > >>>> started blocking. The recommended ACLs are a functional >>>> temporary >>>> >> > >>>> workaround, but I've also opened a request with Netflix. >>>> >> > >>>> >>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>>> >> > ganzer at spawar.navy.mil> >>>> >> > >>>> wrote: >>>> >> > >>>> >>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>>> yet. I >>>> >> > >>>> connect >>>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>>> space is >>>> >> > >> being >>>> >> > >>>>> blocked. >>>> >> > >>>>> >>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native >>>> IPv6 from >>>> >> > >> Time >>>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>>> >> service >>>> >> > >> for >>>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>>> bug. And >>>> >> > >> they >>>> >> > >>>> are >>>> >> > >>>>> taking their sweet time pushing out the fixed firmware >>>> update that >>>> >> > >>>> Comcast >>>> >> > >>>>> and Cox seemed to be able to push to their customers last >>>> fall. >>>> >> > >>>>> >>>> >> > >>>>> -Mark Ganzer >>>> >> > >>>>> >>>> >> > >>>>> >>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>> >> > >>>>>> >>>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>>> ISPs? >>>> >> > >>>>>> >>>> >> > >>>>>> If I remember correctly (I can't find the source at the >>>> moment), >>>> >> > >> HE.net >>>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>>> >> > >>>>>> >>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an IPv6 >>>> >> project >>>> >> > >> at >>>> >> > >>>>>> work at the moment that's a bit important to me. >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>> >> > >>>> baldur.norddahl at gmail.com >>>> >> > >>>>>> wrote: >>>> >> > >>>>>> >>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>> >> > >>>> cryptographrix at gmail.com>: >>>> >> > >>>>>>> >>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>>> >> explicitly >>>> >> > >>>>>>> telling >>>> >> > >>>>>>> >>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>>> before >>>> >> they >>>> >> > >>>>>>>> completely kill US IPv6 adoption. >>>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just >>>> need >>>> >> > need >>>> >> > >>>>>>> native >>>> >> > >>>>>>> ipv6. >>>> >> > >>>>>>> >>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try the >>>> >> other >>>> >> > >>>>>>> protocol >>>> >> > >>>>>>> before blocking. >>>> >> > >> >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>> >>> From cryptographrix at gmail.com Sat Jun 4 03:11:20 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 03:11:20 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Surely they could - for some reason they haven't. It's not better - it's desperate. But it's more than nothing. Of course, there's always the possibility that I/we will be left with 300 septillion IPv6 IPs and nobody to route them. On Fri, Jun 3, 2016 at 10:58 PM Mansoor Nathani wrote: > How is this better than getting native IPv6 from a provider? If they are > willing to run a BGP session with you (that too with a private ASN), surely > they can offer native IPv6 as well. > > On Fri, Jun 3, 2016 at 10:19 PM, Cryptographrix > wrote: > >> "A /48 is officially the smallest"...but apparently smaller gets >> advertised all over, and I imagine esp for private ASNs...sooooo we buy a >> /40 and 256 people here get /48s? >> >> That would also be hilarious if Netflix blocking HE resulted in 256-some >> people each getting a /48. >> >> >> >> On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix >> wrote: >> >>> Nope - You'd have the /56 and only people within your /56 (or /64 if you >>> sliced it up nicely) would be able to do things with it routed by your ISP. >>> >>> Of course this means we'll have to get our ISPs to listen for our BGP >>> advertisement... >>> >>> >>> On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani < >>> mnathani.lists at gmail.com> wrote: >>> >>>> Wouldn't the /56 get blocked as soon as Netflix detects multiple >>>> accounts logging in from the same IPv6 range? >>>> >>>> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix < >>>> cryptographrix at gmail.com> wrote: >>>> >>>>> This is a good idea. We should do this. >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>>>> raymond.beaudoin at icarustech.com> wrote: >>>>> >>>>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a >>>>> round of >>>>> > drinks. >>>>> > >>>>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>>>> cryptographrix at gmail.com> >>>>> > wrote: >>>>> > >>>>> >> We should crowdsource a /40 and split it up into /64's for each of >>>>> us. >>>>> >> >>>>> >> >>>>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>>>> >> wrote: >>>>> >> >>>>> >> > If early adopter PI IPv6 was the same price as early adopter PI v4 >>>>> >> space, >>>>> >> > my wife would be totally on board with this solution. >>>>> >> > >>>>> >> > Matthew Kaufman >>>>> >> > >>>>> >> > (Sent from my iPhone) >>>>> >> > >>>>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan >>>>> wrote: >>>>> >> > > >>>>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>>>> >> > > >>>>> >> > > >>>>> >> > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>>>> >> > > *Arbor Networks* >>>>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>>> >> > > www.arbornetworks.com >>>>> >> > > >>>>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>>>> >> > > raymond.beaudoin at icarustech.com> wrote: >>>>> >> > > >>>>> >> > >> As an alternative, there are multiple cloud service offerings >>>>> that >>>>> >> will >>>>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>>>> server in >>>>> >> > their >>>>> >> > >> data centers. It seems pretty tongue-in-cheek, and satisfying, >>>>> to >>>>> >> turn >>>>> >> > >> up a *>>>> >> > >> favorite virtual router instance> *and then route through it. >>>>> The >>>>> >> > Internet >>>>> >> > >> is such an amazing place. >>>>> >> > >> >>>>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>>>> >> > cryptographrix at gmail.com> >>>>> >> > >> wrote: >>>>> >> > >> >>>>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as >>>>> understanding to >>>>> >> the >>>>> >> > CS >>>>> >> > >>> rep that it wasn't their fault. >>>>> >> > >>> >>>>> >> > >>> They thought I was weird as anything. >>>>> >> > >>> >>>>> >> > >>> If there are any Verizon FiOS network engineers on the >>>>> thread, a >>>>> >> fellow >>>>> >> > >>> Verizon employee would thank you kindly for an off-thread >>>>> email >>>>> >> > regarding >>>>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>>>> drink-of-choice, >>>>> >> you >>>>> >> > >>> configure my account to listen for route advertisement). >>>>> >> > >>> >>>>> >> > >>> Strange that it has to come to this to get "legit" IPv6 >>>>> service. >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>>>> >> > >>> >>>>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>>>> >> evening it >>>>> >> > >>>> started blocking. The recommended ACLs are a functional >>>>> temporary >>>>> >> > >>>> workaround, but I've also opened a request with Netflix. >>>>> >> > >>>> >>>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>>>> >> > ganzer at spawar.navy.mil> >>>>> >> > >>>> wrote: >>>>> >> > >>>> >>>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net tunnel >>>>> yet. I >>>>> >> > >>>> connect >>>>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>>>> space is >>>>> >> > >> being >>>>> >> > >>>>> blocked. >>>>> >> > >>>>> >>>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native >>>>> IPv6 from >>>>> >> > >> Time >>>>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>>>> >> service >>>>> >> > >> for >>>>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>>>> bug. And >>>>> >> > >> they >>>>> >> > >>>> are >>>>> >> > >>>>> taking their sweet time pushing out the fixed firmware >>>>> update that >>>>> >> > >>>> Comcast >>>>> >> > >>>>> and Cox seemed to be able to push to their customers last >>>>> fall. >>>>> >> > >>>>> >>>>> >> > >>>>> -Mark Ganzer >>>>> >> > >>>>> >>>>> >> > >>>>> >>>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>> >> > >>>>>> >>>>> >> > >>>>>> Depends - how many US users have native IPv6 through their >>>>> ISPs? >>>>> >> > >>>>>> >>>>> >> > >>>>>> If I remember correctly (I can't find the source at the >>>>> moment), >>>>> >> > >> HE.net >>>>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>>>> >> > >>>>>> >>>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an >>>>> IPv6 >>>>> >> project >>>>> >> > >> at >>>>> >> > >>>>>> work at the moment that's a bit important to me. >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>> >> > >>>> baldur.norddahl at gmail.com >>>>> >> > >>>>>> wrote: >>>>> >> > >>>>>> >>>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>> >> > >>>> cryptographrix at gmail.com>: >>>>> >> > >>>>>>> >>>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>>>> >> explicitly >>>>> >> > >>>>>>> telling >>>>> >> > >>>>>>> >>>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>>>> before >>>>> >> they >>>>> >> > >>>>>>>> completely kill US IPv6 adoption. >>>>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You >>>>> just need >>>>> >> > need >>>>> >> > >>>>>>> native >>>>> >> > >>>>>>> ipv6. >>>>> >> > >>>>>>> >>>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try >>>>> the >>>>> >> other >>>>> >> > >>>>>>> protocol >>>>> >> > >>>>>>> before blocking. >>>>> >> > >> >>>>> >> > >>>>> >> > >>>>> >> >>>>> > >>>>> > >>>>> >>>> >>>> > From cryptographrix at gmail.com Sat Jun 4 03:12:19 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Sat, 04 Jun 2016 03:12:19 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: And yeah, most every US ISP *can* route IPv6, but they just haven't for absolutely no reason. On Fri, Jun 3, 2016 at 11:11 PM Cryptographrix wrote: > Surely they could - for some reason they haven't. > > It's not better - it's desperate. > > But it's more than nothing. > > Of course, there's always the possibility that I/we will be left with 300 > septillion IPv6 IPs and nobody to route them. > > > On Fri, Jun 3, 2016 at 10:58 PM Mansoor Nathani > wrote: > >> How is this better than getting native IPv6 from a provider? If they are >> willing to run a BGP session with you (that too with a private ASN), surely >> they can offer native IPv6 as well. >> >> On Fri, Jun 3, 2016 at 10:19 PM, Cryptographrix > > wrote: >> >>> "A /48 is officially the smallest"...but apparently smaller gets >>> advertised all over, and I imagine esp for private ASNs...sooooo we buy a >>> /40 and 256 people here get /48s? >>> >>> That would also be hilarious if Netflix blocking HE resulted in 256-some >>> people each getting a /48. >>> >>> >>> >>> On Fri, Jun 3, 2016 at 10:11 PM Cryptographrix >>> wrote: >>> >>>> Nope - You'd have the /56 and only people within your /56 (or /64 if >>>> you sliced it up nicely) would be able to do things with it routed by your >>>> ISP. >>>> >>>> Of course this means we'll have to get our ISPs to listen for our BGP >>>> advertisement... >>>> >>>> >>>> On Fri, Jun 3, 2016 at 10:09 PM Mansoor Nathani < >>>> mnathani.lists at gmail.com> wrote: >>>> >>>>> Wouldn't the /56 get blocked as soon as Netflix detects multiple >>>>> accounts logging in from the same IPv6 range? >>>>> >>>>> On Fri, Jun 3, 2016 at 9:49 PM, Cryptographrix < >>>>> cryptographrix at gmail.com> wrote: >>>>> >>>>>> This is a good idea. We should do this. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 9:48 PM Raymond Beaudoin < >>>>>> raymond.beaudoin at icarustech.com> wrote: >>>>>> >>>>>> > Make it a /56 each and you've got a deal. Hell, I'll throw in a >>>>>> round of >>>>>> > drinks. >>>>>> > >>>>>> > On Fri, Jun 3, 2016 at 8:40 PM, Cryptographrix < >>>>>> cryptographrix at gmail.com> >>>>>> > wrote: >>>>>> > >>>>>> >> We should crowdsource a /40 and split it up into /64's for each of >>>>>> us. >>>>>> >> >>>>>> >> >>>>>> >> On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman >>>>> > >>>>>> >> wrote: >>>>>> >> >>>>>> >> > If early adopter PI IPv6 was the same price as early adopter PI >>>>>> v4 >>>>>> >> space, >>>>>> >> > my wife would be totally on board with this solution. >>>>>> >> > >>>>>> >> > Matthew Kaufman >>>>>> >> > >>>>>> >> > (Sent from my iPhone) >>>>>> >> > >>>>>> >> > > On Jun 3, 2016, at 6:27 PM, Spencer Ryan >>>>>> wrote: >>>>>> >> > > >>>>>> >> > > Well if you have PI space just use HE's BGP tunnel offerings. >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > *Spencer Ryan* | Senior Systems Administrator | >>>>>> sryan at arbor.net >>>>>> >> > > *Arbor Networks* >>>>>> >> > > +1.734.794.5033 (d) | +1.734.846.2053 (m) >>>>>> >> > > www.arbornetworks.com >>>>>> >> > > >>>>>> >> > > On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>>>>> >> > > raymond.beaudoin at icarustech.com> wrote: >>>>>> >> > > >>>>>> >> > >> As an alternative, there are multiple cloud service offerings >>>>>> that >>>>>> >> will >>>>>> >> > >> advertise your IPv6 allocations on your behalf direct to a >>>>>> server in >>>>>> >> > their >>>>>> >> > >> data centers. It seems pretty tongue-in-cheek, and >>>>>> satisfying, to >>>>>> >> turn >>>>>> >> > >> up a *>>>>> >> > >> favorite virtual router instance> *and then route through it. >>>>>> The >>>>>> >> > Internet >>>>>> >> > >> is such an amazing place. >>>>>> >> > >> >>>>>> >> > >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >>>>>> >> > cryptographrix at gmail.com> >>>>>> >> > >> wrote: >>>>>> >> > >> >>>>>> >> > >>> Yeah I RAWRed to them pretty hard whilst being as >>>>>> understanding to >>>>>> >> the >>>>>> >> > CS >>>>>> >> > >>> rep that it wasn't their fault. >>>>>> >> > >>> >>>>>> >> > >>> They thought I was weird as anything. >>>>>> >> > >>> >>>>>> >> > >>> If there are any Verizon FiOS network engineers on the >>>>>> thread, a >>>>>> >> fellow >>>>>> >> > >>> Verizon employee would thank you kindly for an off-thread >>>>>> email >>>>>> >> > regarding >>>>>> >> > >>> BGP advertisement (I'll buy the IPv6 block and the >>>>>> drink-of-choice, >>>>>> >> you >>>>>> >> > >>> configure my account to listen for route advertisement). >>>>>> >> > >>> >>>>>> >> > >>> Strange that it has to come to this to get "legit" IPv6 >>>>>> service. >>>>>> >> > >>> >>>>>> >> > >>> >>>>>> >> > >>> >>>>>> >> > >>> >>>>>> >> > >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>>>> >> > >>> raymond.beaudoin at icarustech.com> wrote: >>>>>> >> > >>> >>>>>> >> > >>>> I wasn't originally affected on my he.net tunnel, but this >>>>>> >> evening it >>>>>> >> > >>>> started blocking. The recommended ACLs are a functional >>>>>> temporary >>>>>> >> > >>>> workaround, but I've also opened a request with Netflix. >>>>>> >> > >>>> >>>>>> >> > >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >>>>>> >> > ganzer at spawar.navy.mil> >>>>>> >> > >>>> wrote: >>>>>> >> > >>>> >>>>>> >> > >>>>> So far I am not seeing a Netflix block on my he.net >>>>>> tunnel yet. I >>>>>> >> > >>>> connect >>>>>> >> > >>>>> to the Los Angeles node, so maybe not all of HE's address >>>>>> space is >>>>>> >> > >> being >>>>>> >> > >>>>> blocked. >>>>>> >> > >>>>> >>>>>> >> > >>>>> Not going to be disabling IPv6 here either. + HAD native >>>>>> IPv6 from >>>>>> >> > >> Time >>>>>> >> > >>>>> Warner, but they decided to in their wisdom to disable IPv6 >>>>>> >> service >>>>>> >> > >> for >>>>>> >> > >>>>> anyone that has an Arris SB6183 due to an Arris firmware >>>>>> bug. And >>>>>> >> > >> they >>>>>> >> > >>>> are >>>>>> >> > >>>>> taking their sweet time pushing out the fixed firmware >>>>>> update that >>>>>> >> > >>>> Comcast >>>>>> >> > >>>>> and Cox seemed to be able to push to their customers last >>>>>> fall. >>>>>> >> > >>>>> >>>>>> >> > >>>>> -Mark Ganzer >>>>>> >> > >>>>> >>>>>> >> > >>>>> >>>>>> >> > >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> Depends - how many US users have native IPv6 through >>>>>> their ISPs? >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> If I remember correctly (I can't find the source at the >>>>>> moment), >>>>>> >> > >> HE.net >>>>>> >> > >>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> And yeah, not doing that - actually in the middle of an >>>>>> IPv6 >>>>>> >> project >>>>>> >> > >> at >>>>>> >> > >>>>>> work at the moment that's a bit important to me. >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>>> >> > >>>> baldur.norddahl at gmail.com >>>>>> >> > >>>>>> wrote: >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>>> >> > >>>> cryptographrix at gmail.com>: >>>>>> >> > >>>>>>> >>>>>> >> > >>>>>>>> The information I'm getting from Netflix support now is >>>>>> >> explicitly >>>>>> >> > >>>>>>> telling >>>>>> >> > >>>>>>> >>>>>> >> > >>>>>>>> me to turn off IPv6 - someone might want to stop them >>>>>> before >>>>>> >> they >>>>>> >> > >>>>>>>> completely kill US IPv6 adoption. >>>>>> >> > >>>>>>> Not allowing he.net tunnels is not killing ipv6. You >>>>>> just need >>>>>> >> > need >>>>>> >> > >>>>>>> native >>>>>> >> > >>>>>>> ipv6. >>>>>> >> > >>>>>>> >>>>>> >> > >>>>>>> On the other hand it would be nice if Netflix would try >>>>>> the >>>>>> >> other >>>>>> >> > >>>>>>> protocol >>>>>> >> > >>>>>>> before blocking. >>>>>> >> > >> >>>>>> >> > >>>>>> >> > >>>>>> >> >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >> From Valdis.Kletnieks at vt.edu Sat Jun 4 03:42:12 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Jun 2016 23:42:12 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <110625.1465011732@turing-police.cc.vt.edu> On Fri, 03 Jun 2016 17:21:16 -0700, Blair Trosper said: > ...IF (and that's a big IF in the Bay Area at least) you can get the newest > modems. Easier said than done. http://www.amazon.com/ARRIS-SURFboard-SB6141-DOCSIS-Cable/dp/B00AJHDZSI/ $68.75 and Done. And the damned thing even pays for itself by not paying a rental every month. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From swmike at swm.pp.se Sat Jun 4 06:48:18 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 4 Jun 2016 08:48:18 +0200 (CEST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: On Fri, 3 Jun 2016, Cryptographrix wrote: > I have a VPN connection at my house. There's no way for them to know the > difference between me using my home network connection from Hong Kong or > my home network connection from my house. In my case I have a he.net tunnel from their tunnel servers in Stockholm. This is properly GEOIP:ed to Sweden (I had to get that done by another content provider that seems to use the same GEOIP as Netflix, because after this was done a year ago or something, Netflix stopped thinking I was in the US when I accessed it over IPv6.) My regular IPv4 address also GEOIPs to same place. So the fact I am using IPv6 through a tunnel provider seems to be what triggers Netflix to block me. The fact that my IPv4 connectivity is NOT through a tunnel, is something they could check. I really wish their tunnel connectivity checker was a bit more sofisticated so it would correlate the following: My billing address is in Sweden. My IPv4 GEOIP says I am in Sweden. My IPv6 GEOIP says I am in Sweden. Ok, so fine, I am not trying to circumvent anything so just let me watch the bloody content ok to show to people in Sweden. BLOODY HELL! -- Mikael Abrahamsson email: swmike at swm.pp.se From brandon at rd.bbc.co.uk Sat Jun 4 10:48:59 2016 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 4 Jun 2016 11:48:59 +0100 (BST) Subject: Netflix VPN detection - actual engineer needed Message-ID: <201606041048.LAA18167@sunf10.rd.bbc.co.uk> > On Jun 3, 2016, at 17:35 , Owen DeLong wrote: > Let?'s face it folks, if we want to encourage Netflix to tell the > content providers to give up the silly geo-shit, then we have to > stop patronizing channels that do silly geo-shit. Correct but it needs a lot to do that. We do the geo thing. I didn't want us to and we didn't for a few years but once the geo people had convinced rights owners it was a viable thing they forced people buying their content to use it. I tried to stop it here and failed but it's never over, people are starting to realise it's silly to annoy people who want your services, you just need to find a way to allow them To be fair to Netflix the tunnel blocking will likely have been driven by their content suppliers asserting their contractual rights to not allow access from certain places. Their content suppliers will have seen people boasting how they use tunnels to get round them and tunnel suppliers advertising their services for doing so. Blame them for the blocking as while it was a personal thing they wouldn't have been bothered much. As usual a few people see an opportunity to make money off something and in the process break it for everyone btw the list of tunnel providers was likely supplied by the same geo ip people, some sell that as an extra. brandon From owen at delong.com Sat Jun 4 18:33:33 2016 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2016 11:33:33 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3! db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: <39D646BE-31A5-489B-B391-4A994BCCBF0C@delong.com> > On Jun 3, 2016, at 18:31 , Cryptographrix wrote: > > Honestly I was trying to make that sound like a "missed connections" ad > there for a moment, but seriously I'd buy a /40 right now if possible to > have non-tunneled IPv6 if I could. You can easily get a /48 from ARIN. Not sure why you think you?d need a /40 for home. I?m a pretty big fan of sparse allocation and tend to be considered an outlier for extreme home networking and my /48 still has many subnets available. > It's so weird being on US internet - your content distributor makes you > feel like a criminal because their content provider has standing orders to > deny you from viewing the content they provide and the only other thing you > can do about it is turn off the thing that gives you access to the way you > make the money to pay for their stuff. Yep? RIAA and MPAA proving once again that they just don?t get it. Owen > > > > On Fri, Jun 3, 2016 at 9:25 PM Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > >> As an alternative, there are multiple cloud service offerings that will >> advertise your IPv6 allocations on your behalf direct to a server in their >> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn up a *> favorite virtual router instance> *and then route through it. The >> Internet is such an amazing place. >> >> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix >> wrote: >> >>> Yeah I RAWRed to them pretty hard whilst being as understanding to the CS >>> rep that it wasn't their fault. >>> >>> They thought I was weird as anything. >>> >>> If there are any Verizon FiOS network engineers on the thread, a fellow >>> Verizon employee would thank you kindly for an off-thread email regarding >>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >>> configure my account to listen for route advertisement). >>> >>> Strange that it has to come to this to get "legit" IPv6 service. >>> >>> >>> >>> >>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>> raymond.beaudoin at icarustech.com> wrote: >>> >>>> I wasn't originally affected on my he.net tunnel, but this evening it >>>> started blocking. The recommended ACLs are a functional temporary >>>> workaround, but I've also opened a request with Netflix. >>>> >>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >>>> wrote: >>>> >>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >>>> connect >>>>> to the Los Angeles node, so maybe not all of HE's address space is >>>> being >>>>> blocked. >>>>> >>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from Time >>>>> Warner, but they decided to in their wisdom to disable IPv6 service for >>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >>>> they are >>>>> taking their sweet time pushing out the fixed firmware update that >>>> Comcast >>>>> and Cox seemed to be able to push to their customers last fall. >>>>> >>>>> -Mark Ganzer >>>>> >>>>> >>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>> >>>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>>> >>>>>> If I remember correctly (I can't find the source at the moment), >>>> HE.net >>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>> >>>>>> And yeah, not doing that - actually in the middle of an IPv6 project >>>> at >>>>>> work at the moment that's a bit important to me. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>> baldur.norddahl at gmail.com >>>>>>> >>>>>> wrote: >>>>>> >>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>> cryptographrix at gmail.com>: >>>>>>> >>>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>>>> >>>>>>> telling >>>>>>> >>>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>>> completely kill US IPv6 adoption. >>>>>>>> >>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need >>>>>>> native >>>>>>> ipv6. >>>>>>> >>>>>>> On the other hand it would be nice if Netflix would try the other >>>>>>> protocol >>>>>>> before blocking. >>>>>>> >>>>>>> >>>>> >>>> >>> >> From owen at delong.com Sat Jun 4 18:37:14 2016 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2016 11:37:14 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3! db-0524-79dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: > On Jun 3, 2016, at 18:32 , Raymond Beaudoin wrote: > > Fair point, Spencer! Only Netflix engineers could tell us how they're > determining networks to be blocked, but I'm paranoid they're dynamically > updating based AS PATH. I figured HE's ASN may have made the naughty list. > Admittedly, that would be pretty drastic. Time to do some testing. :> I tend to doubt it: route-views6.routeviews.org> sh bgp 2620:0:930::/48 BGP routing table entry for 2620:0:930::/48 Paths: (31 available, best #26, table Default-IP-Routing-Table) Not advertised to any peer 3257 8121 1734, (aggregated by 1734 192.124.40.251) 2001:668:0:4::2 from 2001:668:0:4::2 (213.200.87.91) Origin IGP, metric 770, localpref 100, valid, external Community: 3257:4560 3257:5010 Last update: Fri Jun 3 09:07:40 2016 47872 6939 1734, (aggregated by 1734 192.124.40.251) 2a01:73e0::1 from 2a01:73e0::1 (185.44.116.227) (fe80::223:9c03:9b50:ffc0) Origin IGP, localpref 100, valid, external Community: 47872:1200 Last update: Fri Jun 3 05:48:08 2016 3741 6939 1734, (aggregated by 1734 192.124.40.251) 2c0f:fc00::2 from 2c0f:fc00::2 (168.209.255.56) Origin IGP, localpref 100, valid, external Last update: Thu Jun 2 23:12:06 2016 31019 6939 1734, (aggregated by 1734 192.124.40.251) 2001:67c:22dc:def1::1 from 2001:67c:22dc:def1::1 (91.228.151.1) Origin incomplete, localpref 100, valid, external Last update: Sat Jun 4 18:31:19 2016 3277 3267 6939 1734, (aggregated by 1734 192.124.40.251) 2001:b08:2:280::4:100 from 2001:b08:2:280::4:100 (194.85.4.4) Origin IGP, localpref 100, valid, external Community: 3277:3267 Last update: Wed Jun 1 12:54:09 2016 7660 4635 6939 1734, (aggregated by 1734 192.124.40.251) 2001:200:901::5 from 2001:200:901::5 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 0:12989 0:13335 0:15169 0:20940 0:22822 4635:800 7660:4 7660:6 Last update: Tue May 31 03:14:20 2016 7018 6939 1734, (aggregated by 1734 192.124.40.251) 2001:1890:111d:1::63 from 2001:1890:111d:1::63 (12.0.1.63) (fe80::5254:ff:fe61:b8e6) Origin IGP, localpref 100, valid, external Community: 7018:5000 7018:37232 Last update: Tue May 31 02:36:49 2016 209 6939 1734, (aggregated by 1734 192.124.40.251) 2001:428::205:171:203:138 from 2001:428::205:171:203:138 (205.171.203.138) Origin IGP, metric 8000051, localpref 100, valid, external Community: 209:888 Last update: Tue May 31 02:36:49 2016 20912 6939 1734, (aggregated by 1734 192.124.40.251) 2001:40d0::126 from 2001:40d0::126 (212.66.96.126) Origin IGP, localpref 100, valid, external Community: 20912:65016 Last update: Tue May 31 02:37:02 2016 13030 6939 1734, (aggregated by 1734 192.124.40.251) 2001:1620:1::203 from 2001:1620:1::203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:61 13030:1604 13030:51107 Last update: Tue May 31 02:36:50 2016 30071 8121 1734, (aggregated by 1734 192.124.40.251) 2001:4830::e from 2001:4830::e (66.55.128.18) Origin IGP, metric 42, localpref 100, valid, external Community: 30071:57062 Last update: Tue May 31 02:39:32 2016 57463 6939 1734, (aggregated by 1734 192.124.40.251) 2a00:1728::1f:4 from 2a00:1728::1f:4 (192.168.7.118) Origin IGP, localpref 100, valid, external Community: 64700:6939 Last update: Tue May 31 02:37:03 2016 My NF is still working over IPv6. Owen > > On Fri, Jun 3, 2016 at 8:27 PM, Spencer Ryan wrote: > >> Well if you have PI space just use HE's BGP tunnel offerings. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >> raymond.beaudoin at icarustech.com> wrote: >> >>> As an alternative, there are multiple cloud service offerings that will >>> advertise your IPv6 allocations on your behalf direct to a server in their >>> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn >>> up a *>> favorite virtual router instance> *and then route through it. The Internet >>> >>> is such an amazing place. >>> >>> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix >>> wrote: >>> >>>> Yeah I RAWRed to them pretty hard whilst being as understanding to the >>> CS >>>> rep that it wasn't their fault. >>>> >>>> They thought I was weird as anything. >>>> >>>> If there are any Verizon FiOS network engineers on the thread, a fellow >>>> Verizon employee would thank you kindly for an off-thread email >>> regarding >>>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >>>> configure my account to listen for route advertisement). >>>> >>>> Strange that it has to come to this to get "legit" IPv6 service. >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>> raymond.beaudoin at icarustech.com> wrote: >>>> >>>>> I wasn't originally affected on my he.net tunnel, but this evening it >>>>> started blocking. The recommended ACLs are a functional temporary >>>>> workaround, but I've also opened a request with Netflix. >>>>> >>>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >>> >>>>> wrote: >>>>> >>>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >>>>> connect >>>>>> to the Los Angeles node, so maybe not all of HE's address space is >>> being >>>>>> blocked. >>>>>> >>>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from >>> Time >>>>>> Warner, but they decided to in their wisdom to disable IPv6 service >>> for >>>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >>> they >>>>> are >>>>>> taking their sweet time pushing out the fixed firmware update that >>>>> Comcast >>>>>> and Cox seemed to be able to push to their customers last fall. >>>>>> >>>>>> -Mark Ganzer >>>>>> >>>>>> >>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>>> >>>>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>>>> >>>>>>> If I remember correctly (I can't find the source at the moment), >>> HE.net >>>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>>> >>>>>>> And yeah, not doing that - actually in the middle of an IPv6 >>> project at >>>>>>> work at the moment that's a bit important to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>> baldur.norddahl at gmail.com >>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>> cryptographrix at gmail.com>: >>>>>>>> >>>>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>>>>> >>>>>>>> telling >>>>>>>> >>>>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>>>> completely kill US IPv6 adoption. >>>>>>>>> >>>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need >>> need >>>>>>>> native >>>>>>>> ipv6. >>>>>>>> >>>>>>>> On the other hand it would be nice if Netflix would try the other >>>>>>>> protocol >>>>>>>> before blocking. >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> From owen at delong.com Sat Jun 4 18:38:10 2016 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2016 11:38:10 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3! db-0524-7 9dd-6873-30d8b864879a@spawar.navy.mil> Message-ID: <53D9A273-7909-436B-B72F-7033846C3BD6@delong.com> If you?re wife is really worried about $100/year, give up your first 2 weeks of Starbucks each year in trade. Owen > On Jun 3, 2016, at 18:33 , Matthew Kaufman wrote: > > If early adopter PI IPv6 was the same price as early adopter PI v4 space, my wife would be totally on board with this solution. > > Matthew Kaufman > > (Sent from my iPhone) > >> On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >> >> Well if you have PI space just use HE's BGP tunnel offerings. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >> raymond.beaudoin at icarustech.com> wrote: >> >>> As an alternative, there are multiple cloud service offerings that will >>> advertise your IPv6 allocations on your behalf direct to a server in their >>> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn >>> up a *>> favorite virtual router instance> *and then route through it. The Internet >>> is such an amazing place. >>> >>> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix >>> wrote: >>> >>>> Yeah I RAWRed to them pretty hard whilst being as understanding to the CS >>>> rep that it wasn't their fault. >>>> >>>> They thought I was weird as anything. >>>> >>>> If there are any Verizon FiOS network engineers on the thread, a fellow >>>> Verizon employee would thank you kindly for an off-thread email regarding >>>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >>>> configure my account to listen for route advertisement). >>>> >>>> Strange that it has to come to this to get "legit" IPv6 service. >>>> >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>> raymond.beaudoin at icarustech.com> wrote: >>>> >>>>> I wasn't originally affected on my he.net tunnel, but this evening it >>>>> started blocking. The recommended ACLs are a functional temporary >>>>> workaround, but I've also opened a request with Netflix. >>>>> >>>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer >>>>> wrote: >>>>> >>>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >>>>> connect >>>>>> to the Los Angeles node, so maybe not all of HE's address space is >>> being >>>>>> blocked. >>>>>> >>>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from >>> Time >>>>>> Warner, but they decided to in their wisdom to disable IPv6 service >>> for >>>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >>> they >>>>> are >>>>>> taking their sweet time pushing out the fixed firmware update that >>>>> Comcast >>>>>> and Cox seemed to be able to push to their customers last fall. >>>>>> >>>>>> -Mark Ganzer >>>>>> >>>>>> >>>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>>>> >>>>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>>>> >>>>>>> If I remember correctly (I can't find the source at the moment), >>> HE.net >>>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>>> >>>>>>> And yeah, not doing that - actually in the middle of an IPv6 project >>> at >>>>>>> work at the moment that's a bit important to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>> baldur.norddahl at gmail.com >>>>>>> wrote: >>>>>>> >>>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>> cryptographrix at gmail.com>: >>>>>>>> >>>>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>>>> telling >>>>>>>> >>>>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>>>> completely kill US IPv6 adoption. >>>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need >>>>>>>> native >>>>>>>> ipv6. >>>>>>>> >>>>>>>> On the other hand it would be nice if Netflix would try the other >>>>>>>> protocol >>>>>>>> before blocking. >>> > From owen at delong.com Sat Jun 4 18:43:29 2016 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2016 11:43:29 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Not necessarily a bad idea, but please give everyone at least a /48. Personally, I found that getting my own /48 was cheap enough that I didn?t worry about crowd sourcing. Today, they are even cheaper effective 1 July than when I got mine, so I?m not sure what Matthew is on about. 3x-Small (/40 or smaller) $250 initial, $250/year with Registration Services plan (includes voting membership) or $100/year without. Owen > On Jun 3, 2016, at 18:40 , Cryptographrix wrote: > > We should crowdsource a /40 and split it up into /64's for each of us. > > > On Fri, Jun 3, 2016 at 9:38 PM Matthew Kaufman wrote: > >> If early adopter PI IPv6 was the same price as early adopter PI v4 space, >> my wife would be totally on board with this solution. >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>> On Jun 3, 2016, at 6:27 PM, Spencer Ryan wrote: >>> >>> Well if you have PI space just use HE's BGP tunnel offerings. >>> >>> >>> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >>> *Arbor Networks* >>> +1.734.794.5033 (d) | +1.734.846.2053 (m) >>> www.arbornetworks.com >>> >>> On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin < >>> raymond.beaudoin at icarustech.com> wrote: >>> >>>> As an alternative, there are multiple cloud service offerings that will >>>> advertise your IPv6 allocations on your behalf direct to a server in >> their >>>> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn >>>> up a *>>> favorite virtual router instance> *and then route through it. The >> Internet >>>> is such an amazing place. >>>> >>>> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix < >> cryptographrix at gmail.com> >>>> wrote: >>>> >>>>> Yeah I RAWRed to them pretty hard whilst being as understanding to the >> CS >>>>> rep that it wasn't their fault. >>>>> >>>>> They thought I was weird as anything. >>>>> >>>>> If there are any Verizon FiOS network engineers on the thread, a fellow >>>>> Verizon employee would thank you kindly for an off-thread email >> regarding >>>>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you >>>>> configure my account to listen for route advertisement). >>>>> >>>>> Strange that it has to come to this to get "legit" IPv6 service. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin < >>>>> raymond.beaudoin at icarustech.com> wrote: >>>>> >>>>>> I wasn't originally affected on my he.net tunnel, but this evening it >>>>>> started blocking. The recommended ACLs are a functional temporary >>>>>> workaround, but I've also opened a request with Netflix. >>>>>> >>>>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer < >> ganzer at spawar.navy.mil> >>>>>> wrote: >>>>>> >>>>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I >>>>>> connect >>>>>>> to the Los Angeles node, so maybe not all of HE's address space is >>>> being >>>>>>> blocked. >>>>>>> >>>>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from >>>> Time >>>>>>> Warner, but they decided to in their wisdom to disable IPv6 service >>>> for >>>>>>> anyone that has an Arris SB6183 due to an Arris firmware bug. And >>>> they >>>>>> are >>>>>>> taking their sweet time pushing out the fixed firmware update that >>>>>> Comcast >>>>>>> and Cox seemed to be able to push to their customers last fall. >>>>>>> >>>>>>> -Mark Ganzer >>>>>>> >>>>>>> >>>>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote: >>>>>>>> >>>>>>>> Depends - how many US users have native IPv6 through their ISPs? >>>>>>>> >>>>>>>> If I remember correctly (I can't find the source at the moment), >>>> HE.net >>>>>>>> represents something like 70% of IPv6 traffic in the US. >>>>>>>> >>>>>>>> And yeah, not doing that - actually in the middle of an IPv6 project >>>> at >>>>>>>> work at the moment that's a bit important to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl < >>>>>> baldur.norddahl at gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" < >>>>>> cryptographrix at gmail.com>: >>>>>>>>> >>>>>>>>>> The information I'm getting from Netflix support now is explicitly >>>>>>>>> telling >>>>>>>>> >>>>>>>>>> me to turn off IPv6 - someone might want to stop them before they >>>>>>>>>> completely kill US IPv6 adoption. >>>>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need >> need >>>>>>>>> native >>>>>>>>> ipv6. >>>>>>>>> >>>>>>>>> On the other hand it would be nice if Netflix would try the other >>>>>>>>> protocol >>>>>>>>> before blocking. >>>> >> >> From owen at delong.com Sat Jun 4 18:46:56 2016 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2016 11:46:56 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: Message-ID: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> > On Jun 3, 2016, at 23:48 , Mikael Abrahamsson wrote: > > On Fri, 3 Jun 2016, Cryptographrix wrote: > >> I have a VPN connection at my house. There's no way for them to know the difference between me using my home network connection from Hong Kong or my home network connection from my house. > > In my case I have a he.net tunnel from their tunnel servers in Stockholm. This is properly GEOIP:ed to Sweden (I had to get that done by another content provider that seems to use the same GEOIP as Netflix, because after this was done a year ago or something, Netflix stopped thinking I was in the US when I accessed it over IPv6.) > > My regular IPv4 address also GEOIPs to same place. > > So the fact I am using IPv6 through a tunnel provider seems to be what triggers Netflix to block me. The fact that my IPv4 connectivity is NOT through a tunnel, is something they could check. > > I really wish their tunnel connectivity checker was a bit more sofisticated so it would correlate the following: > > My billing address is in Sweden. > My IPv4 GEOIP says I am in Sweden. > My IPv6 GEOIP says I am in Sweden. > > Ok, so fine, I am not trying to circumvent anything so just let me watch the bloody content ok to show to people in Sweden. > > BLOODY HELL! > > -- > Mikael Abrahamsson email: swmike at swm.pp.se Get your own /48 and advertise to HE Tunnel via BGP. Problem solved. From swmike at swm.pp.se Sat Jun 4 19:16:28 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 4 Jun 2016 21:16:28 +0200 (CEST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> Message-ID: On Sat, 4 Jun 2016, Owen DeLong wrote: > Get your own /48 and advertise to HE Tunnel via BGP. Problem solved. I am now instead mooching off of someone elses PI /48 and set up another tunnel, so not using HE at all anymore. Let's see if that works better. Still waiting to be able to test because when I deconfigured IPv6 on my Apple Airport Extreme and moved my IPv6 to an UBNT ER5, the Airport didn't send zero lifetime RAs so now everything is chaos for a while. Family acceptance factor is helped by Happy Eyeballs I guess though... -- Mikael Abrahamsson email: swmike at swm.pp.se From larrysheldon at cox.net Sun Jun 5 01:28:53 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 4 Jun 2016 20:28:53 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <53D9A273-7909-436B-B72F-7033846C3BD6@delong.com> References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <05a3a3! db-0524-7 9dd-6873-30d8b864879a@spawar.navy.mil> <53D9A273-7909-436B-B72F-7033846C3BD6@delong.com> Message-ID: <72fe1d26-e291-7d63-9584-47a784b71091@cox.net> On 6/4/2016 13:38, Owen DeLong wrote: > If you?re wife is really worried about $100/year, give up your first > 2 weeks of Starbucks each year in trade. My wife does very well in managing our sparse resources (in spite of the efforts of the government and the Jesuits) and (I suspect) would not patronize a Starbucks on an errand for a dying parishioner. There are two (at least) things I do not understand about this business (probably why I failed at it). Why do people buy "services" from people who charge extra to annoy their customers, and why do providers work so hard to be annoying when providing better service would actually be cheaper and less work? -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From xxnog at ledeuns.net Sun Jun 5 09:38:17 2016 From: xxnog at ledeuns.net (Denis Fondras) Date: Sun, 5 Jun 2016 11:38:17 +0200 Subject: ERPS/G.8032 interoperability Message-ID: <20160605093817.GN16361@enforcer.ledeuns.net> Hi all, Is there any study on ERPS/G.8032 interoperability between different equipment manufacturer ? Denis From ryan at finnesey.com Sun Jun 5 16:31:56 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Sun, 5 Jun 2016 16:31:56 +0000 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: Would you mind sharing some of the telecommunications focused law firms? I am about to start a company that is going back into the CLEC/ISP/VoIP Business and I am going to have to establish relationships with a few law firms. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Flanery (eric) Sent: Tuesday, May 31, 2016 2:55 PM Cc: NANOG list Subject: Re: ISP License in the USA? There is no such thing as an 'ISP license' in the US. I have a hard time imagining Texas of all places would have such a requirement. Depending on what exactly you are doing, there are various and highly varied requirements, such as acquiring a SPIN number for E-Rate, filing FCC 477 if you do broadband, FCC 499 if you do VoIP (CLEC and ETC also apply there), a FRN if you do pretty much anything FCC-related, various sorts of licenses for most radio/microwave systems (excepting part 15 stuff), CALEA, open internet, etc... COALS _could_ apply _if_ you are running a cable TV system that also delivers data services, but it isn't an 'ISP thing'. More to the point... I wouldn't take US legal advice from any consultant not familiar with US law, or really any non-lawyer consultant at all. I wouldn't take it from NANOG either; while it's a tremendous technical resource, it is not your attorney. There are a number of telecommunications focused law firms out there, with knowledgeable lawyers. It would be a good idea to establish a relationship with one, if you intend to enter the increasingly complex legal minefield of being an ISP. --Eric On Tue, May 31, 2016 at 11:24 AM, Dan White wrote: > Not familiar with the process, but look at E-rate if you want to > provide service to schools, libraries and health providers. > > > On 05/31/16 13:14 -0500, Lorell Hathcock wrote: > >> NANOG: >> >> Our owner has hired a consultant who insists that we should have an >> ISP license to operate in the United States. (Like they have in >> other countries like Germany and in Africa where he has extensive >> personal experience.) >> >> I am asking him to tell me which license we should have because I >> don't know of a license that we are required to have to route IP >> traffic to end customers. >> >> I am familiar with CLEC status filed with our state. But it is not a >> requirement to pass traffic. >> >> He is suggesting COALS with which I am completely unfamiliar. >> >> Can anyone tell me if there is a Texas state and/or USA Federal >> license for a small operator to pass IP traffic from the internet to >> end users (commercial and/or residential). >> >> I am aware that there are some CALEA requirements of ISPs that seem >> to kick in once a CALEA request is made, but is that different from a >> license. >> > > -- > Dan White > BTC Broadband > From mfidelman at meetinghouse.net Sun Jun 5 18:17:12 2016 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 5 Jun 2016 14:17:12 -0400 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: <12088f99-265c-1229-d207-e7ab664f8843@meetinghouse.net> A couple of places to start: Baller Stokes & Lide, P.C. (www.baller.com) http://www.bbklaw.com (which absorbed Miller & Van Eaton a few years back) They both have practices that focus on telecom from a municipal point of view (municipal broadband, right-of-way issues, cable franchises, and such) - which is how I know them - but may be able to help or point you in the right direction. Miles Fidelman On 6/5/16 12:31 PM, Ryan Finnesey wrote: > Would you mind sharing some of the telecommunications focused law firms? I am about to start a company that is going back into the CLEC/ISP/VoIP Business and I am going to have to establish relationships with a few law firms. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Flanery (eric) > Sent: Tuesday, May 31, 2016 2:55 PM > Cc: NANOG list > Subject: Re: ISP License in the USA? > > There is no such thing as an 'ISP license' in the US. I have a hard time imagining Texas of all places would have such a requirement. > > Depending on what exactly you are doing, there are various and highly varied requirements, such as acquiring a SPIN number for E-Rate, filing FCC > 477 if you do broadband, FCC 499 if you do VoIP (CLEC and ETC also apply there), a FRN if you do pretty much anything FCC-related, various sorts of licenses for most radio/microwave systems (excepting part 15 stuff), CALEA, open internet, etc... > > COALS _could_ apply _if_ you are running a cable TV system that also delivers data services, but it isn't an 'ISP thing'. > > More to the point... > > I wouldn't take US legal advice from any consultant not familiar with US law, or really any non-lawyer consultant at all. I wouldn't take it from NANOG either; while it's a tremendous technical resource, it is not your attorney. > > There are a number of telecommunications focused law firms out there, with knowledgeable lawyers. It would be a good idea to establish a relationship with one, if you intend to enter the increasingly complex legal minefield of being an ISP. > > --Eric > > On Tue, May 31, 2016 at 11:24 AM, Dan White wrote: > >> Not familiar with the process, but look at E-rate if you want to >> provide service to schools, libraries and health providers. >> >> >> On 05/31/16 13:14 -0500, Lorell Hathcock wrote: >> >>> NANOG: >>> >>> Our owner has hired a consultant who insists that we should have an >>> ISP license to operate in the United States. (Like they have in >>> other countries like Germany and in Africa where he has extensive >>> personal experience.) >>> >>> I am asking him to tell me which license we should have because I >>> don't know of a license that we are required to have to route IP >>> traffic to end customers. >>> >>> I am familiar with CLEC status filed with our state. But it is not a >>> requirement to pass traffic. >>> >>> He is suggesting COALS with which I am completely unfamiliar. >>> >>> Can anyone tell me if there is a Texas state and/or USA Federal >>> license for a small operator to pass IP traffic from the internet to >>> end users (commercial and/or residential). >>> >>> I am aware that there are some CALEA requirements of ISPs that seem >>> to kick in once a CALEA request is made, but is that different from a >>> license. >>> >> -- >> Dan White >> BTC Broadband >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From faisal at snappytelecom.net Sun Jun 5 19:49:27 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 5 Jun 2016 19:49:27 +0000 (GMT) Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: <1467279082.393014.1465156167179.JavaMail.zimbra@snappytelecom.net> http://www.commlawgroup.com/#hashslider1 or Kris Tomey 's Info:- > Law Office > 1725 I Street, NW, Suite 300 > Washington, DC 20006 > > Phone: 202.250.3413 > Fax: 202.517.9175 > kris at lokt.net > > LoKT Consulting > 1425 Leimert Blvd., Suite 404 > Oakland, CA 94602 > > Phone: 510.285.8010 > Fax: 510.868.8418 > kris at lokt.net > or Stephen E. Coran Lerman Senter, PLLC 2000 K Street, N.W., Suite 600 Washington, D.C. 20006-1809 (202) 416-6744 - office (202) 669-3288 -mobile scoran at lermansenter.com Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Ryan Finnesey" > To: "Eric Flanery (eric)" > Cc: "nanog list" > Sent: Sunday, June 5, 2016 12:31:56 PM > Subject: RE: ISP License in the USA? > Would you mind sharing some of the telecommunications focused law firms? I am > about to start a company that is going back into the CLEC/ISP/VoIP Business and > I am going to have to establish relationships with a few law firms. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Flanery (eric) > Sent: Tuesday, May 31, 2016 2:55 PM > Cc: NANOG list > Subject: Re: ISP License in the USA? > > There is no such thing as an 'ISP license' in the US. I have a hard time > imagining Texas of all places would have such a requirement. > > Depending on what exactly you are doing, there are various and highly varied > requirements, such as acquiring a SPIN number for E-Rate, filing FCC > 477 if you do broadband, FCC 499 if you do VoIP (CLEC and ETC also apply there), > a FRN if you do pretty much anything FCC-related, various sorts of licenses for > most radio/microwave systems (excepting part 15 stuff), CALEA, open internet, > etc... > > COALS _could_ apply _if_ you are running a cable TV system that also delivers > data services, but it isn't an 'ISP thing'. > > More to the point... > > I wouldn't take US legal advice from any consultant not familiar with US law, or > really any non-lawyer consultant at all. I wouldn't take it from NANOG either; > while it's a tremendous technical resource, it is not your attorney. > > There are a number of telecommunications focused law firms out there, with > knowledgeable lawyers. It would be a good idea to establish a relationship with > one, if you intend to enter the increasingly complex legal minefield of being > an ISP. > > --Eric > > On Tue, May 31, 2016 at 11:24 AM, Dan White wrote: > >> Not familiar with the process, but look at E-rate if you want to >> provide service to schools, libraries and health providers. >> >> >> On 05/31/16 13:14 -0500, Lorell Hathcock wrote: >> >>> NANOG: >>> >>> Our owner has hired a consultant who insists that we should have an >>> ISP license to operate in the United States. (Like they have in >>> other countries like Germany and in Africa where he has extensive >>> personal experience.) >>> >>> I am asking him to tell me which license we should have because I >>> don't know of a license that we are required to have to route IP >>> traffic to end customers. >>> >>> I am familiar with CLEC status filed with our state. But it is not a >>> requirement to pass traffic. >>> >>> He is suggesting COALS with which I am completely unfamiliar. >>> >>> Can anyone tell me if there is a Texas state and/or USA Federal >>> license for a small operator to pass IP traffic from the internet to >>> end users (commercial and/or residential). >>> >>> I am aware that there are some CALEA requirements of ISPs that seem >>> to kick in once a CALEA request is made, but is that different from a >>> license. >>> >> >> -- >> Dan White >> BTC Broadband From cboyd at gizmopartners.com Sun Jun 5 20:27:25 2016 From: cboyd at gizmopartners.com (Chris Boyd) Date: Sun, 5 Jun 2016 15:27:25 -0500 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: <0BABACFF-4F2D-4BC7-80BF-338070972220@gizmopartners.com> > On Jun 5, 2016, at 11:31 AM, Ryan Finnesey wrote: > > Would you mind sharing some of the telecommunications focused law firms? I am about to start a company that is going back into the CLEC/ISP/VoIP Business and I am going to have to establish relationships with a few law firms. I highly recommend McCollough Henry, PC in Austin, Texas. http://www.mccolloughhenry.com 1250 South Capital of Texas Highway Building 3, Suite 400 Austin, Texas 78746 (512) 782-2086 ?Chris From menscher at gmail.com Sun Jun 5 21:18:56 2016 From: menscher at gmail.com (Damian Menscher) Date: Sun, 5 Jun 2016 14:18:56 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl wrote: > Den 4. jun. 2016 01.26 skrev "Cryptographrix" : > > > > The information I'm getting from Netflix support now is explicitly > telling > > me to turn off IPv6 - someone might want to stop them before they > > completely kill US IPv6 adoption. > > Not allowing he.net tunnels is not killing ipv6. You just need need native > ipv6. > This entire thread confuses me. Are there normal home users who are being blocked from Netflix because their ISP forces them through a HE VPN? Or is this massive thread just about a handful of geeks who think IPv6 is cool and insist they be allowed to use it despite not having it natively? I could certainly understand ISP concerns that they are receiving user complaints because they failed to provide native IPv6 (why not?), but whining that you've managed to create a non-standard network setup doesn't work with some providers seems a bit silly. Damian From deleskie at gmail.com Sun Jun 5 21:55:34 2016 From: deleskie at gmail.com (jim deleskie) Date: Sun, 5 Jun 2016 18:55:34 -0300 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: Damian, I HIGHLY doubt regular folks are running into issues with this, I suspect its not even geeks in general having issues, I suspect 80% plus of those having issues spend most of their time complaining about something related to v6 and the rest of the geeks not loving them/it enough. -jim On Sun, Jun 5, 2016 at 6:18 PM, Damian Menscher wrote: > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl > > wrote: > > > Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > > > > > > The information I'm getting from Netflix support now is explicitly > > telling > > > me to turn off IPv6 - someone might want to stop them before they > > > completely kill US IPv6 adoption. > > > > Not allowing he.net tunnels is not killing ipv6. You just need need > native > > ipv6. > > > > This entire thread confuses me. Are there normal home users who are being > blocked from Netflix because their ISP forces them through a HE VPN? Or is > this massive thread just about a handful of geeks who think IPv6 is cool > and insist they be allowed to use it despite not having it natively? I > could certainly understand ISP concerns that they are receiving user > complaints because they failed to provide native IPv6 (why not?), but > whining that you've managed to create a non-standard network setup doesn't > work with some providers seems a bit silly. > > Damian > From owen at delong.com Sun Jun 5 21:59:27 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jun 2016 14:59:27 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> > On Jun 5, 2016, at 14:18 , Damian Menscher wrote: > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl > wrote: > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" : >>> >>> The information I'm getting from Netflix support now is explicitly >> telling >>> me to turn off IPv6 - someone might want to stop them before they >>> completely kill US IPv6 adoption. >> >> Not allowing he.net tunnels is not killing ipv6. You just need need native >> ipv6. >> > > This entire thread confuses me. Are there normal home users who are being > blocked from Netflix because their ISP forces them through a HE VPN? Or is > this massive thread just about a handful of geeks who think IPv6 is cool > and insist they be allowed to use it despite not having it natively? I > could certainly understand ISP concerns that they are receiving user > complaints because they failed to provide native IPv6 (why not?), but > whining that you've managed to create a non-standard network setup doesn't > work with some providers seems a bit silly. > > Damian What is non-standard about an HE tunnel? It conforms to the relevant RFCs and is a very common configuration widely deployed to many thousands of locations around the internet. It?s not that Netflix happens to not work with these tunnels, the problem is that they are taking deliberate active steps to specifically block them. Most likely, these steps are being taken at the behest of their content providers, but to the best of my knowledge, that is merely speculation so far as I don?t believe Netflix themselves have confirmed this. (It?s not unlikely that they are unable to do so due to those same content providers likely insisting on these requirements being considered proprietary information subject to NDA.) So? I don?t know how many ?normal users? use HE tunnels vs. ?geeks? or how one would go about defining the difference. I can tell you that there are an awful lot of people using HE tunnels, and based on what I saw while working at HE, I don?t believe they are all geeks. While I would say that geeks are a larger fraction of the HE Tunnel using populace than of the general population, I?m not sure to what extent. Probably a lot less than you think based on the tone of your message. I think that a provider that has specifically claimed to be an early adopter supporting IPv6 and is now having their support department tell customers to turn off IPv6 altogether is certainly noteworthy and not in a good way. Further, if that provider is actively taking steps to damage previously working IPv6 network configurations, that is also worthy of substantial negative publicity. I?m confused as to why you would think otherwise. Owen From mlfreita at mtu.edu Sun Jun 5 22:18:20 2016 From: mlfreita at mtu.edu (Matt Freitag) Date: Sun, 5 Jun 2016 18:18:20 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: While it is damaging negative publicity it also makes sense. HE's tunnel service amounts to a free VPN that happens to provide IPv6. I would love for someone from HE to jump in and explain better how their tunnel works, why it's been blocked by Netflix, and what (if anything) they are doing to mitigate it. For my part, I also found that my HE tunnel no longer worked with Netflix because, again, it amounts to a free VPN service. I had to shut it off. However, I did discover that my ISP Charter Communications runs a 6rd tunnel service for their customers and enabled that on my router instead. Here are the settings I put in my ASUS router, taken off of a Tomato router firmware forum post: DHCP Option: Disable IPv6 Prefix: 2602:100:: IPv6 Prefix Length: 32 IPv4 Border Router: 68.114.165.1 IPv4 Router Mask Length: 0 I'm also using an MTU of 1480 and a Tunnel TTL of 255. Works great, though I imagine it'll only work for other Charter customers who don't care what prefix they get assigned as Charter uses prefix delegation to make this work. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.it.mtu.edu/ On Sun, Jun 5, 2016 at 5:59 PM, Owen DeLong wrote: > > > On Jun 5, 2016, at 14:18 , Damian Menscher wrote: > > > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> > > wrote: > > > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > >>> > >>> The information I'm getting from Netflix support now is explicitly > >> telling > >>> me to turn off IPv6 - someone might want to stop them before they > >>> completely kill US IPv6 adoption. > >> > >> Not allowing he.net tunnels is not killing ipv6. You just need need > native > >> ipv6. > >> > > > > This entire thread confuses me. Are there normal home users who are > being > > blocked from Netflix because their ISP forces them through a HE VPN? Or > is > > this massive thread just about a handful of geeks who think IPv6 is cool > > and insist they be allowed to use it despite not having it natively? I > > could certainly understand ISP concerns that they are receiving user > > complaints because they failed to provide native IPv6 (why not?), but > > whining that you've managed to create a non-standard network setup > doesn't > > work with some providers seems a bit silly. > > > > Damian > > What is non-standard about an HE tunnel? It conforms to the relevant RFCs > and > is a very common configuration widely deployed to many thousands of > locations > around the internet. > > It?s not that Netflix happens to not work with these tunnels, the problem > is > that they are taking deliberate active steps to specifically block them. > > Most likely, these steps are being taken at the behest of their content > providers, > but to the best of my knowledge, that is merely speculation so far as I > don?t > believe Netflix themselves have confirmed this. (It?s not unlikely that > they are > unable to do so due to those same content providers likely insisting on > these > requirements being considered proprietary information subject to NDA.) > > So? I don?t know how many ?normal users? use HE tunnels vs. ?geeks? or how > one > would go about defining the difference. I can tell you that there are an > awful > lot of people using HE tunnels, and based on what I saw while working at > HE, > I don?t believe they are all geeks. While I would say that geeks are a > larger > fraction of the HE Tunnel using populace than of the general population, > I?m > not sure to what extent. Probably a lot less than you think based on the > tone of your message. > > I think that a provider that has specifically claimed to be an early > adopter > supporting IPv6 and is now having their support department tell customers > to > turn off IPv6 altogether is certainly noteworthy and not in a good way. > > Further, if that provider is actively taking steps to damage previously > working > IPv6 network configurations, that is also worthy of substantial negative > publicity. > > I?m confused as to why you would think otherwise. > > Owen > > From laszlo at heliacal.net Sun Jun 5 22:38:53 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sun, 5 Jun 2016 22:38:53 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: On 2016-06-05 21:18, Damian Menscher wrote: > This entire thread confuses me. Are there normal home users who are being > blocked from Netflix because their ISP forces them through a HE VPN? Or is > this massive thread just about a handful of geeks who think IPv6 is cool > and insist they be allowed to use it despite not having it natively? I > could certainly understand ISP concerns that they are receiving user > complaints because they failed to provide native IPv6 (why not?), but > whining that you've managed to create a non-standard network setup doesn't > work with some providers seems a bit silly. > > Damian I think this thread is specifically about bashing Netflix for blocking HE, but the root of the problem is in trying to use the apparent source address of a packet to determine where a person might be located. In this case Netflix is deliberately trying to fight VPNs and the users understand what's going on. Usually a blocked user can't even load the website they are blocked from, so they can't even complain, unless they happen to notice that works from some other ISP (at home/work perhaps). In these situations people blame the network/ISP and that's the part that ticks off the admins of those networks. Try explaining to a complaining user that it's the website's fault while it works from their friend's connection. For another example, some CDN hosts offer their customers the ability to block requests based on GeoIP country - this is a terrible idea for obvious reasons but that doesn't stop CDNs from offering it, and of course website owners fall for it and enable it. Then what happens is there are a bunch of users who can't access the site at all. It makes no sense because they are not 'bad guys' and they're not from the wrong country, so what gives? Well it's just collateral damage, they can move to a major city and use a major national ISP that's in the database. Maybe they're on a HE tunnel, maybe they're on a new ISP who just got their netblocks.. in the end they are blacklisted and to those users it just looks like the website operator went out of business. How widespread is this problem? For me, the websites of the local public school system and a major local grocery store block based on GeoIP and I can't access them because my numbers aren't in their db. There are city services sites that I can't access without jumping through hoops with proxies or VPNs. I've personally tried to complain to several of these website operators and even after escalations the best I can get is "did you try clearing your cookies". It's not good. -Laszlo From menscher at gmail.com Sun Jun 5 22:48:52 2016 From: menscher at gmail.com (Damian Menscher) Date: Sun, 5 Jun 2016 15:48:52 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: On Sun, Jun 5, 2016 at 2:59 PM, Owen DeLong wrote: > > > On Jun 5, 2016, at 14:18 , Damian Menscher wrote: > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> wrote: > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > >>> > >>> The information I'm getting from Netflix support now is explicitly > >> telling > >>> me to turn off IPv6 - someone might want to stop them before they > >>> completely kill US IPv6 adoption. > >> > >> Not allowing he.net tunnels is not killing ipv6. You just need need > native > >> ipv6. > > > > This entire thread confuses me. Are there normal home users who are > being > > blocked from Netflix because their ISP forces them through a HE VPN? Or > is > > this massive thread just about a handful of geeks who think IPv6 is cool > > and insist they be allowed to use it despite not having it natively? I > > could certainly understand ISP concerns that they are receiving user > > complaints because they failed to provide native IPv6 (why not?), but > > whining that you've managed to create a non-standard network setup > doesn't > > work with some providers seems a bit silly. > > What is non-standard about an HE tunnel? It conforms to the relevant RFCs > and > is a very common configuration widely deployed to many thousands of > locations > around the internet. > What *is* standard about them? My earliest training as a sysadmin taught me that any time you switch away from a default setting, you're venturing into the unknown. Your config is no longer well-tested; you may experience strange errors; nobody else will have seen the same bugs. That's exactly what's happening here -- people are setting up IPv6 tunnel broker connections, then complaining that there are unexpected side effects. It?s not that Netflix happens to not work with these tunnels, the problem is > that they are taking deliberate active steps to specifically block them. > [Citation needed] ;) You're taking this as an attack on Hurricane Electric, and by extension on IPv6. But the reality is that Netflix has presumably identified HE tunnel broker as a frequent source of VPN connections that violate their ToS, and they are blocking it as they would any other widescale abuse. The impact to their userbase is miniscule -- as noted above, normal users won't be affected, and those who are have the trivial workaround of disabling tunnelbroker for Netflix-bound connections. (I agree Netflix could helpfully 302 such users to ipv4.netflix.com instead, but it's already such a small problem I doubt that's a priority for them. And it probably wouldn't reduce the hype here anyway.) As a side note, this is a common meme: recently Tor claimed CloudFlare is anti-privacy for requiring captchas for their users. The reality is much more mundane -- service providers need to protect their own networks, and Tor traffic is (according to CloudFlare [ https://blog.cloudflare.com/the-trouble-with-tor/]) 94% abuse. I suggest you focus your efforts on bringing native IPv6 to the masses, not criticizing service providers for defending themselves against abuse, just because that abuse happens to be over a network (HE tunnel broker; Tor; etc) you support. Netflix isn't hurting IPv6 adoption in any real way, but the (incorrect!) claim that IPv6 doesn't work with Netflix will (if this thread is picked up by the press). Damian From owen at delong.com Sun Jun 5 23:01:08 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jun 2016 16:01:08 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25! E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <04A69FE1-03C8-4C6A-8A0F-3A56B336709A@delong.com> > On Jun 5, 2016, at 15:18 , Matt Freitag wrote: > > While it is damaging negative publicity it also makes sense. HE's tunnel service amounts to a free VPN that happens to provide IPv6. I would love for someone from HE to jump in and explain better how their tunnel works, why it's been blocked by Netflix, and what (if anything) they are doing to mitigate it. Well? I?m no longer with HE (for about 2 years now), but it?s a pretty basic 6in4 tunnel set up. They have routers around the world and a web site that will automatically configure those routers for requested tunnels. I?m not sure how you came to the conclusion that HE has responsibility or even the ability to explain Netflix?s actions or mitigate them. HE provides a pipeline. That?s it. You send an encapsulated packet to their router, it unwraps it and forwards it on to the IPv6 internet. Similarly, the IPv6 internet sends their router a packet destined for one of your addresses, HE encapsulates the packet and forwards the encapsulated packet off to your designated router. > For my part, I also found that my HE tunnel no longer worked with Netflix because, again, it amounts to a free VPN service. I had to shut it off. Interestingly, my HE tunnel has no such problem so far. However, I am not using HE address space for my tunnel (which I suspect is the mechanism Netflix is most likely using, most likely they have built a database of common tunnel addresses). > However, I did discover that my ISP Charter Communications runs a 6rd tunnel service for their customers and enabled that on my router instead. Here are the settings I put in my ASUS router, taken off of a Tomato router firmware forum post: > > DHCP Option: Disable > IPv6 Prefix: 2602:100:: > IPv6 Prefix Length: 32 > IPv4 Border Router: 68.114.165.1 > IPv4 Router Mask Length: 0 > > I'm also using an MTU of 1480 and a Tunnel TTL of 255. You probably shouldn?t use such a large TTL. Try 64. > Works great, though I imagine it'll only work for other Charter customers who don't care what prefix they get assigned as Charter uses prefix delegation to make this work. Pretty common setup. Owen > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 > https://www.mtu.edu/ > https://www.it.mtu.edu/ > On Sun, Jun 5, 2016 at 5:59 PM, Owen DeLong > wrote: > > > On Jun 5, 2016, at 14:18 , Damian Menscher > wrote: > > > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl > > > wrote: > > > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > >>> > >>> The information I'm getting from Netflix support now is explicitly > >> telling > >>> me to turn off IPv6 - someone might want to stop them before they > >>> completely kill US IPv6 adoption. > >> > >> Not allowing he.net tunnels is not killing ipv6. You just need need native > >> ipv6. > >> > > > > This entire thread confuses me. Are there normal home users who are being > > blocked from Netflix because their ISP forces them through a HE VPN? Or is > > this massive thread just about a handful of geeks who think IPv6 is cool > > and insist they be allowed to use it despite not having it natively? I > > could certainly understand ISP concerns that they are receiving user > > complaints because they failed to provide native IPv6 (why not?), but > > whining that you've managed to create a non-standard network setup doesn't > > work with some providers seems a bit silly. > > > > Damian > > What is non-standard about an HE tunnel? It conforms to the relevant RFCs and > is a very common configuration widely deployed to many thousands of locations > around the internet. > > It?s not that Netflix happens to not work with these tunnels, the problem is > that they are taking deliberate active steps to specifically block them. > > Most likely, these steps are being taken at the behest of their content providers, > but to the best of my knowledge, that is merely speculation so far as I don?t > believe Netflix themselves have confirmed this. (It?s not unlikely that they are > unable to do so due to those same content providers likely insisting on these > requirements being considered proprietary information subject to NDA.) > > So? I don?t know how many ?normal users? use HE tunnels vs. ?geeks? or how one > would go about defining the difference. I can tell you that there are an awful > lot of people using HE tunnels, and based on what I saw while working at HE, > I don?t believe they are all geeks. While I would say that geeks are a larger > fraction of the HE Tunnel using populace than of the general population, I?m > not sure to what extent. Probably a lot less than you think based on the > tone of your message. > > I think that a provider that has specifically claimed to be an early adopter > supporting IPv6 and is now having their support department tell customers to > turn off IPv6 altogether is certainly noteworthy and not in a good way. > > Further, if that provider is actively taking steps to damage previously working > IPv6 network configurations, that is also worthy of substantial negative > publicity. > > I?m confused as to why you would think otherwise. > > Owen > > From morrowc.lists at gmail.com Sun Jun 5 23:11:33 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 5 Jun 2016 19:11:33 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: On Sun, Jun 5, 2016 at 6:48 PM, Damian Menscher wrote: > I suggest you focus your efforts on bringing native IPv6 to the masses, not > criticizing service providers for defending themselves against abuse, just > because that abuse happens to be over a network (HE tunnel broker; Tor; > etc) you support. > ?I agree with damian here, almost.. I would bet that in teh flix/he case it's not "abuse" or even: "ToS violations", but the requirement by the IP folks selling their content to flix that flix do their best to block 'out of region' access to content. I dislike the IP folks as much as anyone, but :( flix has to make a good-faith-effort or they'll lose content sources, I suspect. -chris? From laszlo at heliacal.net Sun Jun 5 23:33:52 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sun, 5 Jun 2016 23:33:52 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> On 2016-06-05 22:48, Damian Menscher wrote: > > What *is* standard about them? My earliest training as a sysadmin taught > me that any time you switch away from a default setting, you're venturing > into the unknown. Your config is no longer well-tested; you may experience > strange errors; nobody else will have seen the same bugs. > > That's exactly what's happening here -- people are setting up IPv6 tunnel > broker connections, then complaining that there are unexpected side > effects. > > Damian, If we were talking about some device that is outputting incorrect packets and they are failing to work with Netflix I would agree with you, but in this case the packets are standard and everything works fine. Netflix went out of their way to try to find a way to make it not work. The users and geeks aren't just breaking stuff and expecting others to work around their broken setup, but this is actually what Netflix is doing. All Netflix can look at is the content of the packet and so they're using the source address to discriminate. It is true that some users might be able to work around it if they can get on an ISP that gives them an allowed address, but that isn't a good solution for an open internet. There are a lot of non technical Netflix users who are being told to turn off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken system. Those users don't care what IPv6 is, they just learn that it's bad because it breaks Netflix. Most users have no way to change these things and they just aren't going to be able to use Netflix anymore. That's a very selfish way to operate, a huge step backwards, and it's a kick in the balls to everyone who works to make technological progress on the internet. The simple truth is that Netflix is trying to figure out where people are located, but this is not possible to do reliably with current internet technology. Instead they did something that is unreliable, and many customers become collateral damage through no fault of their own. All the breakage is on the Netflix side. -Laszlo From marka at isc.org Sun Jun 5 23:35:27 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2016 09:35:27 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Sun, 05 Jun 2016 15:48:52 -0700." References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4 B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> In message , Damian Menscher writes: > On Sun, Jun 5, 2016 at 2:59 PM, Owen DeLong wrote: > > > > > On Jun 5, 2016, at 14:18 , Damian Menscher wrote: > > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl < > > baldur.norddahl at gmail.com> wrote: > > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" > >: > > >>> > > >>> The information I'm getting from Netflix support now is explicitly > > >> telling > > >>> me to turn off IPv6 - someone might want to stop them before they > > >>> completely kill US IPv6 adoption. > > >> > > >> Not allowing he.net tunnels is not killing ipv6. You just need need > > >> native ipv6. > > > > > > This entire thread confuses me. Are there normal home users who are > > being > > > blocked from Netflix because their ISP forces them through a HE VPN? > Or > > is > > > this massive thread just about a handful of geeks who think IPv6 is > cool > > > and insist they be allowed to use it despite not having it natively? > I > > > could certainly understand ISP concerns that they are receiving user > > > complaints because they failed to provide native IPv6 (why not?), but > > > whining that you've managed to create a non-standard network setup > > doesn't > > > work with some providers seems a bit silly. > > > > What is non-standard about an HE tunnel? It conforms to the relevant > RFCs > > and > > is a very common configuration widely deployed to many thousands of > > locations > > around the internet. > > > > What *is* standard about them? My earliest training as a sysadmin taught > me that any time you switch away from a default setting, you're venturing > into the unknown. Your config is no longer well-tested; you may > experience strange errors; nobody else will have seen the same bugs. Well the encapsulation is standardised. There are 100's of thousands of tunnels many of which have been running for over a decade now. My tunnel is 13 years old at this point. But hey, I may be venturing into the unknown. > That's exactly what's happening here -- people are setting up IPv6 tunnel > broker connections, then complaining that there are unexpected side > effects. Side effects that took 13 years to materialise. Yeah pull the other one. > It???s not that Netflix happens to not work with these tunnels, the problem > is > > that they are taking deliberate active steps to specifically block them. > > > > [Citation needed] ;) http://www.wired.com/2016/03/netflix-discontent-blocked-vpns-boiling/ > You're taking this as an attack on Hurricane Electric, and by extension on > IPv6. But the reality is that Netflix has presumably identified HE tunnel > broker as a frequent source of VPN connections that violate their ToS, and > they are blocking it as they would any other widescale abuse. The impact > to their userbase is miniscule -- as noted above, normal users won't be > affected, and those who are have the trivial workaround of disabling > tunnelbroker for Netflix-bound connections. (I agree Netflix could > helpfully 302 such users to ipv4.netflix.com instead, but it's already > such > a small problem I doubt that's a priority for them. And it probably > wouldn't reduce the hype here anyway.) It is a attack on HE. HE also provides stable user -> address mappings so you can do fine grained geo location based on HE IPv6 addresses. Also despite what the content cartel say using a VPN to bypass georestrictions to get movies is not illegal, nor is it "piracy". Individuals are allowed to import content from other countries. It is commercial importing that is banned. > As a side note, this is a common meme: recently Tor claimed CloudFlare is > anti-privacy for requiring captchas for their users. The reality is much > more mundane -- service providers need to protect their own networks, and > Tor traffic is (according to CloudFlare [ > https://blog.cloudflare.com/the-trouble-with-tor/]) 94% abuse. HE is not Tor. HE is just a ISP that doesn't do large geographic IP blocks. > I suggest you focus your efforts on bringing native IPv6 to the masses, > not > criticizing service providers for defending themselves against abuse, just > because that abuse happens to be over a network (HE tunnel broker; Tor; > etc) you support. Netflix isn't hurting IPv6 adoption in any real way, > but > the (incorrect!) claim that IPv6 doesn't work with Netflix will (if this > thread is picked up by the press). > > Damian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sryan at arbor.net Sun Jun 5 23:36:32 2016 From: sryan at arbor.net (Spencer Ryan) Date: Sun, 5 Jun 2016 19:36:32 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: I'm unaware of any US based user who gets native dual stack from their ISP having issues. Netflix is blocking anonymous VPNs based on their content providers requests. HE'S tunnel broker is effectively that. On Jun 5, 2016 7:34 PM, "Laszlo Hanyecz" wrote: > > > On 2016-06-05 22:48, Damian Menscher wrote: > >> >> What *is* standard about them? My earliest training as a sysadmin taught >> me that any time you switch away from a default setting, you're venturing >> into the unknown. Your config is no longer well-tested; you may >> experience >> strange errors; nobody else will have seen the same bugs. >> >> That's exactly what's happening here -- people are setting up IPv6 tunnel >> broker connections, then complaining that there are unexpected side >> effects. >> >> >> Damian, > > If we were talking about some device that is outputting incorrect packets > and they are failing to work with Netflix I would agree with you, but in > this case the packets are standard and everything works fine. Netflix went > out of their way to try to find a way to make it not work. The users and > geeks aren't just breaking stuff and expecting others to work around their > broken setup, but this is actually what Netflix is doing. All Netflix can > look at is the content of the packet and so they're using the source > address to discriminate. It is true that some users might be able to work > around it if they can get on an ISP that gives them an allowed address, but > that isn't a good solution for an open internet. > > There are a lot of non technical Netflix users who are being told to turn > off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken > system. Those users don't care what IPv6 is, they just learn that it's bad > because it breaks Netflix. Most users have no way to change these things > and they just aren't going to be able to use Netflix anymore. That's a > very selfish way to operate, a huge step backwards, and it's a kick in the > balls to everyone who works to make technological progress on the > internet. The simple truth is that Netflix is trying to figure out where > people are located, but this is not possible to do reliably with current > internet technology. Instead they did something that is unreliable, and > many customers become collateral damage through no fault of their own. All > the breakage is on the Netflix side. > > -Laszlo > > From menscher at gmail.com Sun Jun 5 23:45:56 2016 From: menscher at gmail.com (Damian Menscher) Date: Sun, 5 Jun 2016 16:45:56 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: On Sun, Jun 5, 2016 at 4:33 PM, Laszlo Hanyecz wrote: > On 2016-06-05 22:48, Damian Menscher wrote: > >> >> What *is* standard about them? My earliest training as a sysadmin taught >> me that any time you switch away from a default setting, you're venturing >> into the unknown. Your config is no longer well-tested; you may >> experience >> strange errors; nobody else will have seen the same bugs. >> >> That's exactly what's happening here -- people are setting up IPv6 tunnel >> broker connections, then complaining that there are unexpected side >> effects. >> > > There are a lot of non technical Netflix users who are being told to turn > off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken > system. Those users don't care what IPv6 is, they just learn that it's bad > because it breaks Netflix. Most users have no way to change these things > and they just aren't going to be able to use Netflix anymore. Who are these non-technical Netflix users who accidentally stumbled into having a HE tunnel broker connection without their knowledge? I wasn't aware this sort of thing could happen without user consent, and would like to know if I'm wrong. Only thing I can imagine is if ISPs are using HE as a form of CGN. Another question: what benefit does one get from having a HE tunnel broker connection? Is it just geek points, or is there a practical benefit too? Damian From sryan at arbor.net Sun Jun 5 23:53:49 2016 From: sryan at arbor.net (Spencer Ryan) Date: Sun, 5 Jun 2016 19:53:49 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: > Another question: what benefit does one get from having a HE tunnel broker connection? Is it just geek points, or is there a practical benefit too? We used them to use our own (ARIN) IP space before we had connections in all sites that we could BGP to the carriers, this allowed us to avoid renumbering down the road. This used the BGP Tunnelbroker service though and we announced our own /44 le 48 blocks. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Sun, Jun 5, 2016 at 7:45 PM, Damian Menscher wrote: > On Sun, Jun 5, 2016 at 4:33 PM, Laszlo Hanyecz > wrote: > > > On 2016-06-05 22:48, Damian Menscher wrote: > > > >> > >> What *is* standard about them? My earliest training as a sysadmin > taught > >> me that any time you switch away from a default setting, you're > venturing > >> into the unknown. Your config is no longer well-tested; you may > >> experience > >> strange errors; nobody else will have seen the same bugs. > >> > >> That's exactly what's happening here -- people are setting up IPv6 > tunnel > >> broker connections, then complaining that there are unexpected side > >> effects. > >> > > > > There are a lot of non technical Netflix users who are being told to turn > > off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken > > system. Those users don't care what IPv6 is, they just learn that it's > bad > > because it breaks Netflix. Most users have no way to change these things > > and they just aren't going to be able to use Netflix anymore. > > > Who are these non-technical Netflix users who accidentally stumbled into > having a HE tunnel broker connection without their knowledge? I wasn't > aware this sort of thing could happen without user consent, and would like > to know if I'm wrong. Only thing I can imagine is if ISPs are using HE as > a form of CGN. > > Another question: what benefit does one get from having a HE tunnel broker > connection? Is it just geek points, or is there a practical benefit too? > > Damian > From marka at isc.org Mon Jun 6 00:07:03 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2016 10:07:03 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Sun, 05 Jun 2016 19:36:32 -0400." References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec13 44@heliacal.net> Message-ID: <20160606000703.F1AF44AD2F69@rock.dv.isc.org> In message , Spencer Ryan writes: > I'm unaware of any US based user who gets native dual stack from their ISP > having issues. Netflix is blocking anonymous VPNs based on their content > providers requests. HE'S tunnel broker is effectively that. No. The addresses can be tied back to the individual that created the tunnel which is exactly like tying back the addresses to the person that ordered the cable or dsl service. The HE addresses are no more anonymous than that. The difference is that HE don't have large geo located pools of addresses covering lots of users. Instead each allocated prefix needs to be individually geopip located. My HE /48 is registered with at least one geoip service as they provided tools (a phone app) which allow me to update their database based on the GPS data. Additionally there is no requirement for any ISP to allocate addresses in geoip blocks. Mark > On Jun 5, 2016 7:34 PM, "Laszlo Hanyecz" wrote: > > > > > > > On 2016-06-05 22:48, Damian Menscher wrote: > > > >> > >> What *is* standard about them? My earliest training as a sysadmin taught > >> me that any time you switch away from a default setting, you're venturing > >> into the unknown. Your config is no longer well-tested; you may > >> experience > >> strange errors; nobody else will have seen the same bugs. > >> > >> That's exactly what's happening here -- people are setting up IPv6 tunnel > >> broker connections, then complaining that there are unexpected side > >> effects. > >> > >> > >> Damian, > > > > If we were talking about some device that is outputting incorrect packets > > and they are failing to work with Netflix I would agree with you, but in > > this case the packets are standard and everything works fine. Netflix went > > out of their way to try to find a way to make it not work. The users and > > geeks aren't just breaking stuff and expecting others to work around their > > broken setup, but this is actually what Netflix is doing. All Netflix can > > look at is the content of the packet and so they're using the source > > address to discriminate. It is true that some users might be able to work > > around it if they can get on an ISP that gives them an allowed address, but > > that isn't a good solution for an open internet. > > > > There are a lot of non technical Netflix users who are being told to turn > > off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken > > system. Those users don't care what IPv6 is, they just learn that it's bad > > because it breaks Netflix. Most users have no way to change these things > > and they just aren't going to be able to use Netflix anymore. That's a > > very selfish way to operate, a huge step backwards, and it's a kick in the > > balls to everyone who works to make technological progress on the > > internet. The simple truth is that Netflix is trying to figure out where > > people are located, but this is not possible to do reliably with current > > internet technology. Instead they did something that is unreliable, and > > many customers become collateral damage through no fault of their own. All > > the breakage is on the Netflix side. > > > > -Laszlo > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Jun 6 00:13:58 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2016 10:13:58 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Sun, 05 Jun 2016 16:45:56 -0700." References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec13 44@heliacal.net> Message-ID: <20160606001358.D1E374AD302F@rock.dv.isc.org> In message , Damian Menscher writes: > > Another question: what benefit does one get from having a HE tunnel broker > connection? Is it just geek points, or is there a practical benefit too? I used it to provide a IPv6 connection at home because I develop network software from home and I need to know that it will work over both IPv4 and IPv6. Others use HE tunnels to be able to reach individual machines from outside as the IPv4 NAT prevents it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From laszlo at heliacal.net Mon Jun 6 00:15:51 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 6 Jun 2016 00:15:51 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: <3dc9268b-2491-2a02-70eb-bff15bb96d08@heliacal.net> On 2016-06-05 23:45, Damian Menscher wrote: > Who are these non-technical Netflix users who accidentally stumbled > into having a HE tunnel broker connection without their knowledge? I > wasn't aware this sort of thing could happen without user consent, and > would like to know if I'm wrong. Only thing I can imagine is if ISPs > are using HE as a form of CGN. > > Another question: what benefit does one get from having a HE tunnel > broker connection? Is it just geek points, or is there a practical > benefit too? > > Damian Well, you could use the HE.net tunnels to work around the problem if their GeoIP checks block you in the first place. HE.net tunnelbroker is commonly used by home users on ISPs which don't provide v6 on their own, like Verizon's fios. Home routers generally have support for this built in and it doesn't take someone with a lot of technical knowledge to set it up. You can also set up BGP with HE and they will give you free transit on the free tunnel and accept your announcements. Personally I have set it up with and without BGP at small office locations as a way to provide IPv6 to the office workers, when only v4 was available. You just click to get a HE.net /48. For P2P stuff it's a way to get around NAT - you can get inbound torrent connections or host a shooting game match on your desktop behind the NAT router. -Laszlo From morrowc.lists at gmail.com Mon Jun 6 00:25:06 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 5 Jun 2016 20:25:06 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <3dc9268b-2491-2a02-70eb-bff15bb96d08@heliacal.net> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <3dc9268b-2491-2a02-70eb-bff15bb96d08@heliacal.net> Message-ID: On Sun, Jun 5, 2016 at 8:15 PM, Laszlo Hanyecz wrote: > For P2P stuff it's a way to get around NAT - you can get inbound torrent > connections or host a shooting game match on your desktop behind the NAT > router. ?but to be fair, stun/ice/upnp has made all that work for 'years'...? From joelja at bogus.com Sun Jun 5 18:57:26 2016 From: joelja at bogus.com (joel jaeggli) Date: Sun, 5 Jun 2016 11:57:26 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> Message-ID: <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> HE's downstream cone does not include a whole lot of residential ISPs. if you further exclude the ones that are multihomed you're left with a pretty small subset. that said they (HE) can be and are a valuable peer both in v4 and v6. Personally I wouldn't single home to anything that looks tier-1ish but your mileage may vary the residential operators I look at tend to be fairly diversly connected. On 6/3/16 5:46 PM, Josh Reynolds wrote: > You might be one of a handful. > On Jun 3, 2016 7:35 PM, "Gary E. Miller" wrote: > >> Yo Spencer! >> >> On Fri, 3 Jun 2016 20:13:03 -0400 >> Spencer Ryan wrote: >> >>> Yes but HE doesn't serve residential users directly. >> >> Really? I am the only one? Doubtful. >> >> RGDS >> GARY >> --------------------------------------------------------------------------- >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> gem at rellim.com Tel:+1 541 382 8588 >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From josh at kyneticwifi.com Mon Jun 6 01:23:39 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 5 Jun 2016 20:23:39 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> Message-ID: Uhm, what? Where do you think ISPs get their transit exactly? On Jun 5, 2016 8:17 PM, "joel jaeggli" wrote: > HE's downstream cone does not include a whole lot of residential ISPs. > if you further exclude the ones that are multihomed you're left with a > pretty small subset. that said they (HE) can be and are a valuable peer > both in v4 and v6. > > Personally I wouldn't single home to anything that looks tier-1ish but > your mileage may vary the residential operators I look at tend to be > fairly diversly connected. > > On 6/3/16 5:46 PM, Josh Reynolds wrote: > > You might be one of a handful. > > On Jun 3, 2016 7:35 PM, "Gary E. Miller" wrote: > > > >> Yo Spencer! > >> > >> On Fri, 3 Jun 2016 20:13:03 -0400 > >> Spencer Ryan wrote: > >> > >>> Yes but HE doesn't serve residential users directly. > >> > >> Really? I am the only one? Doubtful. > >> > >> RGDS > >> GARY > >> > --------------------------------------------------------------------------- > >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > >> gem at rellim.com Tel:+1 541 382 8588 > >> > > > > > From randy at psg.com Mon Jun 6 01:31:19 2016 From: randy at psg.com (Randy Bush) Date: Sun, 05 Jun 2016 18:31:19 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: i just want my mtv. and the normal commercials are bad enough. From randy at psg.com Mon Jun 6 01:39:11 2016 From: randy at psg.com (Randy Bush) Date: Sun, 05 Jun 2016 18:39:11 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <57541678.8040204@ripe.net> <57541E42.7040702@ripe.net> References: Message-ID: > is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how > common is it? we verified that the juniper and cisco platforms we tested replied with the source address being the ingress interface. this is, imiho, good. a kind soul actually sent citable tests > At least my MikroTik RB850Gx2, running 'latest stable' (RouterOS > v6.32.2) replies with the outbound interface, not the inbound. > > I'd assume this is because by default, icmp_errors_use_inbound_ifaddr in > linux is disabled, and they haven't changed the default. > > No idea if that can be tweaked in the weird maze of mikrotik config options. and from the same kind engineer > And just to add even more inconsistency, I checked on my Ubiquiti > EdgeMax (a VyOS fork) which does let me check the state of sysctls: > > router:/etc/sysctl.d$ cat 30-vyatta-router.conf > > # Send ICMP responses with primary address of exiting interface > net.ipv4.icmp_errors_use_inbound_ifaddr=1 > > > So someone in Vyatta decided to explictly set this to be enabled. so one win and one loss randy From johnl at iecc.com Mon Jun 6 02:34:44 2016 From: johnl at iecc.com (John Levine) Date: 6 Jun 2016 02:34:44 -0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <20160606023444.25723.qmail@ary.lan> >What is non-standard about an HE tunnel? It conforms to the relevant RFCs and >is a very common configuration widely deployed to many thousands of locations >around the internet. Nothing whatsoever, but so what? >Most likely, these steps are being taken at the behest of their content providers, >but to the best of my knowledge, that is merely speculation so far as I don?t >believe Netflix themselves have confirmed this. (It?s not unlikely that they are >unable to do so due to those same content providers likely insisting on these >requirements being considered proprietary information subject to NDA.) Of course they are. Movie licenses are invariably country specific. R's, John From johnl at iecc.com Mon Jun 6 02:39:39 2016 From: johnl at iecc.com (John Levine) Date: 6 Jun 2016 02:39:39 -0000 Subject: HE tunnels, was Netflix VPN detection - actual engineer needed In-Reply-To: Message-ID: <20160606023939.25768.qmail@ary.lan> >Another question: what benefit does one get from having a HE tunnel broker >connection? Is it just geek points, or is there a practical benefit too? It gets your network a reliable IPv6 connection when your own ISP doesn't support IPv6 yet. That's why I use them. And please skip the rant about how I should stamp my feet and demand my ISP support IPv6, They're perfectly reasonable, but they're dual homed, one of their upstreams doesn't do IPv6, and the number of reasonable providers in semi-rural upstate NY is not huge. R's, John From jlewis at lewis.org Mon Jun 6 02:51:58 2016 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 5 Jun 2016 22:51:58 -0400 (EDT) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: On Sun, 5 Jun 2016, Owen DeLong wrote: > What is non-standard about an HE tunnel? It conforms to the relevant RFCs and > is a very common configuration widely deployed to many thousands of locations > around the internet. > > It??s not that Netflix happens to not work with these tunnels, the problem is > that they are taking deliberate active steps to specifically block them. It's not a question of standard vs non-standard. If Netflix is blocking HE IPv6 space (tunnel customers), I suspect they're doing so because this is effectively an IPv6 VPN service that masks the end-user's real IP making invalid any IP-based GEO assumptions Netflix would like to make about customer connections in order to satisfy their content licenses. > So?? I don??t know how many ??normal users?? use HE tunnels vs. ??geeks?? or how one > would go about defining the difference. I can tell you that there are an awful > lot of people using HE tunnels, and based on what I saw while working at HE, > I don??t believe they are all geeks. While I would say that geeks are a larger You have to be at least somewhat of a geek to even care about IPv6 and know that HE provides free IPv6 tunnels for those who can't get it natively from their own ISP. Ideally, HE's v6 tunnel service should become more or less redundant as more service provider networks dual-stack their customers. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From josh at kyneticwifi.com Mon Jun 6 02:55:06 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 5 Jun 2016 21:55:06 -0500 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: <57541678.8040204@ripe.net> <57541E42.7040702@ripe.net> Message-ID: I'm assuming you'd like this behavior on EdgeOS changed? I know a guy... On Jun 5, 2016 8:41 PM, "Randy Bush" wrote: > > is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how > > common is it? > > we verified that the juniper and cisco platforms we tested replied with > the source address being the ingress interface. this is, imiho, good. > > a kind soul actually sent citable tests > > > At least my MikroTik RB850Gx2, running 'latest stable' (RouterOS > > v6.32.2) replies with the outbound interface, not the inbound. > > > > I'd assume this is because by default, icmp_errors_use_inbound_ifaddr in > > linux is disabled, and they haven't changed the default. > > > > No idea if that can be tweaked in the weird maze of mikrotik config > options. > > and from the same kind engineer > > > And just to add even more inconsistency, I checked on my Ubiquiti > > EdgeMax (a VyOS fork) which does let me check the state of sysctls: > > > > router:/etc/sysctl.d$ cat 30-vyatta-router.conf > > > > # Send ICMP responses with primary address of exiting interface > > net.ipv4.icmp_errors_use_inbound_ifaddr=1 > > > > > > So someone in Vyatta decided to explictly set this to be enabled. > > so one win and one loss > > randy > From marka at isc.org Mon Jun 6 03:22:12 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2016 13:22:12 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Sun, 05 Jun 2016 22:51:58 -0400." References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <20160606032212.BF61C4ADA12E@rock.dv.isc.org> In message , Jon Lewis write s: > On Sun, 5 Jun 2016, Owen DeLong wrote: > > > What is non-standard about an HE tunnel? It conforms to the relevant RFCs a > nd > > is a very common configuration widely deployed to many thousands of locatio > ns > > around the internet. > > > > It??s not that Netflix happens to not work with these tunnels, the problem is > > that they are taking deliberate active steps to specifically block them. > > It's not a question of standard vs non-standard. If Netflix is blocking > HE IPv6 space (tunnel customers), I suspect they're doing so because this > is effectively an IPv6 VPN service that masks the end-user's real IP > making invalid any IP-based GEO assumptions Netflix would like to make > about customer connections in order to satisfy their content licenses. What's not "real" about the HE allocated IPv6 address? They are more stable that most IPv4 addresses you get from residential ISP's. I've had the oldest of my addresses for 13 years. The /48 is slightly newer but it is stable across IPv4 renumberings. They don't change on power cycle of the modem / router. My IPv4 address changes periodically with no notice with the ISP not even honouring the DHCP lease requiring me to take corrective measures. Just because they are not in a big geoip friendly IP block doesn't make them not "real". They are stable addresses and if Netflix or any other geoip based service did their homework they could workout where the addresses are located. The only reason they don't work is that Netflix is lazy and would rather annoy their customers rather than deliver a paid for service. > > So?? I don??t know how many ??normal users?? use HE tunnels vs. ??geeks?? or how one > > would go about defining the difference. I can tell you that there are an aw > ful > > lot of people using HE tunnels, and based on what I saw while working at HE > , > > I don??t believe they are all geeks. While I would say that geeks are a large > r > > You have to be at least somewhat of a geek to even care about IPv6 and > know that HE provides free IPv6 tunnels for those who can't get it > natively from their own ISP. Ideally, HE's v6 tunnel service should > become more or less redundant as more service provider networks dual-stack > their customers. > > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Mon Jun 6 04:03:32 2016 From: randy at psg.com (Randy Bush) Date: Sun, 05 Jun 2016 21:03:32 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: <57541678.8040204@ripe.net> <57541E42.7040702@ripe.net> Message-ID: > I'm assuming you'd like this behavior on EdgeOS changed? no, the opposite. j & c got it right. microtik did not. vyatta seems to have. randy From joelja at bogus.com Mon Jun 6 05:38:40 2016 From: joelja at bogus.com (joel jaeggli) Date: Sun, 5 Jun 2016 22:38:40 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> Message-ID: <088a8da3-f308-7a8a-b5dc-791693997455@bogus.com> On 6/5/16 6:23 PM, Josh Reynolds wrote: > Uhm, what? Where do you think ISPs get their transit exactly? They buy from 2 or more wholesale transit providers and in general they opportunistically peer, although scale helps a lot there. > On Jun 5, 2016 8:17 PM, "joel jaeggli" > wrote: > > HE's downstream cone does not include a whole lot of residential ISPs. > if you further exclude the ones that are multihomed you're left with a > pretty small subset. that said they (HE) can be and are a valuable peer > both in v4 and v6. > > Personally I wouldn't single home to anything that looks tier-1ish but > your mileage may vary the residential operators I look at tend to be > fairly diversly connected. > > On 6/3/16 5:46 PM, Josh Reynolds wrote: > > You might be one of a handful. > > On Jun 3, 2016 7:35 PM, "Gary E. Miller" > wrote: > > > >> Yo Spencer! > >> > >> On Fri, 3 Jun 2016 20:13:03 -0400 > >> Spencer Ryan > wrote: > >> > >>> Yes but HE doesn't serve residential users directly. > >> > >> Really? I am the only one? Doubtful. > >> > >> RGDS > >> GARY > >> > --------------------------------------------------------------------------- > >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > >> gem at rellim.com Tel:+1 541 382 > 8588 > >> > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From todd.crane at n5tech.com Mon Jun 6 05:43:01 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Sun, 5 Jun 2016 22:43:01 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <088a8da3-f308-7a8a-b5dc-791693997455@bogus.com> References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> <088a8da3-f308-7a8a-b5dc-791693997455@bogus.com> Message-ID: <1E66F52D-4161-4582-9AC0-0B3A58785DBC@n5tech.com> Fixed it for you > On Jun 5, 2016, at 10:38 PM, joel jaeggli wrote: > > > They buy from 2 or more wholesale transit providers and in general they > opportunistically bureaucratically peer, although scale helps a lot there. From josh at kyneticwifi.com Mon Jun 6 06:53:21 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 6 Jun 2016 01:53:21 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <088a8da3-f308-7a8a-b5dc-791693997455@bogus.com> References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160603172914.5bb93412@spidey.rellim.com> <94b4063c-5259-c0fb-397b-b8a15097d77d@bogus.com> <088a8da3-f308-7a8a-b5dc-791693997455@bogus.com> Message-ID: I've worked at my fair share of eyeball ISPs, and many of them used HE as one of their connections, On Mon, Jun 6, 2016 at 12:38 AM, joel jaeggli wrote: > On 6/5/16 6:23 PM, Josh Reynolds wrote: >> Uhm, what? Where do you think ISPs get their transit exactly? > > They buy from 2 or more wholesale transit providers and in general they > opportunistically peer, although scale helps a lot there. > >> On Jun 5, 2016 8:17 PM, "joel jaeggli" > > wrote: >> >> HE's downstream cone does not include a whole lot of residential ISPs. >> if you further exclude the ones that are multihomed you're left with a >> pretty small subset. that said they (HE) can be and are a valuable peer >> both in v4 and v6. >> >> Personally I wouldn't single home to anything that looks tier-1ish but >> your mileage may vary the residential operators I look at tend to be >> fairly diversly connected. >> >> On 6/3/16 5:46 PM, Josh Reynolds wrote: >> > You might be one of a handful. >> > On Jun 3, 2016 7:35 PM, "Gary E. Miller" > > wrote: >> > >> >> Yo Spencer! >> >> >> >> On Fri, 3 Jun 2016 20:13:03 -0400 >> >> Spencer Ryan > wrote: >> >> >> >>> Yes but HE doesn't serve residential users directly. >> >> >> >> Really? I am the only one? Doubtful. >> >> >> >> RGDS >> >> GARY >> >> >> --------------------------------------------------------------------------- >> >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> >> gem at rellim.com Tel:+1 541 382 >> 8588 >> >> >> > >> >> > > From mark.tinka at seacom.mu Mon Jun 6 12:47:37 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 6 Jun 2016 14:47:37 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <190488dd-1ebe-9b06-6ee8-17381dfcef2a@seacom.mu> On 5/Jun/16 23:18, Damian Menscher wrote: > This entire thread confuses me. Are there normal home users who are being > blocked from Netflix because their ISP forces them through a HE VPN? Or is > this massive thread just about a handful of geeks who think IPv6 is cool > and insist they be allowed to use it despite not having it natively? I > could certainly understand ISP concerns that they are receiving user > complaints because they failed to provide native IPv6 (why not?), but > whining that you've managed to create a non-standard network setup doesn't > work with some providers seems a bit silly. Non-standard? Sounds like one of those "best-of-breed" words that get thrown around inside companies. Mark. From mark.tinka at seacom.mu Mon Jun 6 12:49:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 6 Jun 2016 14:49:36 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <6e1b9fb2-9a0a-79f7-da0f-6845c8f7d2dc@seacom.mu> On 6/Jun/16 00:18, Matt Freitag wrote: > While it is damaging negative publicity it also makes sense. HE's tunnel > service amounts to a free VPN that happens to provide IPv6. I would love > for someone from HE to jump in and explain better how their tunnel works, > why it's been blocked by Netflix, and what (if anything) they are doing to > mitigate it. > > For my part, I also found that my HE tunnel no longer worked with Netflix > because, again, it amounts to a free VPN service. I had to shut it off. You use the word "free" like as though Netflix would not block a "paid for" VPN service. I don't think the commercial state of the VPN service matters. Mark. From mark.tinka at seacom.mu Mon Jun 6 12:53:04 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 6 Jun 2016 14:53:04 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <4d792a5f-7738-27d7-02f6-cbf40968cad6@seacom.mu> On 6/Jun/16 00:48, Damian Menscher wrote: > What *is* standard about them? My earliest training as a sysadmin taught > me that any time you switch away from a default setting, you're venturing > into the unknown. Your config is no longer well-tested; you may experience > strange errors; nobody else will have seen the same bugs. > > That's exactly what's happening here -- people are setting up IPv6 tunnel > broker connections, then complaining that there are unexpected side > effects. In that case, let's shutdown the entire Internet and be done with it. If any network operator here is running their entire network in a "standard" way as described by Damian, then they are doing something wrong. Mark. From mark.tinka at seacom.mu Mon Jun 6 13:03:14 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 6 Jun 2016 15:03:14 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: On 6/Jun/16 01:45, Damian Menscher wrote: > > Who are these non-technical Netflix users who accidentally stumbled into > having a HE tunnel broker connection without their knowledge? I wasn't > aware this sort of thing could happen without user consent, and would like > to know if I'm wrong. Only thing I can imagine is if ISPs are using HE as > a form of CGN. There are several networks around the world that rely on 6-in-4 because their local provider does not offer IPv6. Mark. From johnstong at westmancom.com Mon Jun 6 13:36:43 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Mon, 6 Jun 2016 13:36:43 +0000 Subject: Traffic engineering and peering for CDNs Message-ID: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> Lately I have been putting in some effort to maximize our IX connections by trying to work with the top 5-ish list of ASNs that still send us traffic via a paid transit connection despite the fact that we are both present on the same IX(s). In one case I missed the fact that one ASN wasn't using the IXs route-servers, that's on me for not spotting that one. Even with proper IX peering in place though it seems like some CDNs are better at using the IX connections than others. ASN 15169 for instance does an excellent job sending more than 99.99% of traffic via the IX connection; thank you. While others only seem to manage to send 60 - 80% of traffic via the IX. What I am not understanding about the respective CDN's network wherein they don't send traffic to me through a consistent path? Is the content coming from widely different places and rather than transport it across their own network from a remote site they would rather hot-potato it out a local transit connection? Are their transit costs so low that they don't care about using an IX connection over transit unlike a small operator like me? Is this just a non-obvious issue wherein they maybe just can't originate enough of the traffic near the IX and therefore don't make use of the IX connection, again a hot-potato phenomenon? Secondly can someone explain to me why some CDNs want a gigabit or two of traffic to be exchanged between our respective networks before they would peer with me via a public IX? I totally get those kinds of thresholds before engaging in a private interconnect but I don't understand the reluctance with regard to a public IX, that they are already established at. Is it again just a simple case of bandwidth economics that operate at a different scale than I can comprehend? I'm hoping the community can shed some light on this for me as I'm trying to avoid grilling the operators that are working with me as I don't expect those front line individuals to necessarily have a full view of the factors at play. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From jlewis at lewis.org Mon Jun 6 14:06:24 2016 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 6 Jun 2016 10:06:24 -0400 (EDT) Subject: Traffic engineering and peering for CDNs In-Reply-To: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> Message-ID: On Mon, 6 Jun 2016, Graham Johnston wrote: > What I am not understanding about the respective CDN's network wherein > they don't send traffic to me through a consistent path? Is the content > coming from widely different places and rather than transport it across > their own network from a remote site they would rather hot-potato it out > a local transit connection? Depends on the CDN, but its possible the traffic is coming from different locations and not all CDNs even have a network, so if you don't have peering with their location serving the traffic (and they don't have a network), the traffic will have to come to you via other paths. > Are their transit costs so low that they don't care about using an IX > connection over transit unlike a small operator like me? Is this just a Maybe. Or maybe the traffic to you is small enough (to them) that you're not on their radar as a desirable peer. Or maybe they just haven't gotten around to sending you a peering request yet. > Secondly can someone explain to me why some CDNs want a gigabit or two > of traffic to be exchanged between our respective networks before they > would peer with me via a public IX? Which ones want that much? We like to see some traffic before moving from "IX route-server peering" to direct peering via the IX, just because there are so many possible peers and only so much router resources. It's really not worth the resources (router or management) to direct peer with a network with which there's virtually no traffic being exchanged, just because we're on the same IX(s). 1-2G to peer seems kind of high. Some might insist that you move peering to PNI if you're doing >1-2G across an IX. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mmg at transtelco.net Mon Jun 6 14:18:07 2016 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Mon, 6 Jun 2016 08:18:07 -0600 Subject: Monitoring system recommendation Message-ID: Dear Nanog community We are currently planning to upgrade our monitoring system (Opsview) due to scalability issues and I was wondering what do you recommend for monitoring 5000 hosts and 35000 services. We would like to use a monitoring system that is compatible with the nagios plugin format, however we are not sure if systems like Icinga/Shinken/Op5 are the way to go. Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? Would you recommend commercial systems like Sevone, Zabbix, etc instead of open source ones? Your input is really appreciated it Thank you and have a great day Regards From pr at isprime.com Mon Jun 6 14:36:19 2016 From: pr at isprime.com (Phil Rosenthal) Date: Mon, 6 Jun 2016 08:36:19 -0600 Subject: Traffic engineering and peering for CDNs In-Reply-To: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> Message-ID: Hello, > On Jun 6, 2016, at 7:36 AM, Graham Johnston wrote: > > Lately I have been putting in some effort to maximize our IX connections by trying to work with the top 5-ish list of ASNs that still send us traffic via a paid transit connection despite the fact that we are both present on the same IX(s). In one case I missed the fact that one ASN wasn't using the IXs route-servers, that's on me for not spotting that one. > > Even with proper IX peering in place though it seems like some CDNs are better at using the IX connections than others. ASN 15169 for instance does an excellent job sending more than 99.99% of traffic via the IX connection; thank you. While others only seem to manage to send 60 - 80% of traffic via the IX. What I am not understanding about the respective CDN's network wherein they don't send traffic to me through a consistent path? Is the content coming from widely different places and rather than transport it across their own network from a remote site they would rather hot-potato it out a local transit connection? Are their transit costs so low that they don't care about using an IX connection over transit unlike a small operator like me? Is this just a non-obvious issue wherein they maybe just can't originate enough of the traffic near the IX and therefore don't make use of the IX connection, again a hot-potato phenomenon? Most CDN?s do not have a backbone. Transit costs are not free, but as most traffic is served by local nodes from cache, the costs of transport between locations in many cases is higher than just sending via transit. In some cases, the CDN may not have good mapping and may not be certain which node is best to serve your customers. In other cases, not all content exists on all nodes, and they may redirect to serve from the nodes which have the content. Finally, there may be an outage or capacity limits from the closest location, and another location may be serving to make up the shortfall. > > Secondly can someone explain to me why some CDNs want a gigabit or two of traffic to be exchanged between our respective networks before they would peer with me via a public IX? I totally get those kinds of thresholds before engaging in a private interconnect but I don't understand the reluctance with regard to a public IX, that they are already established at. Is it again just a simple case of bandwidth economics that operate at a different scale than I can comprehend? > This sounds like a surprisingly high threshold, but to some extent it boils down like this ? setting up sessions requires some time. In the ideal world, the peer is intelligent and has everything set up properly, but even in this case, it still requires some time for making sure things go up properly. Some (but not all) CDN?s have it automated to reduce this time. Some potential peering networks are poorly run, and will leak routes, not announce all of their routes, will not configure the sessions properly, etc ? this adds up to significantly more time. Before the CDN starts setting up peering with another network, it is not necessarily obvious if the potential peer is run by competent people or not. Many CDN?s are members of the route servers. If you are exchanging a small amount of traffic, and both you and the CDN are on the Route Server for the IX, there maybe no reason to set up direct sessions which will require both more coordination time for configuration, and more router cpu time/ram on an ongoing basis. From the perspective of the CDN, most likely, 1Gbps or less is a perfectly reasonable amount of traffic to exchange to peers who are learned only via the route server, and not directly. > I'm hoping the community can shed some light on this for me as I'm trying to avoid grilling the operators that are working with me as I don't expect those front line individuals to necessarily have a full view of the factors at play. > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > Best Regards, -Phil Rosenthal ISPrime From tmorizot at gmail.com Mon Jun 6 14:50:15 2016 From: tmorizot at gmail.com (Scott Morizot) Date: Mon, 6 Jun 2016 09:50:15 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: I have Hulu Plus and Amazon Prime. The only thing I would miss from Netflix is their Marvel original series. And I can live with that. I can't live without my IPv6 enabled home network and Internet connection since that's an essential part of my job. (I'm the IPv6 transition technical lead for a large organization.) While I actually manage my home internet gateway through a linux server and have fine-grained control over the firewall rules, I'm still debating whether I care enough about a handful of series to continue paying a company that is deliberately acting against its users' interests. Right now I'm leaning toward no. But I'll discuss it with my wife before making a final decision. Scott On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka wrote: > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > Who are these non-technical Netflix users who accidentally stumbled into > > having a HE tunnel broker connection without their knowledge? I wasn't > > aware this sort of thing could happen without user consent, and would > like > > to know if I'm wrong. Only thing I can imagine is if ISPs are using HE > as > > a form of CGN. > > There are several networks around the world that rely on 6-in-4 because > their local provider does not offer IPv6. > > Mark. > From mhuff at ox.com Mon Jun 6 14:59:54 2016 From: mhuff at ox.com (Matthew Huff) Date: Mon, 6 Jun 2016 14:59:54 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Netflix IS acting in their user's best interest. In order to provide content that the user's want, the content providers have mandated that they do their due diligence to block out of region users including VPN and open tunnel access. As Hulu and Amazon prime become more popular and their contracts with the content provides come due, they will have to also. You can argue about the content provides business model all you want, but Netflix has to do what they are doing. They aren't blocking IPv6 users, they are blocking users that are using VPNs and/or tunnels since their currently is no practical way of providing GEOIP information about that users that the content providers require. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot > Sent: Monday, June 6, 2016 10:50 AM > To: Mark Tinka > Cc: NANOG list > Subject: Re: Netflix VPN detection - actual engineer needed > > I have Hulu Plus and Amazon Prime. The only thing I would miss from > Netflix > is their Marvel original series. And I can live with that. I can't live > without my IPv6 enabled home network and Internet connection since > that's > an essential part of my job. (I'm the IPv6 transition technical lead > for a > large organization.) While I actually manage my home internet gateway > through a linux server and have fine-grained control over the firewall > rules, I'm still debating whether I care enough about a handful of > series > to continue paying a company that is deliberately acting against its > users' > interests. Right now I'm leaning toward no. But I'll discuss it with my > wife before making a final decision. > > Scott > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > wrote: > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > Who are these non-technical Netflix users who accidentally stumbled > into > > > having a HE tunnel broker connection without their knowledge? I > wasn't > > > aware this sort of thing could happen without user consent, and > would > > like > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > using HE > > as > > > a form of CGN. > > > > There are several networks around the world that rely on 6-in-4 > because > > their local provider does not offer IPv6. > > > > Mark. > > From sryan at arbor.net Mon Jun 6 15:03:16 2016 From: sryan at arbor.net (Spencer Ryan) Date: Mon, 6 Jun 2016 11:03:16 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: As an addendum to this and what someone said earlier about the tunnels not being anonymous: From Netflix's perspective they are. Yes HE knows who controls which tunnel, but if Netflix went to HE and said "Tell me what user has xxxxx/48" HE would say "No". Thus, making them an effective anonymous VPN service from Netflix's perspective. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Mon, Jun 6, 2016 at 10:59 AM, Matthew Huff wrote: > Netflix IS acting in their user's best interest. In order to provide > content that the user's want, the content providers have mandated that they > do their due diligence to block out of region users including VPN and open > tunnel access. As Hulu and Amazon prime become more popular and their > contracts with the content provides come due, they will have to also. > > You can argue about the content provides business model all you want, but > Netflix has to do what they are doing. They aren't blocking IPv6 users, > they are blocking users that are using VPNs and/or tunnels since their > currently is no practical way of providing GEOIP information about that > users that the content providers require. > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot > > Sent: Monday, June 6, 2016 10:50 AM > > To: Mark Tinka > > Cc: NANOG list > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > I have Hulu Plus and Amazon Prime. The only thing I would miss from > > Netflix > > is their Marvel original series. And I can live with that. I can't live > > without my IPv6 enabled home network and Internet connection since > > that's > > an essential part of my job. (I'm the IPv6 transition technical lead > > for a > > large organization.) While I actually manage my home internet gateway > > through a linux server and have fine-grained control over the firewall > > rules, I'm still debating whether I care enough about a handful of > > series > > to continue paying a company that is deliberately acting against its > > users' > > interests. Right now I'm leaning toward no. But I'll discuss it with my > > wife before making a final decision. > > > > Scott > > > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > > wrote: > > > > > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > > > > Who are these non-technical Netflix users who accidentally stumbled > > into > > > > having a HE tunnel broker connection without their knowledge? I > > wasn't > > > > aware this sort of thing could happen without user consent, and > > would > > > like > > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > > using HE > > > as > > > > a form of CGN. > > > > > > There are several networks around the world that rely on 6-in-4 > > because > > > their local provider does not offer IPv6. > > > > > > Mark. > > > > From tmorizot at gmail.com Mon Jun 6 15:03:57 2016 From: tmorizot at gmail.com (Scott Morizot) Date: Mon, 6 Jun 2016 10:03:57 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: Nonsense. That is hardly their only option as many others have pointed out. It's a deliberate and technically lazy choice to block 6in4 tunnels. Those are not even vaguely the same thing as a VPN. They've decided to break normal IPv6 support and do so in a way that does not even fall back to IPv4. They deserve all the bad publicity that comes with such a anti-customer decision and the blame for their implementation choices cannot be passed back to the content providers. Scott On Mon, Jun 6, 2016 at 9:59 AM, Matthew Huff wrote: > Netflix IS acting in their user's best interest. In order to provide > content that the user's want, the content providers have mandated that they > do their due diligence to block out of region users including VPN and open > tunnel access. As Hulu and Amazon prime become more popular and their > contracts with the content provides come due, they will have to also. > > You can argue about the content provides business model all you want, but > Netflix has to do what they are doing. They aren't blocking IPv6 users, > they are blocking users that are using VPNs and/or tunnels since their > currently is no practical way of providing GEOIP information about that > users that the content providers require. > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot > > Sent: Monday, June 6, 2016 10:50 AM > > To: Mark Tinka > > Cc: NANOG list > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > I have Hulu Plus and Amazon Prime. The only thing I would miss from > > Netflix > > is their Marvel original series. And I can live with that. I can't live > > without my IPv6 enabled home network and Internet connection since > > that's > > an essential part of my job. (I'm the IPv6 transition technical lead > > for a > > large organization.) While I actually manage my home internet gateway > > through a linux server and have fine-grained control over the firewall > > rules, I'm still debating whether I care enough about a handful of > > series > > to continue paying a company that is deliberately acting against its > > users' > > interests. Right now I'm leaning toward no. But I'll discuss it with my > > wife before making a final decision. > > > > Scott > > > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > > wrote: > > > > > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > > > > Who are these non-technical Netflix users who accidentally stumbled > > into > > > > having a HE tunnel broker connection without their knowledge? I > > wasn't > > > > aware this sort of thing could happen without user consent, and > > would > > > like > > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > > using HE > > > as > > > > a form of CGN. > > > > > > There are several networks around the world that rely on 6-in-4 > > because > > > their local provider does not offer IPv6. > > > > > > Mark. > > > > From sperreault at jive.com Fri Jun 3 21:54:13 2016 From: sperreault at jive.com (Simon Perreault) Date: Fri, 3 Jun 2016 17:54:13 -0400 Subject: =?UTF-8?Q?Vid=C3=A9otron_CPE_bug?= In-Reply-To: References: Message-ID: Any Vid?otron engineer listening? On your CPE there's a SIP ALG on TCP port 5060 that is causing issues to our clients with Cisco 79xx phones. I'm referring to the CPE that is used for business subscribers with static IP addresses. Please contact me for all the details. Thanks, Simon From feld at feld.me Sun Jun 5 22:56:55 2016 From: feld at feld.me (Mark Felder) Date: Sun, 05 Jun 2016 17:56:55 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <1465167415.3401978.628673425.1B94DB11@webmail.messagingengine.com> On Sun, Jun 5, 2016, at 17:18, Matt Freitag wrote: > While it is damaging negative publicity it also makes sense. HE's tunnel > service amounts to a free VPN that happens to provide IPv6. I would love > for someone from HE to jump in and explain better how their tunnel works, > why it's been blocked by Netflix, and what (if anything) they are doing > to > mitigate it. > > For my part, I also found that my HE tunnel no longer worked with Netflix > because, again, it amounts to a free VPN service. I had to shut it off. > > However, I did discover that my ISP Charter Communications runs a 6rd > tunnel service for their customers and enabled that on my router instead. > Here are the settings I put in my ASUS router, taken off of a Tomato > router > firmware forum post: > > DHCP Option: Disable > IPv6 Prefix: 2602:100:: > IPv6 Prefix Length: 32 > IPv4 Border Router: 68.114.165.1 > IPv4 Router Mask Length: 0 > > I'm also using an MTU of 1480 and a Tunnel TTL of 255. > > Works great, though I imagine it'll only work for other Charter customers > who don't care what prefix they get assigned as Charter uses prefix > delegation to make this work. > That's funny because I tried to switch back to my Charter 6rd tunnel to solve this and found even worse results. I stopped using Charter's 6rd because it was terrible (latency mostly) but I was surprised to find Netflix to be broken, not blocked. In my browser none of the static elements load after I'm logged in. I pretty much get a black page. It's not an MTU problem either... Note, I'm on FreeBSD which doesn't support 6rd completely (there's an uncommitted stf(4) driver with 6rd support by hrs@ but it was broken last I checked). Using just a gif tunnel works but I can't contact any IPs on 2602:100::/32, which is fine because I don't have a reason to talk directly to any Charter 6rd tunnel users. -- Mark Felder feld at feld.me From feld at feld.me Sun Jun 5 23:03:41 2016 From: feld at feld.me (Mark Felder) Date: Sun, 05 Jun 2016 18:03:41 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E661A186@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B401E6619F8A@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E6619FC2@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A0F8@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A186@MUNPRDMBXA1.medline.com> Message-ID: <1465167821.3403383.628676465.0EFE5079@webmail.messagingengine.com> On Fri, Jun 3, 2016, at 17:30, Naslund, Steve wrote: > > I guarantee you that Apple does not know where my Apple TV units or any > of my Sony TVs are because they are on hard Ethernet cables with WiFi > disabled so if they told the lawyers that, they lied. > I woud not be surprised if Apple wakes up the wifi occasionally to listen/scan for SSIDs on non-iPhone devices where there's no worry of impacting battery usage. Just because you don't intend to pass traffic on it does not mean the OS doesn't have a valid use for it. -- Mark Felder feld at feld.me From feld at feld.me Sun Jun 5 23:52:51 2016 From: feld at feld.me (Mark Felder) Date: Sun, 05 Jun 2016 18:52:51 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> Message-ID: <1465170771.3776819.628703297.6CB08F87@webmail.messagingengine.com> On Sun, Jun 5, 2016, at 18:45, Damian Menscher wrote: > > Another question: what benefit does one get from having a HE tunnel > broker > connection? Is it just geek points, or is there a practical benefit too? > I can access all my equipment at home remotely without having to resort to Port Address Translation. I only have one static IPv4 and I run a lot of services. -- Mark Felder feld at feld.me From nanog at radu-adrian.feurdean.net Mon Jun 6 08:08:01 2016 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Mon, 06 Jun 2016 10:08:01 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> Message-ID: <1465200481.63182.628965217.1BE98914@webmail.messagingengine.com> On Sun, Jun 5, 2016, at 23:55, jim deleskie wrote: > Damian, I HIGHLY doubt regular folks are running into issues with this, I > suspect its not even geeks in general having issues, I suspect 80% plus of > those having issues spend most of their time complaining about something > related to v6 and the rest of the geeks not loving them/it enough. You don't even need a HE tunnel in order to be blocked for "VPN reasons": 2 providers, both dual-stacked (2 different v6 prefixes on the home LAN, adresses from both /64s on each machine), only one used for IPv4 exit. With this set-up you DO get random messages about being on a VPN (at least on some devices). From kotikalapudi.sriram at nist.gov Mon Jun 6 11:41:52 2016 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Mon, 6 Jun 2016 11:41:52 +0000 Subject: intra-AS messaging for route leak prevention Message-ID: I am a co-author on a route-leak detection/mitigation/prevention draft in the IDR WG in the IETF: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 Based on private conversations with a few major ISPs, the following common practice for intra-AS messaging (using Community tagging in iBGP) for prevention of route leaks is described in Section 3.2 of the draft: ?Routes are tagged on ingress to an AS with communities for origin, including the type of eBGP peer it was learned from (customer, transit-provider or peer), geographic location, etc. The community attributes are carried across the AS with the routes. Routes that the AS originates directly are tagged with similar origin communities when they are redistributed into BGP from static, IGP, etc. These communities are used along with additional logic in route policies to determine which routes are to be announced to which eBGP peers and which are to be dropped. Route policy is applied to eBGP sessions based on what set of routes they should receive (transit, full routes, internal-only, default-only, etc.). In this process, the ISP's AS also ensures that routes learned from a transit-provider or a lateral peer (i.e. non-transit) at an ingress router are not leaked at an egress router to another transit-provider or peer. Additionally, in many cases, ISP network operators' outbound policies require explicit matches for expected communities before passing routes. This helps ensure that that if an update has made it into the routing table (i.e. RIB) but has missed its ingress community tagging (due to a missing/misapplied ingress policy), it will not be inadvertently leaked.? Question: Are there other means of conveying this information in common use today (i.e. for prevention of route leaks)? Also, the following publicly available references can be possibly cited in support of the above: https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf http://showipbgp.com/bgp-tools/bgp-community-list/91-level3-as3356.html Pointers to any other relevant references would be very welcome as well. Thank you. Sriram From feld at feld.me Mon Jun 6 14:54:39 2016 From: feld at feld.me (Mark Felder) Date: Mon, 06 Jun 2016 09:54:39 -0500 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: <1465224879.2035247.629334225.3B0C6523@webmail.messagingengine.com> On Mon, Jun 6, 2016, at 09:18, Manuel Mar?n wrote: > Dear Nanog community > > We are currently planning to upgrade our monitoring system (Opsview) due > to > scalability issues and I was wondering what do you recommend for > monitoring > 5000 hosts and 35000 services. We would like to use a monitoring system > that is compatible with the nagios plugin format, however we are not sure > if systems like Icinga/Shinken/Op5 are the way to go. > > Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? > Would you recommend commercial systems like Sevone, Zabbix, etc instead > of > open source ones? > While not being completely drop-in compatible with Nagios plugins, Xymon (Big Brother clone) is up to the task of monitoring this many hosts/services. Here's a page with a list of businesses who are publicly reporting their use of Xymon and the number of hosts/services they're monitoring. ServiceNow is the biggest I've seen with 569,869 hosts and 740,185 status messages (different service checks being reported back in). It's really hard to find tools that can scale that large, but with the load distributed to a few Xymon Proxys which are reporting to your centralized instance it will scale as large as you want. https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/User_Guide/The_Xymon_Users_list#ServiceNow.2C_Inc. I've used it for years and greatly prefer it to everything else due to its simplicity and config format. I find nagios's config format extremely tedious. As for Nagios plugins: Nagios derives the results of plugins from the status as exit codes: 0 = green, 1 = yellow, 2 = red if I recall correctly. If you just modify the plugin to execute a Xymon command as the last step and report the color instead of the exit code it should work fine. There was a tool called "xynagios" that automatically made nagios plugins work without modification but I haven't tried to use it and don't know if it's still out there. There are two things you might want to be aware of with Xymon: the monitoring data is not encrypted not the wire; it's up to you to handle that at the moment if you feel it is necessary. It also does not support IPv6. There was a huge rewrite in progress for years to handle both of these but it stalled out. Recently it has picked up a lot of development steam and they're scrapping the major rewrite and back porting the important things. I believe Xymon 4.4 will at least have the encrypted transport. -- Mark Felder feld at feld.me From john-nanog at peachfamily.net Mon Jun 6 15:08:13 2016 From: john-nanog at peachfamily.net (John Peach) Date: Mon, 6 Jun 2016 11:08:13 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> The whois information on the HE IPv6 address, does give the location. At least, it does on mine. On Mon, 6 Jun 2016 11:03:16 -0400 Spencer Ryan wrote: > As an addendum to this and what someone said earlier about the > tunnels not being anonymous: From Netflix's perspective they are. Yes > HE knows who controls which tunnel, but if Netflix went to HE and > said "Tell me what user has xxxxx/48" HE would say "No". Thus, making > them an effective anonymous VPN service from Netflix's perspective. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Mon, Jun 6, 2016 at 10:59 AM, Matthew Huff wrote: > > > Netflix IS acting in their user's best interest. In order to provide > > content that the user's want, the content providers have mandated > > that they do their due diligence to block out of region users > > including VPN and open tunnel access. As Hulu and Amazon prime > > become more popular and their contracts with the content provides > > come due, they will have to also. > > > > You can argue about the content provides business model all you > > want, but Netflix has to do what they are doing. They aren't > > blocking IPv6 users, they are blocking users that are using VPNs > > and/or tunnels since their currently is no practical way of > > providing GEOIP information about that users that the content > > providers require. > > > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-694-5669 > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott > > > Morizot Sent: Monday, June 6, 2016 10:50 AM > > > To: Mark Tinka > > > Cc: NANOG list > > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > > > I have Hulu Plus and Amazon Prime. The only thing I would miss > > > from Netflix > > > is their Marvel original series. And I can live with that. I > > > can't live without my IPv6 enabled home network and Internet > > > connection since that's > > > an essential part of my job. (I'm the IPv6 transition technical > > > lead for a > > > large organization.) While I actually manage my home internet > > > gateway through a linux server and have fine-grained control over > > > the firewall rules, I'm still debating whether I care enough > > > about a handful of series > > > to continue paying a company that is deliberately acting against > > > its users' > > > interests. Right now I'm leaning toward no. But I'll discuss it > > > with my wife before making a final decision. > > > > > > Scott > > > > > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > > > wrote: > > > > > > > > > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > > > > > > > Who are these non-technical Netflix users who accidentally > > > > > stumbled > > > into > > > > > having a HE tunnel broker connection without their > > > > > knowledge? I > > > wasn't > > > > > aware this sort of thing could happen without user consent, > > > > > and > > > would > > > > like > > > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > > > using HE > > > > as > > > > > a form of CGN. > > > > > > > > There are several networks around the world that rely on 6-in-4 > > > because > > > > their local provider does not offer IPv6. > > > > > > > > Mark. > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From mhuff at ox.com Mon Jun 6 15:09:14 2016 From: mhuff at ox.com (Matthew Huff) Date: Mon, 6 Jun 2016 15:09:14 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: <223f4d984d4248648eb6f91072a69869@pur-vm-exch13n2.ox.com> Scott, You are being absurd. The number of Netflix customers using 6in4 tunnels has to be in the 0.0001% territory of their users. They would be committing business malpractice to risk their contracts with content providers to provide access to that negligent amount of users. It?s not laziness to look at the risk versus rewards and decide it isn?t worth it from a business practice. Yes, they could work with tunnel brokers and VPN provides and come up with some way of communicating GEOIP information, but even if the content providers were okay with that the cost involved versus the number of users they would impact would never make it worth their wile. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Scott Morizot [mailto:tmorizot at gmail.com] Sent: Monday, June 6, 2016 11:04 AM To: Matthew Huff Cc: Mark Tinka ; NANOG list Subject: Re: Netflix VPN detection - actual engineer needed Nonsense. That is hardly their only option as many others have pointed out. It's a deliberate and technically lazy choice to block 6in4 tunnels. Those are not even vaguely the same thing as a VPN. They've decided to break normal IPv6 support and do so in a way that does not even fall back to IPv4. They deserve all the bad publicity that comes with such a anti-customer decision and the blame for their implementation choices cannot be passed back to the content providers. Scott On Mon, Jun 6, 2016 at 9:59 AM, Matthew Huff > wrote: Netflix IS acting in their user's best interest. In order to provide content that the user's want, the content providers have mandated that they do their due diligence to block out of region users including VPN and open tunnel access. As Hulu and Amazon prime become more popular and their contracts with the content provides come due, they will have to also. You can argue about the content provides business model all you want, but Netflix has to do what they are doing. They aren't blocking IPv6 users, they are blocking users that are using VPNs and/or tunnels since their currently is no practical way of providing GEOIP information about that users that the content providers require. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot > Sent: Monday, June 6, 2016 10:50 AM > To: Mark Tinka > > Cc: NANOG list > > Subject: Re: Netflix VPN detection - actual engineer needed > > I have Hulu Plus and Amazon Prime. The only thing I would miss from > Netflix > is their Marvel original series. And I can live with that. I can't live > without my IPv6 enabled home network and Internet connection since > that's > an essential part of my job. (I'm the IPv6 transition technical lead > for a > large organization.) While I actually manage my home internet gateway > through a linux server and have fine-grained control over the firewall > rules, I'm still debating whether I care enough about a handful of > series > to continue paying a company that is deliberately acting against its > users' > interests. Right now I'm leaning toward no. But I'll discuss it with my > wife before making a final decision. > > Scott > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > > wrote: > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > Who are these non-technical Netflix users who accidentally stumbled > into > > > having a HE tunnel broker connection without their knowledge? I > wasn't > > > aware this sort of thing could happen without user consent, and > would > > like > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > using HE > > as > > > a form of CGN. > > > > There are several networks around the world that rely on 6-in-4 > because > > their local provider does not offer IPv6. > > > > Mark. > > From sryan at arbor.net Mon Jun 6 15:11:55 2016 From: sryan at arbor.net (Spencer Ryan) Date: Mon, 6 Jun 2016 11:11:55 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: > They deserve all the bad publicity that comes with such a anti-customer decision and the blame for their implementation choices cannot be passed back to the content providers. Content Providers: Block VPN and tunnel services. Netflix: That really isn't the best way of doing this Content Providers: I don't care, do it or we pull our content. Someone here from BBC effectively said the exact same thing. Netflix has no where near enough original content to have their providers all pull out. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Mon, Jun 6, 2016 at 11:03 AM, Scott Morizot wrote: > Nonsense. That is hardly their only option as many others have pointed out. > It's a deliberate and technically lazy choice to block 6in4 tunnels. Those > are not even vaguely the same thing as a VPN. They've decided to break > normal IPv6 support and do so in a way that does not even fall back to > IPv4. They deserve all the bad publicity that comes with such a > anti-customer decision and the blame for their implementation choices > cannot be passed back to the content providers. > > Scott > > On Mon, Jun 6, 2016 at 9:59 AM, Matthew Huff wrote: > > > Netflix IS acting in their user's best interest. In order to provide > > content that the user's want, the content providers have mandated that > they > > do their due diligence to block out of region users including VPN and > open > > tunnel access. As Hulu and Amazon prime become more popular and their > > contracts with the content provides come due, they will have to also. > > > > You can argue about the content provides business model all you want, but > > Netflix has to do what they are doing. They aren't blocking IPv6 users, > > they are blocking users that are using VPNs and/or tunnels since their > > currently is no practical way of providing GEOIP information about that > > users that the content providers require. > > > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-694-5669 > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott > Morizot > > > Sent: Monday, June 6, 2016 10:50 AM > > > To: Mark Tinka > > > Cc: NANOG list > > > Subject: Re: Netflix VPN detection - actual engineer needed > > > > > > I have Hulu Plus and Amazon Prime. The only thing I would miss from > > > Netflix > > > is their Marvel original series. And I can live with that. I can't live > > > without my IPv6 enabled home network and Internet connection since > > > that's > > > an essential part of my job. (I'm the IPv6 transition technical lead > > > for a > > > large organization.) While I actually manage my home internet gateway > > > through a linux server and have fine-grained control over the firewall > > > rules, I'm still debating whether I care enough about a handful of > > > series > > > to continue paying a company that is deliberately acting against its > > > users' > > > interests. Right now I'm leaning toward no. But I'll discuss it with my > > > wife before making a final decision. > > > > > > Scott > > > > > > On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka > > > wrote: > > > > > > > > > > > > > > > On 6/Jun/16 01:45, Damian Menscher wrote: > > > > > > > > > > > > > > Who are these non-technical Netflix users who accidentally stumbled > > > into > > > > > having a HE tunnel broker connection without their knowledge? I > > > wasn't > > > > > aware this sort of thing could happen without user consent, and > > > would > > > > like > > > > > to know if I'm wrong. Only thing I can imagine is if ISPs are > > > using HE > > > > as > > > > > a form of CGN. > > > > > > > > There are several networks around the world that rely on 6-in-4 > > > because > > > > their local provider does not offer IPv6. > > > > > > > > Mark. > > > > > > > From Jason_Livingood at comcast.com Mon Jun 6 15:13:03 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Mon, 6 Jun 2016 15:13:03 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <110625.1465011732@turing-police.cc.vt.edu> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <110625.1465011732@turing-police.cc.vt.edu> Message-ID: The SB6141, while fine for now, is only an 8 downstream channel device. If you are buying one now I would recommend a a 16 or 24 channel device. Alternatively, wait (lease) a few months and buy a DOCSIS 3.1 modem in retail when they come out. Jason Livingood Comcast On 6/3/16, 11:42 PM, "nanog-bounces at nanog.org on behalf of Valdis.Kletnieks at vt.edu" wrote: >On Fri, 03 Jun 2016 17:21:16 -0700, Blair Trosper said: >> ...IF (and that's a big IF in the Bay Area at least) you can get the >>newest >> modems. Easier said than done. > >http://www.amazon.com/ARRIS-SURFboard-SB6141-DOCSIS-Cable/dp/B00AJHDZSI/ > >$68.75 and Done. And the damned thing even pays for itself by not paying >a rental >every month. From swmike at swm.pp.se Mon Jun 6 15:16:36 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 6 Jun 2016 17:16:36 +0200 (CEST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> References: <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: On Mon, 6 Jun 2016, Matthew Huff wrote: > You can argue about the content provides business model all you want, > but Netflix has to do what they are doing. They aren't blocking IPv6 > users, they are blocking users that are using VPNs and/or tunnels since > their currently is no practical way of providing GEOIP information about > that users that the content providers require. See my earlier email. My billing address is in Sweden. My IPv4 address GEOIPs to Sweden. My IPv6 tunnel GEOIPs to Sweden. I am not trying to circumvent ANYTHING, I am trying to watch content available to swedish users. Still, Netflix is blocking my HE IPv6 tunnel, it seems mostly just lazy-blocking all HE prefixes instead of actually writing some intelligent code to try to find the people that are trying to circumvent the geographical limitations imposed by content owners. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore at fud.no Mon Jun 6 15:21:23 2016 From: tore at fud.no (Tore Anderson) Date: Mon, 6 Jun 2016 17:21:23 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: <20160606172123.42825d2d@envy.e5.y.home> * Spencer Ryan > As an addendum to this and what someone said earlier about the > tunnels not being anonymous: From Netflix's perspective they are. Yes > HE knows who controls which tunnel, but if Netflix went to HE and > said "Tell me what user has xxxxx/48" HE would say "No". Thus, making > them an effective anonymous VPN service from Netflix's perspective. Every ISP would say ?No? to that question. In sane juridstictions only law enforcement has any chance of getting that answer (hopefully only if they have a valid mandate from some kind of court). But Netflix shouldn't have any need to ask in the first place. Their customers need to log in to their own personal accounts in order to access any content, when they do Netflix can discover their addresses. Tore From nsuan at nonexiste.net Mon Jun 6 15:31:23 2016 From: nsuan at nonexiste.net (Nicholas Suan) Date: Mon, 6 Jun 2016 11:31:23 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: On Sun, Jun 5, 2016 at 10:51 PM, Jon Lewis wrote: > On Sun, 5 Jun 2016, Owen DeLong wrote: > >> What is non-standard about an HE tunnel? It conforms to the relevant RFCs >> and >> is a very common configuration widely deployed to many thousands of >> locations >> around the internet. >> >> It??s not that Netflix happens to not work with these tunnels, the problem >> is >> that they are taking deliberate active steps to specifically block them. > > > It's not a question of standard vs non-standard. If Netflix is blocking HE > IPv6 space (tunnel customers), I suspect they're doing so because this is > effectively an IPv6 VPN service that masks the end-user's real IP making > invalid any IP-based GEO assumptions Netflix would like to make about > customer connections in order to satisfy their content licenses. > Yes, it's just Netflix being super aggressive about blocking VPNs. They're basically removing access from any sort of service that can be used to tunnel. From job at instituut.net Mon Jun 6 15:54:18 2016 From: job at instituut.net (Job Snijders) Date: Mon, 6 Jun 2016 17:54:18 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: Message-ID: <20160606155418.GD35417@22.rev.meerval.net> On Mon, Jun 06, 2016 at 11:41:52AM +0000, Sriram, Kotikalapudi (Fed) wrote: > I am a co-author on a route-leak detection/mitigation/prevention draft > in the IDR WG in the IETF: > https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 > > Question: Are there other means of conveying this information > in common use today (i.e. for prevention of route leaks)? There is the "human network" approach, where operators share information with each other which be used to generate config to help block "unlikely" announcements from eBGP neighbors. For instance AT&T and NTT agreed (through email) that there should be no intermediate networks between 2914 & 7018, therefore NTT blocks announcements that match as-path-regexp '_7018_' on any and all eBGP sessions, except the direct sessions with 7018. NTT calls this concept "peerlocking". I'll cover this approach at the upcoming NANOG meeting in Chicago: https://www.nanog.org/meetings/abstract?id=2860 Kind regards, Job From Jason_Livingood at comcast.com Mon Jun 6 15:55:58 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Mon, 6 Jun 2016 15:55:58 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: On 6/5/16, 7:11 PM, "NANOG on behalf of Christopher Morrow" wrote: >I dislike the IP folks as much as anyone, but :( flix has to make a >good-faith-effort or they'll lose content sources, I suspect. Perhaps so. And now that they are an original content creator as well, and making large investments to do so, that may also be a factor as they work to maximize distribution revenues. Jason From jeffg at opennms.org Mon Jun 6 16:00:20 2016 From: jeffg at opennms.org (Jeff Gehlbach) Date: Mon, 6 Jun 2016 12:00:20 -0400 Subject: Monitoring system recommendation In-Reply-To: <1465224879.2035247.629334225.3B0C6523@webmail.messagingengine.com> References: <1465224879.2035247.629334225.3B0C6523@webmail.messagingengine.com> Message-ID: <36763329-f6ff-9ea9-a441-5edb35da1bc2@opennms.org> On Mon, Jun 6, 2016, at 09:18, Manuel Mar?n wrote: >> 5000 hosts and 35000 services. We would like to use a monitoring >> system that is compatible with the nagios plugin format, however we >> are not sure if systems like Icinga/Shinken/Op5 are the way to go. At that kind of scale, you need to take a serious look at moving away from the Nagios plugin model. Any model based primarily on forking external processes is going to hold you back. >> Is someone using systems like Op5 or Icinga2 for monitoring > 5000 >> hosts? This kind of scale is easily achieved with OpenNMS with appropriate hardware and planning, largely because it does everything in-process. We do offer limited support for NRPE as a transitional mechanism. Disclosure: I get paid to work with OpenNMS in a consulting capacity. >> Would you recommend commercial systems like Sevone, Zabbix, etc >> instead of open source ones? Zabbix is open source. I know some of their team and would recommend putting them on your list. I also know a number of brilliant people who work for SevOne, but I don't know much about their product. -jeff From laszlo at heliacal.net Mon Jun 6 16:01:29 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 6 Jun 2016 16:01:29 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160606172123.42825d2d@envy.e5.y.home> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> Message-ID: On 2016-06-06 15:21, Tore Anderson wrote: > > But Netflix shouldn't have any need to ask in the first place. Their > customers need to log in to their own personal accounts in order to > access any content, when they do Netflix can discover their addresses. > > Tore Hey there's an idea, how about they ASK the users where they are located, instead of telling them where they are located. Presumably a user will have a new billing address when they move to a new place. That ought to be a lot more accurate than lookup based on a static map of number -> location. I don't think this is too crazy of an idea.. my car insurance company asks me what zip code I keep my cars in. Netflix could ask people what zip code they watch video from. -Laszlo From steve at blighty.com Mon Jun 6 16:02:49 2016 From: steve at blighty.com (Steve Atkins) Date: Mon, 6 Jun 2016 09:02:49 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160606172123.42825d2d@envy.e5.y.home> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5 .y.home> Message-ID: <8A7599D3-9307-4F75-9306-58C6F074320A@blighty.com> > On Jun 6, 2016, at 8:21 AM, Tore Anderson wrote: > > * Spencer Ryan > >> As an addendum to this and what someone said earlier about the >> tunnels not being anonymous: From Netflix's perspective they are. Yes >> HE knows who controls which tunnel, but if Netflix went to HE and >> said "Tell me what user has xxxxx/48" HE would say "No". Thus, making >> them an effective anonymous VPN service from Netflix's perspective. > > Every ISP would say ?No? to that question. In sane juridstictions only > law enforcement has any chance of getting that answer (hopefully only if > they have a valid mandate from some kind of court). HE.net run a perfectly good rwhois server which has my town, state, country and zip code for my personal IPv6 tunnel, just the same as they have full contact information for my HE-provided business IPv6 space. > But Netflix shouldn't have any need to ask in the first place. Their > customers need to log in to their own personal accounts in order to > access any content, when they do Netflix can discover their addresses. The content providers are concerned about who is consuming the content, not who is paying for it. Those needn't be the same people, and given how careful people are not to share netflix creds with friends, often won't be. Netflix could stomp on credential sharing, but they don't seem to particularly want to. Blocking a few VPN providers seems a figleaf to keep the content providers happier while inconveniencing relatively few end users - anyone who's using a VPN or tunnel anyway can probably change things around to avoid the blocking with little effort. Cheers, Steve From cbaker at dyn.com Mon Jun 6 16:03:52 2016 From: cbaker at dyn.com (Chris Baker) Date: Mon, 6 Jun 2016 12:03:52 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: No need to speculate some details are available ... http://www.michaelgeist.ca/2015/04/nobodys-perfect-leaked-contract-reveals-sony-requires-netflix-to-geo-block-but-acknowledges-technology-is-imperfect/ And thats just for a single content provider ... On Mon, Jun 6, 2016 at 11:55 AM, Livingood, Jason < Jason_Livingood at comcast.com> wrote: > On 6/5/16, 7:11 PM, "NANOG on behalf of Christopher Morrow" > wrote: > > >I dislike the IP folks as much as anyone, but :( flix has to make a > >good-faith-effort or they'll lose content sources, I suspect. > > Perhaps so. And now that they are an original content creator as well, and > making large investments to do so, that may also be a factor as they work > to maximize distribution revenues. > > Jason > > From ray at oneunified.net Mon Jun 6 16:17:51 2016 From: ray at oneunified.net (Raymond Burkholder) Date: Mon, 6 Jun 2016 13:17:51 -0300 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: <2a6b01d1c00e$f9ebf280$edc3d780$@oneunified.net> > We are currently planning to upgrade our monitoring system (Opsview) due > to scalability issues and I was wondering what do you recommend for > monitoring > 5000 hosts and 35000 services. We would like to use a monitoring system that Another consideration is check_mk. We use it in our shop. The check_mk people wrapped a bunch of python around the Nagios notification engine. No longer do you need to worry about the tedium of nagios config files, those are all built automatically from commands from a gui or from a single configuration file. Check_mk has a benchmarking page which scales to more hosts than you specified: https://mathias-kettner.de/checkmk_checkmk_benchmarks.html For an architecture diagram of how they use nagios for alerting, and python for scanning: http://mathias-kettner.com/check_mk.html If an included agent isn't available, new ones can be written. We are quite happy with the solution. We've replaced cricket, cacti, nagios, observium, and a little bit of smokeping with this almost all in one tool. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nanog at ics-il.net Mon Jun 6 17:53:12 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 6 Jun 2016 12:53:12 -0500 (CDT) Subject: Traffic engineering and peering for CDNs In-Reply-To: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> Message-ID: <125980230.9402.1465235590241.JavaMail.mhammett@ThunderFuck> Some rely on performance testing to the client's DNS resolver and if they're not using on-net ones, they'll be directed to use a different CDN node. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Graham Johnston" To: "nanog at nanog.org" Sent: Monday, June 6, 2016 8:36:43 AM Subject: Traffic engineering and peering for CDNs Lately I have been putting in some effort to maximize our IX connections by trying to work with the top 5-ish list of ASNs that still send us traffic via a paid transit connection despite the fact that we are both present on the same IX(s). In one case I missed the fact that one ASN wasn't using the IXs route-servers, that's on me for not spotting that one. Even with proper IX peering in place though it seems like some CDNs are better at using the IX connections than others. ASN 15169 for instance does an excellent job sending more than 99.99% of traffic via the IX connection; thank you. While others only seem to manage to send 60 - 80% of traffic via the IX. What I am not understanding about the respective CDN's network wherein they don't send traffic to me through a consistent path? Is the content coming from widely different places and rather than transport it across their own network from a remote site they would rather hot-potato it out a local transit connection? Are their transit costs so low that they don't care about using an IX connection over transit unlike a small operator like me? Is this just a non-obvious issue wherein they maybe just can't originate enough of the traffic near the IX and therefore don't make use of the IX connection, again a hot-potato phenomenon? Secondly can someone explain to me why some CDNs want a gigabit or two of traffic to be exchanged between our respective networks before they would peer with me via a public IX? I totally get those kinds of thresholds before engaging in a private interconnect but I don't understand the reluctance with regard to a public IX, that they are already established at. Is it again just a simple case of bandwidth economics that operate at a different scale than I can comprehend? I'm hoping the community can shed some light on this for me as I'm trying to avoid grilling the operators that are working with me as I don't expect those front line individuals to necessarily have a full view of the factors at play. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From owen at delong.com Mon Jun 6 17:54:46 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 10:54:46 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25! E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <0277486E-CBC9-4007-9F77-0B2F583BDDB6@delong.com> > On Jun 5, 2016, at 15:48 , Damian Menscher wrote: > > On Sun, Jun 5, 2016 at 2:59 PM, Owen DeLong > wrote: > > On Jun 5, 2016, at 14:18 , Damian Menscher > wrote: > > On Fri, Jun 3, 2016 at 4:43 PM, Baldur Norddahl > wrote: > >> Den 4. jun. 2016 01.26 skrev "Cryptographrix" >: > >>> > >>> The information I'm getting from Netflix support now is explicitly > >> telling > >>> me to turn off IPv6 - someone might want to stop them before they > >>> completely kill US IPv6 adoption. > >> > >> Not allowing he.net tunnels is not killing ipv6. You just need need native > >> ipv6. > > > > This entire thread confuses me. Are there normal home users who are being > > blocked from Netflix because their ISP forces them through a HE VPN? Or is > > this massive thread just about a handful of geeks who think IPv6 is cool > > and insist they be allowed to use it despite not having it natively? I > > could certainly understand ISP concerns that they are receiving user > > complaints because they failed to provide native IPv6 (why not?), but > > whining that you've managed to create a non-standard network setup doesn't > > work with some providers seems a bit silly. > > What is non-standard about an HE tunnel? It conforms to the relevant RFCs and > is a very common configuration widely deployed to many thousands of locations > around the internet. > > What *is* standard about them? My earliest training as a sysadmin taught me that any time you switch away from a default setting, you're venturing into the unknown. Your config is no longer well-tested; you may experience strange errors; nobody else will have seen the same bugs. Then your training was flat out wrong. By your definition, it?s an experiment every time you manually configure an IP address on a system. Further, System Administration is somewhat different from Networking. As long as one adheres to the protocols as described in the RFCs, things should generally work. HE tunnels conform to RFCs and operate in a well defined and well documented standard manner that complies with all applicable standards. If you never configure a router for something other than default, it is basically a brick. A very very expensive brick. So by your definition, the entire internet is no longer well-tested, etc. That?s just silly. > > That's exactly what's happening here -- people are setting up IPv6 tunnel broker connections, then complaining that there are unexpected side effects. No, that is not what is happening here. What is happening here is that people set up tunnels through the tunnel broker and it worked just fine for years. Some of the next part is speculation (the belief that it is content providers who are behind it), but the networking part is fact: Netflix then likely got complaints from their content providers because some of those tunnels were being used to obfuscate geographic information allowing users outside the intended content distribution range to access the content. As a result, Netflix began deliberately blocking tunnels, including HE IPv6 tunnels and many other kinds of VPNs. This isn?t a case of something didn?t work because it was non-standard. This is a case of Netflix deliberately blocking things that previously worked. > > It?s not that Netflix happens to not work with these tunnels, the problem is > that they are taking deliberate active steps to specifically block them. > > [Citation needed] ;) See the rest of the thread. See Netflix?s public statements about VPNs and Tunnels. > You're taking this as an attack on Hurricane Electric, and by extension on IPv6. But the reality is that Netflix has presumably identified HE tunnel broker as a frequent source of VPN connections that violate their ToS, and they are blocking it as they would any other widescale abuse. The impact to their userbase is miniscule -- as noted above, normal users won't be affected, and those who are have the trivial workaround of disabling tunnelbroker for Netflix-bound connections. (I agree Netflix could helpfully 302 such users to ipv4.netflix.com instead, but it's already such a small problem I doubt that's a priority for them. And it probably wouldn't reduce the hype here anyway.) Actually, when I read them, the ToS did not prohibit me from using a VPN or a tunnel to reach their service. The ToS did prohibit accessing content from a disallowed geographic region, but the problem here is that Netflix is indiscriminately blocking all tunnels and vpns that they can identify, not just the ones that are being used for geo-obfuscation. > As a side note, this is a common meme: recently Tor claimed CloudFlare is anti-privacy for requiring captchas for their users. The reality is much more mundane -- service providers need to protect their own networks, and Tor traffic is (according to CloudFlare [https://blog.cloudflare.com/the-trouble-with-tor/ ]) 94% abuse. Netflix isn?t protecting their own network by doing this. They are protecting the (stupid) policies of their content providers. > I suggest you focus your efforts on bringing native IPv6 to the masses, not criticizing service providers for defending themselves against abuse, just because that abuse happens to be over a network (HE tunnel broker; Tor; etc) you support. Netflix isn't hurting IPv6 adoption in any real way, but the (incorrect!) claim that IPv6 doesn't work with Netflix will (if this thread is picked up by the press). Netflix isn?t just defending themselves from abuse. They are, in fact, attacking a valid user population attempting to get legitimate services that they have paid for. Owen From bernd.spiess at ip-it.com Mon Jun 6 17:56:07 2016 From: bernd.spiess at ip-it.com (Bernd Spiess) Date: Mon, 6 Jun 2016 17:56:07 +0000 Subject: AW: Traffic engineering and peering for CDNs In-Reply-To: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> Message-ID: <18a66e18bcf348ffbabe29668a9e5078@exchange.ip-it.com> Hi Graham! In addition to the other two comments, I?d like to add some topics: > Lately I have been putting in some effort to maximize our IX connections by > trying to work with the top 5-ish list of ASNs that still send us traffic via a paid > transit connection despite the fact that we are both present on the same IX(s). > In one case I missed the fact that one ASN wasn't using the IXs route-servers, > that's on me for not spotting that one. This brings up some ideas ... see here: 1) Check if the CDN is on the routeserver 2) Check if the CDN has maybe tagged his prefixes with a "do-not-announce" tag (verify at looking glass) (relevant of course only for outbound traffic) 3) Try to establish a direct peering session with the CDN over the IXP so that you are known to the CDN ... some CDN?s could maybe also prefer or have higher priority on direct sessions than via only routeserver... ... quite some networks give you a larger set of prefixes on a direct session... 4) Talk with the CDN and check his geolocation tagging's for your prefixes and maybe let correct them after you have found out what they are doing 5) Think on the fact, that CDN?s could take their routing decision on the geo-location of the used dns resolver server and not on the users ip address 6) Check, that your network or your customers are not referring to public dns resolvers 7) Think on the fact, that ipv6 could maybe be in place and active too ... so don?t forget your ipv6 path and ipv6 dns resolvers... 8) Check your RADB/RIPE/AFRINIC/... routing db entries - if you did something wrong, maybe you are filtered... (check: http://irrexplorer.nlnog.net/ and looking glasses) 9) Check that you have your set of IP prefixes in good order and do not implement strange magic with asymmetric more specifics ... reduce everything to supernetworks on all edges! 10) Check if you are not handing over bgp tagging's which could cause some prevention automatics and check if you do not send high metric values which are maybe causing negative routing decisions on the other side 11) Think on the fact, that CDN?s have the geographic distance as one of their parameters - if the CDN node is too far away from your network - maybe a closer located content box via transit is rated higher than maybe the long distance via peering (if there is no node or no node with the right content next to you) ... typically CDN are very close to larger IXP?s... 12) Think on the fact, that your ip-transit upstream could be a peering for the CDN ... This neutralizes the peering or transit rating from the point of view of the CDN, but of course not for you ... so: talk with the CDN ... therefore you must be known ... therefore, you should have done a peering session ... 13) Talk with your IXP ... maybe he can help ... Anything missing here? Anything wrong with my ideas? (disclaimer: yes, I do work for an IXP ... but this is my personal opinion) happy peering... Bernd Bernd Spiess (Manager Peering Service / DE-CIX Management GmbH) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5411 bytes Desc: not available URL: From feld at feld.me Mon Jun 6 17:58:22 2016 From: feld at feld.me (Mark Felder) Date: Mon, 06 Jun 2016 12:58:22 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> Message-ID: <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> On Mon, Jun 6, 2016, at 10:08, John Peach wrote: > The whois information on the HE IPv6 address, does give the location. > At least, it does on mine. > That's interesting. On mine it does not. It just shows HE's info. -- Mark Felder feld at feld.me From owen at delong.com Mon Jun 6 17:57:23 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 10:57:23 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a! 7a3dfec1344@heliacal.net> Message-ID: > On Jun 5, 2016, at 16:45 , Damian Menscher wrote: > > On Sun, Jun 5, 2016 at 4:33 PM, Laszlo Hanyecz > wrote: > >> On 2016-06-05 22:48, Damian Menscher wrote: >> >>> >>> What *is* standard about them? My earliest training as a sysadmin taught >>> me that any time you switch away from a default setting, you're venturing >>> into the unknown. Your config is no longer well-tested; you may >>> experience >>> strange errors; nobody else will have seen the same bugs. >>> >>> That's exactly what's happening here -- people are setting up IPv6 tunnel >>> broker connections, then complaining that there are unexpected side >>> effects. >>> >> >> There are a lot of non technical Netflix users who are being told to turn >> off IPv6, switch ISPs, get a new VPN, etc. because Netflix has a broken >> system. Those users don't care what IPv6 is, they just learn that it's bad >> because it breaks Netflix. Most users have no way to change these things >> and they just aren't going to be able to use Netflix anymore. > > > Who are these non-technical Netflix users who accidentally stumbled into > having a HE tunnel broker connection without their knowledge? I wasn't > aware this sort of thing could happen without user consent, and would like > to know if I'm wrong. Only thing I can imagine is if ISPs are using HE as > a form of CGN. I don?t know if it ever actually happened or not, but I do know that there were router vendors considering implementing automated Tunnel-broker IPv6 connectivity in instances where native IPv6 was unavailable. All of the API hooks necessary to do so are available in Tunnel Broker. So, it is quite possible that this has happened or will happen in the future. > Another question: what benefit does one get from having a HE tunnel broker > connection? Is it just geek points, or is there a practical benefit too? One can reach IPv6-only content which while a tiny fraction of content today will, by definition be a growing fraction of content in the future. Owen From tom.smyth at wirelessconnect.eu Mon Jun 6 18:03:52 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Mon, 6 Jun 2016 19:03:52 +0100 Subject: Traffic engineering and peering for CDNs In-Reply-To: <125980230.9402.1465235590241.JavaMail.mhammett@ThunderFuck> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> <125980230.9402.1465235590241.JavaMail.mhammett@ThunderFuck> Message-ID: as far as im aware ... a friend of mine on INEX in Ireland said most cdns use source ip of the DNS requests to determine which network to direct them to ... so if you use you have your own resolver on an ip address in your network range cdns can accurately determine what network the request is comming from and determine what ip address / what network that the cdn has nearest to your network... ff you use 3rd party dns servers for your clients... you may not get an optimal ip answer for your dns queries from the CDNS involved I hope this helps Tom Smyth On Mon, Jun 6, 2016 at 6:53 PM, Mike Hammett wrote: > Some rely on performance testing to the client's DNS resolver and if > they're not using on-net ones, they'll be directed to use a different CDN > node. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Graham Johnston" > To: "nanog at nanog.org" > Sent: Monday, June 6, 2016 8:36:43 AM > Subject: Traffic engineering and peering for CDNs > > Lately I have been putting in some effort to maximize our IX connections > by trying to work with the top 5-ish list of ASNs that still send us > traffic via a paid transit connection despite the fact that we are both > present on the same IX(s). In one case I missed the fact that one ASN > wasn't using the IXs route-servers, that's on me for not spotting that one. > > Even with proper IX peering in place though it seems like some CDNs are > better at using the IX connections than others. ASN 15169 for instance does > an excellent job sending more than 99.99% of traffic via the IX connection; > thank you. While others only seem to manage to send 60 - 80% of traffic via > the IX. What I am not understanding about the respective CDN's network > wherein they don't send traffic to me through a consistent path? Is the > content coming from widely different places and rather than transport it > across their own network from a remote site they would rather hot-potato it > out a local transit connection? Are their transit costs so low that they > don't care about using an IX connection over transit unlike a small > operator like me? Is this just a non-obvious issue wherein they maybe just > can't originate enough of the traffic near the IX and therefore don't make > use of the IX connection, again a hot-potato phenomenon? > > Secondly can someone explain to me why some CDNs want a gigabit or two of > traffic to be exchanged between our respective networks before they would > peer with me via a public IX? I totally get those kinds of thresholds > before engaging in a private interconnect but I don't understand the > reluctance with regard to a public IX, that they are already established > at. Is it again just a simple case of bandwidth economics that operate at a > different scale than I can comprehend? > > I'm hoping the community can shed some light on this for me as I'm trying > to avoid grilling the operators that are working with me as I don't expect > those front line individuals to necessarily have a full view of the factors > at play. > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > > > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. From feld at feld.me Mon Jun 6 18:16:20 2016 From: feld at feld.me (Mark Felder) Date: Mon, 06 Jun 2016 13:16:20 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> Message-ID: <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> On Mon, Jun 6, 2016, at 13:09, Brandon Jackson wrote: > Looking up your tunnels block in ARIN will only show HE's Info. > > Using HE's rwhois http://rwhois.he.net/whois.php > > Shows the information provided by the tunnel user at time of signup or as > modified in account settings. > Ahh, correct. This way is showing it for me. I should have known to use their rwhois. -- Mark Felder feld at feld.me From aledm at qix.co.uk Mon Jun 6 19:30:02 2016 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 6 Jun 2016 20:30:02 +0100 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address. Similar to the way that edns-client-subnet records the end user's address for geolocation purposes. I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)? Aled From snoble at sonn.com Mon Jun 6 19:35:23 2016 From: snoble at sonn.com (Steven Noble) Date: Mon, 06 Jun 2016 12:35:23 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: <5755D07B.3050207@sonn.com> It's obviously a nontrivial number otherwise why would Netflix block it? :) Aled Morris wrote: > > Maybe HE's IPv6 tunnel packets could be flagged with a destination option > (extension header field) that records the end-user's IPv4 tunnel endpoint > so geolocation could be done in the "old fashioned" way on that address. > > Similar to the way that edns-client-subnet records the end user's address > for geolocation purposes. > > I have to say though, how many Netflix customers are using HE IPv6 > tunnels, > really? zero percent (to two decimal places)? > > Aled From morrowc.lists at gmail.com Mon Jun 6 19:39:26 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Jun 2016 15:39:26 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris wrote: > Maybe HE's IPv6 tunnel packets could be flagged with a destination option > (extension header field) that records the end-user's IPv4 tunnel endpoint > so geolocation could be done in the "old fashioned" way on that address. > > Similar to the way that edns-client-subnet records the end user's address > for geolocation purposes. > > ?why is this any problem at all for HE to solve? why is this any problem at all for NetFlix to solve? HE just provides transport Netflix is just complying (I suspect) with the wishes of the content owners. complain to your local content owner about this? show the content owners that this sort of restriction in a global economy is silly/counter-productive? explain that: "while I'm a Citizen of locale X, I may often travel around to A, B, C and I'd like for my NetFlix to work in all locations, since I pay good pesos for that access?"? ?Doing any sort of 'authentication' or 'authorization' on src-IP is just .. broken.? > I have to say though, how many Netflix customers are using HE IPv6 tunnels, > really? zero percent (to two decimal places)? > > Aled > From Valdis.Kletnieks at vt.edu Mon Jun 6 19:44:14 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jun 2016 15:44:14 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66d! a@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: <72971.1465242254@turing-police.cc.vt.edu> On Mon, 06 Jun 2016 20:30:02 +0100, Aled Morris said: > Maybe HE's IPv6 tunnel packets could be flagged with a destination option > (extension header field) that records the end-user's IPv4 tunnel endpoint > so geolocation could be done in the "old fashioned" way on that address. > > Similar to the way that edns-client-subnet records the end user's address > for geolocation purposes. First, you'd need buy-in from other tunnel providers. Doing it one-off for HE isn't a scalable answer. And if Netflix can't be bothered to consult rwhois for the ownership (which could be used for other use cases as well), they certainly aren't going to do *new* code as a one-off. Second, you'd need to make sure the extension header didn't get molested or dropped by anything on its way to Netflix. (edns-client-subnet leaves its cookie crumbs a few levels higher in the stack, so is less likely to be mangled by recalcitrant routers) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eric.kuhnke at gmail.com Mon Jun 6 19:59:37 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 6 Jun 2016 12:59:37 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: None of this is a problem with actual network engineering, HE's tunnels work fine. It goes in the category of political/economic/contractual , not "this is a technical problem we need to solve". The problem exists with business/contractual relationship Netflix has with its content providers, which barring a miraculous data leak from a disgruntled sysadmin at Netflix, will remain completely opaque to everyone on the outside looking in. Due to the large sums of money involved, my best guess is that the recent crackdown on VPN and VPN-like tunnels is a result of major content providers staff that have been provided with greatly increased visibility into Netflix's internal processes for identifying and blocking VPNs. Undoubtedly there are dozens of pages in the contracts defining metrics for geolocation and acceptable vs unacceptable levels of "leakage" of content. On Mon, Jun 6, 2016 at 12:39 PM, Christopher Morrow wrote: > On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris wrote: > > > Maybe HE's IPv6 tunnel packets could be flagged with a destination option > > (extension header field) that records the end-user's IPv4 tunnel endpoint > > so geolocation could be done in the "old fashioned" way on that address. > > > > Similar to the way that edns-client-subnet records the end user's address > > for geolocation purposes. > > > > > ?why is this any problem at all for HE to solve? > why is this any problem at all for NetFlix to solve? > > HE just provides transport > Netflix is just complying (I suspect) with the wishes of the content > owners. > > complain to your local content owner about this? show the content owners > that this sort of restriction in a global economy is > silly/counter-productive? explain that: "while I'm a Citizen of locale X, I > may often travel around to A, B, C and I'd like for my NetFlix to work in > all locations, since I pay good pesos for that access?"? > > ?Doing any sort of 'authentication' or 'authorization' on src-IP is just .. > broken.? > > > > > I have to say though, how many Netflix customers are using HE IPv6 > tunnels, > > really? zero percent (to two decimal places)? > > > > Aled > > > From eric at flanery.us Mon Jun 6 20:17:20 2016 From: eric at flanery.us (Eric Flanery (eric)) Date: Mon, 6 Jun 2016 13:17:20 -0700 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: These are the two I'm most familiar with: Lerman Senter, as Faisal mentioned: http://www.lermansenter.com/ Rini O'Neil: http://rinioneil.com/ --Eric From dmitry at interhost.net Mon Jun 6 20:56:55 2016 From: dmitry at interhost.net (Dmitry Sherman) Date: Mon, 6 Jun 2016 20:56:55 +0000 Subject: any way to deal with google's captcha for whole /21 v4? Message-ID: <04819802-41C6-42E7-B0D7-E2E4B79EE158@interhost.net> Hello dear Nanog group, Any suggestions how to deal with Google captcha for whole /21 ipv4 newly acquired block? Every IP from the prefix getting blocked by Captcha which never resolves. Thanks in advance. ? Dmitry Sherman Interhost Networks Ltd dmitry at interhost.net office: 972-74-7029881 mobile: 972-54-3181182 http://www.interhost.co.il From laszlo at heliacal.net Mon Jun 6 21:33:53 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 6 Jun 2016 21:33:53 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: On 2016-06-06 19:39, Christopher Morrow wrote: > > ?Doing any sort of 'authentication' or 'authorization' on src-IP is just .. > broken.? > > This. Netflix is pretending to have a capability (geolocation by src ip) that doesn't exist and there is collateral damage from the application of their half baked solution. Those who end up getting dropped as collateral damage are rightly upset about the discrimination. -Laszlo From eric.kuhnke at gmail.com Mon Jun 6 21:44:32 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 6 Jun 2016 14:44:32 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: Geolocation by IP is even funnier as an idea for those who have worked in network engineering for commercial, geostationary two-way satellite services... Some examples: 1. C-band teleport in Singapore with SingTel IPs, remote terminals in Afghanistan. 2. Ku-band teleport in Germany with IP space in an Intelsat /20, remote terminal on the roof of a US government diplomatic facility in $DEVELOPING_COUNTRY 3. Teleports in Miami with IP space that looks indistinguishable (in terms of BGP-adjacency and traceroutes) from any other ISP in the metro Miami area, providing services to small TDMA VSAT terminals in west Africa. 4. Things in Antarctica that are on the other end of a C-band SCPC pipe from a large earth station in southern California. 5. Maritime Ku and C-band VSAT services with 2.5 meter size 3-axis tracking antennas on top of cruise ships that could be literally anywhere in the Mediterranean or Caribbean oceans, with the terrestrial end of the connection in Switzerland, Italy, Maryland or Georgia. 6. Small pacific island nations that have no submarine fiber connectivity and are now using o3b for IP backhaul, or C-band connectivity to teleports in Australia. On Mon, Jun 6, 2016 at 2:33 PM, Laszlo Hanyecz wrote: > On 2016-06-06 19:39, Christopher Morrow wrote: > >> >> ?Doing any sort of 'authentication' or 'authorization' on src-IP is just >> .. >> broken.? >> >> >> > This. > > Netflix is pretending to have a capability (geolocation by src ip) that > doesn't exist and there is collateral damage from the application of their > half baked solution. Those who end up getting dropped as collateral damage > are rightly upset about the discrimination. > > -Laszlo > > From lyndon at orthanc.ca Mon Jun 6 21:46:12 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 6 Jun 2016 14:46:12 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: > 1. C-band teleport in Singapore with SingTel IPs, remote terminals in > Afghanistan. > > 2. Ku-band teleport in Germany with IP space in an Intelsat /20, remote > terminal on the roof of a US government diplomatic facility in > $DEVELOPING_COUNTRY > > 3. Teleports in Miami with IP space that looks indistinguishable (in terms > of BGP-adjacency and traceroutes) from any other ISP in the metro Miami > area, providing services to small TDMA VSAT terminals in west Africa. > > 4. Things in Antarctica that are on the other end of a C-band SCPC pipe > from a large earth station in southern California. > > 5. Maritime Ku and C-band VSAT services with 2.5 meter size 3-axis tracking > antennas on top of cruise ships that could be literally anywhere in the > Mediterranean or Caribbean oceans, with the terrestrial end of the > connection in Switzerland, Italy, Maryland or Georgia. > > 6. Small pacific island nations that have no submarine fiber connectivity > and are now using o3b for IP backhaul, or C-band connectivity to teleports > in Australia. Yes. All big Netflix customers. From marka at isc.org Mon Jun 6 21:53:53 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Jun 2016 07:53:53 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Mon, 06 Jun 2016 12:59:37 -0700." References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach- desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> Message-ID: <20160606215353.1E92D4AE7420@rock.dv.isc.org> In message , Eric Kuhnke writes: > None of this is a problem with actual network engineering, HE's tunnels > work fine. It goes in the category of political/economic/contractual , not > "this is a technical problem we need to solve". > > The problem exists with business/contractual relationship Netflix has with > its content providers, which barring a miraculous data leak from a > disgruntled sysadmin at Netflix, will remain completely opaque to everyone > on the outside looking in. > > Due to the large sums of money involved, my best guess is that the recent > crackdown on VPN and VPN-like tunnels is a result of major content > providers staff that have been provided with greatly increased visibility > into Netflix's internal processes for identifying and blocking VPNs. > Undoubtedly there are dozens of pages in the contracts defining metrics for > geolocation and acceptable vs unacceptable levels of "leakage" of content. And they could easily redirect HE IPv6 addresses to a IPv4 only service. This would satify both the content providers and the customers. It's not like there tunneled traffic is IPv6 only as there has to be a IPv4 endpoint for the tunnel. You can't argue that HE is too small to do this for as they are targeting HE tunnels. Mark > On Mon, Jun 6, 2016 at 12:39 PM, Christopher Morrow m > > wrote: > > > On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris wrote: > > > > > Maybe HE's IPv6 tunnel packets could be flagged with a destination opti= > on > > > (extension header field) that records the end-user's IPv4 tunnel endpoi= > nt > > > so geolocation could be done in the "old fashioned" way on that address= > . > > > > > > Similar to the way that edns-client-subnet records the end user's addre= > ss > > > for geolocation purposes. > > > > > > > > =E2=80=8Bwhy is this any problem at all for HE to solve? > > why is this any problem at all for NetFlix to solve? > > > > HE just provides transport > > Netflix is just complying (I suspect) with the wishes of the content > > owners. > > > > complain to your local content owner about this? show the content owners > > that this sort of restriction in a global economy is > > silly/counter-productive? explain that: "while I'm a Citizen of locale X,= > I > > may often travel around to A, B, C and I'd like for my NetFlix to work in > > all locations, since I pay good pesos for that access?"=E2=80=8B > > > > =E2=80=8BDoing any sort of 'authentication' or 'authorization' on src-IP = > is just .. > > broken.=E2=80=8B > > > > > > > > > I have to say though, how many Netflix customers are using HE IPv6 > > tunnels, > > > really? zero percent (to two decimal places)? > > > > > > Aled > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Mon Jun 6 21:53:58 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 06 Jun 2016 17:53:58 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4 B43-93A7-B1E4BD9F5996@delong.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> Message-ID: On Sun, 05 Jun 2016 19:35:27 -0400, Mark Andrews wrote: > It is a attack on HE. HE also provides stable user -> address > mappings so you can do fine grained geo location based on HE IPv6 > addresses. They may be "fine grained", but they are still lies. One's tunnel can be terminated from *anywhere*, at *anytime*. HE doesn't publish the IPv4 address of the tunnel endpoint, nor do they update any public facing registry w.r.t. the "address" of that IPv4 address. (which is 99% voodoo as well.) > Also despite what the content cartel say using a VPN to bypass > georestrictions to get movies is not illegal, nor is it "piracy". > Individuals are allowed to import content from other countries. It > is commercial importing that is banned. While the end user may not be violating any law (other than their "contract" with Netflix), Netflix certainly is. They signed a contract that says they cannot send X to Romania / X is only allowed in the USA. In the end, they are allowing content to go where they agreed to not send it. They are legally required to do something about that. (or at least, *look* like they are.) Netflix (and their licensees) know people are using HE tunnels to get around region restrictions. Their hands are tied; they have to show they're doing something to limit this. All you can tell about a HE tunnel is the tunnel broker server that's hosting it. (it's in the hostname -- eg. ash1) Beyond that, you have absolutely no idea where in the universe the other end actually is. Plus, it can move in an instant... one DDNS update, and it's somewhere else. --Ricky From jfbeam at gmail.com Mon Jun 6 22:23:58 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 06 Jun 2016 18:23:58 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66da@jpeach-desktop.anbg.mssm.edu> Message-ID: On Mon, 06 Jun 2016 11:08:13 -0400, John Peach wrote: > The whois information on the HE IPv6 address, does give the location. > At least, it does on mine. It lists the location of the user's registration -- which could very well be a lie as they do nothing at all to verify it. AND that has zero correlation with where the tunnel actually goes. There in is the problem... your tunnel isn't nailed to a physical line ["T1"], or a physical device ["cablemodem"]; it's loosely pinned to an IPv4 address. An address that can change in an instance. An address that can literally be any where. From damian at google.com Mon Jun 6 22:28:02 2016 From: damian at google.com (Damian Menscher) Date: Mon, 6 Jun 2016 15:28:02 -0700 Subject: any way to deal with google's captcha for whole /21 v4? In-Reply-To: <04819802-41C6-42E7-B0D7-E2E4B79EE158@interhost.net> References: <04819802-41C6-42E7-B0D7-E2E4B79EE158@interhost.net> Message-ID: This usually happens because we've detected abuse on your network. Please send me details off-list -- I think you may be an unusual case with the recent transfer of the IP-space. I'm especially curious who you acquired it from since they may have been using it for abuse, then sold it when it was "burned". Damian -- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 On Mon, Jun 6, 2016 at 1:56 PM, Dmitry Sherman wrote: > Hello dear Nanog group, > Any suggestions how to deal with Google captcha for whole /21 ipv4 newly > acquired block? > Every IP from the prefix getting blocked by Captcha which never resolves. > Thanks in advance. > > ? > Dmitry Sherman > Interhost Networks Ltd > dmitry at interhost.net > office: 972-74-7029881 > mobile: 972-54-3181182 > http://www.interhost.co.il > > > > > From jfbeam at gmail.com Mon Jun 6 23:08:58 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 06 Jun 2016 19:08:58 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <72971.1465242254@turing-police.cc.vt.edu> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66d! a@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> <72971.1465242254@turing-police.cc.vt.edu> Message-ID: On Mon, 06 Jun 2016 15:44:14 -0400, wrote: > And if Netflix can't be bothered to consult rwhois > for the ownership (which could be used for other use cases as well), they > certainly aren't going to do *new* code as a one-off. Said by someone who's never written (r)whois parsers. There's no standard, you don't know who's running one, and God knows what it's going to spit out. It's hard enough to simply know who to ask. (see also: jwhois) Parsing whatever junk gets sent back almost requires an AI. Yes, ARIN and RIPE have REST APIs, but they're completely different interfaces with different schemas (and different capabilities.) I have independent applications for talking to each. And those are the only two I'm going to bother with. HE doesn't do a GeoIP lookup for the location of your v4 address and update their rwhois information every time your tunnel endpoint changes. Even if they did, Netflix would have to query that for every connection attempt to make sure you haven't moved it. That's never going to happen. --Ricky From baldur.norddahl at gmail.com Mon Jun 6 23:12:18 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 7 Jun 2016 01:12:18 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: > And they could easily redirect HE IPv6 addresses to a IPv4 only > service. This would satify both the content providers and the > customers. It's not like there tunneled traffic is IPv6 only as > there has to be a IPv4 endpoint for the tunnel. > > You can't argue that HE is too small to do this for as they are > targeting HE tunnels. > > Mark And while we wait for Netflix to do that, you could also turn off ipv6 on your Netflix watching device as a quick fix. Most smart tv do not support it to start with. It is a bit surprising that your browser would choose the ipv6 path via tunnel over the more direct ipv4 path. Anyway, you could blackhole the Netflix ipv6 prefix to force the situation. Or you could get your own /48 prefix and announce via BGP. Might not be free but comes with other advantages and has some coolness factor. Or turn off the tunnel while you watch Netflix. Lots of options for "can do" people. Yes we all hate geo ip solutions but this particular Netflix issue is not a big thing in the grand scheme of things. Regards Baldur From owen at delong.com Mon Jun 6 23:32:02 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 16:32:02 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> Message-ID: <35BB3287-7187-49AE-AA6F-5E959FA04241@delong.com> While I think this may well be the reason for Netflix?s actions, do you have any evidence to back up this claim? Actual evidence vs. just a very good educated guess and speculation could prove very useful in this circumstance. Owen > On Jun 6, 2016, at 7:59 AM, Matthew Huff wrote: > > Netflix IS acting in their user's best interest. In order to provide content that the user's want, the content providers have mandated that they do their due diligence to block out of region users including VPN and open tunnel access. As Hulu and Amazon prime become more popular and their contracts with the content provides come due, they will have to also. > > You can argue about the content provides business model all you want, but Netflix has to do what they are doing. They aren't blocking IPv6 users, they are blocking users that are using VPNs and/or tunnels since their currently is no practical way of providing GEOIP information about that users that the content providers require. > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot >> Sent: Monday, June 6, 2016 10:50 AM >> To: Mark Tinka >> Cc: NANOG list >> Subject: Re: Netflix VPN detection - actual engineer needed >> >> I have Hulu Plus and Amazon Prime. The only thing I would miss from >> Netflix >> is their Marvel original series. And I can live with that. I can't live >> without my IPv6 enabled home network and Internet connection since >> that's >> an essential part of my job. (I'm the IPv6 transition technical lead >> for a >> large organization.) While I actually manage my home internet gateway >> through a linux server and have fine-grained control over the firewall >> rules, I'm still debating whether I care enough about a handful of >> series >> to continue paying a company that is deliberately acting against its >> users' >> interests. Right now I'm leaning toward no. But I'll discuss it with my >> wife before making a final decision. >> >> Scott >> >> On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka >> wrote: >> >>> >>> >>> On 6/Jun/16 01:45, Damian Menscher wrote: >>> >>>> >>>> Who are these non-technical Netflix users who accidentally stumbled >> into >>>> having a HE tunnel broker connection without their knowledge? I >> wasn't >>>> aware this sort of thing could happen without user consent, and >> would >>> like >>>> to know if I'm wrong. Only thing I can imagine is if ISPs are >> using HE >>> as >>>> a form of CGN. >>> >>> There are several networks around the world that rely on 6-in-4 >> because >>> their local provider does not offer IPv6. >>> >>> Mark. >>> From marka at isc.org Mon Jun 6 23:41:14 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Jun 2016 09:41:14 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Mon, 06 Jun 2016 17:53:58 -0400." References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4 B43-93A7-B1E4BD9F5996@delong.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> Message-ID: <20160606234114.7A7904AE812D@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Sun, 05 Jun 2016 19:35:27 -0400, Mark Andrews wrote: > > It is a attack on HE. HE also provides stable user -> address > > mappings so you can do fine grained geo location based on HE IPv6 > > addresses. > > They may be "fine grained", but they are still lies. One's tunnel can be > terminated from *anywhere*, at *anytime*. HE doesn't publish the IPv4 > address of the tunnel endpoint, nor do they update any public facing > registry w.r.t. the "address" of that IPv4 address. (which is 99% voodoo > as well.) What lie? Truly who is lying here. Not the end user. Not HE. There is no requirement to report physical location. > > Also despite what the content cartel say using a VPN to bypass > > georestrictions to get movies is not illegal, nor is it "piracy". > > Individuals are allowed to import content from other countries. It > > is commercial importing that is banned. > > While the end user may not be violating any law (other than their > "contract" with Netflix), Netflix certainly is. They signed a contract > that says they cannot send X to Romania / X is only allowed in the USA. In > the end, they are allowing content to go where they agreed to not send it. > They are legally required to do something about that. (or at least, *look* > like they are.) Are they legally required to go to this level? I actually doubt it. I would love to see this tested in a court because I suspect the content cartel would loose as they were well aware that the geoip databases are imperfect and no one in the world can accurately determine from the IP address where a machine is located. There is a difference between knowingly sending to a different region and incidentally sending to another region. The courts understand this. > Netflix (and their licensees) know people are using HE tunnels to get > around region restrictions. Their hands are tied; they have to show > they're doing something to limit this. No, they do not know. The purpose of HE tunnels is to get IPv6 service. The fact that the endpoints are in different countries some of the time is incidental to that. I have a HE tunnel. It terminates at the topologically closest point which is in California. There is a physically closer endpoint in Hong Kong but it would require a double trip across the Pacific to get to it. Unless you are crazy you don't put the topological tunnel endpoint further from you than you can. When HE finish getting their Sydney pop set up (it wasn't the last time I looked) I'll set up a new tunnel to it and tear down the existing tunnel. It's going to be a few years more before I can get native IPv6. The NBN really put the breaks on IPv6 deployment in Australia as ISP's don't want to invest in the existing technology they are using knowing that the customer is going to be switched to using the NBN in a couple of years. > All you can tell about a HE tunnel is the tunnel broker server that's > hosting it. (it's in the hostname -- eg. ash1) Beyond that, you have > absolutely no idea where in the universe the other end actually is. Plus, > it can move in an instant... one DDNS update, and it's somewhere else. Garbage. You have to establish the tunnel which requires registering a account. It also requires a machine at the other end. Virtual or physical they don't move around the world in a DDNS update. The addresses associated with a tunnel don't change for the life of that tunnel. It's not like you get new IPv6 addresses everytime you reconnect. The tunnels are designed so you can run services at the end of them. They are not a typical VPN service where you get a new IPv4 address from a local pool each time you connect to them. They are setup so you can delegate nameserver to serve the reverse addresses for the namespace being allocated. -- 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 Mon Jun 6 23:40:17 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 16:40:17 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> Message-ID: > On Jun 6, 2016, at 9:01 AM, Laszlo Hanyecz wrote: > > > On 2016-06-06 15:21, Tore Anderson wrote: >> >> But Netflix shouldn't have any need to ask in the first place. Their >> customers need to log in to their own personal accounts in order to >> access any content, when they do Netflix can discover their addresses. >> >> Tore > > Hey there's an idea, how about they ASK the users where they are located, instead of telling them where they are located. Presumably a user will have a new billing address when they move to a new place. That ought to be a lot more accurate than lookup based on a static map of number -> location. I don't think this is too crazy of an idea.. my car insurance company asks me what zip code I keep my cars in. Netflix could ask people what zip code they watch video from. > > -Laszlo The problem is that some users travel and they try to watch Netflix using their home account in far away lands. Now you and I may think this should be perfectly fine and I suspect Netflix would like to agree with us, but I?m sure many content providers have their crania planted so firmly up their collective recta that they believe this is akin to piracy. That?s why they don?t want to allow users who are actually in to claim to be in by using a VPN. The tactic being used for this measurement is silly to the point of absurd (why not use RTT measurements instead), but that?s what I suspect is driving this. Owen From mhuff at ox.com Tue Jun 7 00:44:17 2016 From: mhuff at ox.com (Matthew Huff) Date: Tue, 7 Jun 2016 00:44:17 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <35BB3287-7187-49AE-AA6F-5E959FA04241@delong.com> References: <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <35BB3287-7187-49AE-AA6F-5E959FA04241@delong.com> Message-ID: Search this email thread (there was a link to a document dump), or use google. Neither Netflix nor the content providers have been very shy about this. Now for the speculation part ? I think it?s possible that Netflix has gone along with this because they want to expand into countries that have restrictive policies (china, etc..) and will need to have system to either block or limit capabilities based on the geo-ip for other reasons. Just a hunch. > On Jun 6, 2016, at 7:32 PM, Owen DeLong wrote: > > While I think this may well be the reason for Netflix?s actions, do you have any evidence to back up this claim? > > Actual evidence vs. just a very good educated guess and speculation could prove very useful in this circumstance. > > Owen > >> On Jun 6, 2016, at 7:59 AM, Matthew Huff wrote: >> >> Netflix IS acting in their user's best interest. In order to provide content that the user's want, the content providers have mandated that they do their due diligence to block out of region users including VPN and open tunnel access. As Hulu and Amazon prime become more popular and their contracts with the content provides come due, they will have to also. >> >> You can argue about the content provides business model all you want, but Netflix has to do what they are doing. They aren't blocking IPv6 users, they are blocking users that are using VPNs and/or tunnels since their currently is no practical way of providing GEOIP information about that users that the content providers require. >> >> >> ---- >> Matthew Huff | 1 Manhattanville Rd >> Director of Operations | Purchase, NY 10577 >> OTA Management LLC | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-694-5669 >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Morizot >>> Sent: Monday, June 6, 2016 10:50 AM >>> To: Mark Tinka >>> Cc: NANOG list >>> Subject: Re: Netflix VPN detection - actual engineer needed >>> >>> I have Hulu Plus and Amazon Prime. The only thing I would miss from >>> Netflix >>> is their Marvel original series. And I can live with that. I can't live >>> without my IPv6 enabled home network and Internet connection since >>> that's >>> an essential part of my job. (I'm the IPv6 transition technical lead >>> for a >>> large organization.) While I actually manage my home internet gateway >>> through a linux server and have fine-grained control over the firewall >>> rules, I'm still debating whether I care enough about a handful of >>> series >>> to continue paying a company that is deliberately acting against its >>> users' >>> interests. Right now I'm leaning toward no. But I'll discuss it with my >>> wife before making a final decision. >>> >>> Scott >>> >>> On Mon, Jun 6, 2016 at 8:03 AM, Mark Tinka >>> wrote: >>> >>>> >>>> >>>> On 6/Jun/16 01:45, Damian Menscher wrote: >>>> >>>>> >>>>> Who are these non-technical Netflix users who accidentally stumbled >>> into >>>>> having a HE tunnel broker connection without their knowledge? I >>> wasn't >>>>> aware this sort of thing could happen without user consent, and >>> would >>>> like >>>>> to know if I'm wrong. Only thing I can imagine is if ISPs are >>> using HE >>>> as >>>>> a form of CGN. >>>> >>>> There are several networks around the world that rely on 6-in-4 >>> because >>>> their local provider does not offer IPv6. >>>> >>>> Mark. >>>> > From cb.list6 at gmail.com Tue Jun 7 01:28:16 2016 From: cb.list6 at gmail.com (Ca By) Date: Mon, 6 Jun 2016 18:28:16 -0700 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: On Thursday, June 2, 2016, Rubens Kuhl wrote: > On Thu, Jun 2, 2016 at 11:47 AM, Ca By > > wrote: > > > > > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > > > Wherein akamai explains a detailed study showing ipv6 is "well > > over 10%" faster than ipv4 on mobile, and they reference corroborating > > studies from Linkedin and Facebook. > > > > Says the company that consistently refused to dual-stack its customers by > default... > > > > Looks like akamai is going default ipv4 and ipv6 for new customers. https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html AWS / Cloudfront / Fastly - please have a look at how it is done. I think Cloudflare already did this. > Rubens > From chk at pobox.com Tue Jun 7 01:44:52 2016 From: chk at pobox.com (Harald Koch) Date: Mon, 6 Jun 2016 21:44:52 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> Message-ID: On 6 June 2016 at 19:40, Owen DeLong wrote: > > The problem is that some users travel and they try to watch Netflix using > their home account in far away lands. > Interestingly, audible.com (the audio book people) actually warn you about this up front - they point out on their site that many titles may not be available in foreign countries and therefore you should download your audiobooks before you leave your home country. In other words, it's not just Netflix that has this problem... -- Harald From lyndon at orthanc.ca Tue Jun 7 01:53:45 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 6 Jun 2016 18:53:45 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> ! Message-ID: <8CC4F66A-8CA2-409B-A161-BED97068AD69@orthanc.ca> > In other words, it's not just Netflix that has this problem... No, it's Netflix that has the problem. Audible actually gives a fuck about their customers. From josh at kyneticwifi.com Tue Jun 7 02:30:32 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 6 Jun 2016 21:30:32 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <8CC4F66A-8CA2-409B-A161-BED97068AD69@orthanc.ca> References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> <8CC4F66A-8CA2-409B-A161-BED97068AD69@orthanc.ca> Message-ID: Holy fuck get on your meds. As someone who actually has to deal with 3 different (4 technically) content providers, their distribution agreements and requirements for distribution allll the way through the network are absolutely asinine, but required if you want your eyeballs to receive their content. Trying to work out an actual streaming deal with them was an absolute nightmare. I can't imagine the legal and contractual obligations to event get the content, let alone distribute it in the method they have. What they are doing with content is groundbreaking considering the sources of their content, and it is a huge thorn in the side of advertising companies to say the least. I know wild speculation is what the internet does best (and the less factual information the better), but this thread has gone way off the rails for what NANOG is supposed to discuss. This is a contractual and political issue, not so much a technical one. I'm going to "mute" this thread on my end, as it's gone beyond an actual useful technical discussion and has regressed into some emotional rantfest. I would suggest the rest of NANOG do the same. ... Does anyone have any scotch left? On Jun 6, 2016 8:55 PM, "Lyndon Nerenberg" wrote: > > > In other words, it's not just Netflix that has this problem... > > No, it's Netflix that has the problem. Audible actually gives a fuck > about their customers. From jfbeam at gmail.com Tue Jun 7 02:53:58 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 06 Jun 2016 22:53:58 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160606234114.7A7904AE812D@rock.dv.isc.org> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4 B43-93A7-B1E4BD9F5996@delong.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: > What lie? Truly who is lying here. Not the end user. Not HE. There is > no requirement to report physical location. The general lie that is IP Geolocation. HE only has what I tell them (100% unverified), and what MaxMind (et.al.) tell them (~95% unverified.) They know my IPv4 endpoint address, but that doesn't give them a concrete street address -- they're guessing in exactly the same way everyone else does. And more to the point, HE doesn't share that information with anyone. (whois is populated with your account information. they don't ask where your tunnels are going.) > Are they legally required to go to this level? Possibly, but Netflix isn't going to push this. Win or Lose, they still lose distribution rights. >> Netflix (and their licensees) know people are using HE tunnels to get >> around region restrictions. Their hands are tied; they have to show >> they're doing something to limit this. > > No, they do not know. The purpose of HE tunnels is to get IPv6 service. > The fact that the endpoints are in different countries some of the time > is incidental to that. YES. THEY. DO. There have been entire COMPANIES doing this. (which is likely what sparked this level of response.) Neither HE nor Netflix are naming names, but a short walk through the more colorful parts of the internet should be enlightening. > Garbage. You have to establish the tunnel which requires registering > a account. It also requires a machine at the other end. Virtual > or physical they don't move around the world in a DDNS update. The > addresses associated with a tunnel don't change for the life of > that tunnel. True. 'tho, you can list any nonsense address you want. They do nothing to validate it. (Use my favorite BS address: Independence MT -- pop: zero. It's a dirt road across a mountain in the middle of absolutely nowhere. Google it!) The tunnel endpoint (your IPv4 address) is known only to HE, and not exposed to ANYONE. That's not going to EVER change. Once your tunnel has been setup, that address ("Client IPv4 Address") is not set in stone. People have dynamic addresses, and HE recognizes this, so there are numerous methods to change the tunnel endpoint address. (tunnel configuration page, update through an http(s) request, etc.) THUS, a tunnel can move; it can be terminated anywhere, at anytime. Not only can one update the endpoint to a different address on the same box, but to a completely different box entirely. Furthermore, one account can have several tunnels through different servers that present addresses from different regions. Where I appear to be in the world, thus, depends on which tunnel I have enabled. (and in which countries HE has prefixes, which currently appears to be 4) From blair.trosper at gmail.com Tue Jun 7 03:22:35 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 6 Jun 2016 20:22:35 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: It should be pointed out that -- the SPECIFIC accusation from Netflix -- is that people on TunnelBroker are on a VPN or proxy unblocker. The data does not bear that out. Hash tag just saying. On Mon, Jun 6, 2016 at 7:53 PM, Ricky Beam wrote: > On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: > >> What lie? Truly who is lying here. Not the end user. Not HE. There is >> no requirement to report physical location. >> > > The general lie that is IP Geolocation. HE only has what I tell them (100% > unverified), and what MaxMind (et.al.) tell them (~95% unverified.) They > know my IPv4 endpoint address, but that doesn't give them a concrete street > address -- they're guessing in exactly the same way everyone else does. And > more to the point, HE doesn't share that information with anyone. (whois is > populated with your account information. they don't ask where your tunnels > are going.) > > Are they legally required to go to this level? >> > > Possibly, but Netflix isn't going to push this. Win or Lose, they still > lose distribution rights. > > Netflix (and their licensees) know people are using HE tunnels to get >>> around region restrictions. Their hands are tied; they have to show >>> they're doing something to limit this. >>> >> >> No, they do not know. The purpose of HE tunnels is to get IPv6 service. >> The fact that the endpoints are in different countries some of the time >> is incidental to that. >> > > YES. THEY. DO. There have been entire COMPANIES doing this. (which is > likely what sparked this level of response.) Neither HE nor Netflix are > naming names, but a short walk through the more colorful parts of the > internet should be enlightening. > > Garbage. You have to establish the tunnel which requires registering >> a account. It also requires a machine at the other end. Virtual >> or physical they don't move around the world in a DDNS update. The >> addresses associated with a tunnel don't change for the life of >> that tunnel. >> > > True. 'tho, you can list any nonsense address you want. They do nothing to > validate it. (Use my favorite BS address: Independence MT -- pop: zero. > It's a dirt road across a mountain in the middle of absolutely nowhere. > Google it!) > > The tunnel endpoint (your IPv4 address) is known only to HE, and not > exposed to ANYONE. That's not going to EVER change. Once your tunnel has > been setup, that address ("Client IPv4 Address") is not set in stone. > People have dynamic addresses, and HE recognizes this, so there are > numerous methods to change the tunnel endpoint address. (tunnel > configuration page, update through an http(s) request, etc.) THUS, a tunnel > can move; it can be terminated anywhere, at anytime. Not only can one > update the endpoint to a different address on the same box, but to a > completely different box entirely. > > Furthermore, one account can have several tunnels through different > servers that present addresses from different regions. Where I appear to be > in the world, thus, depends on which tunnel I have enabled. (and in which > countries HE has prefixes, which currently appears to be 4) > From sryan at arbor.net Tue Jun 7 03:25:40 2016 From: sryan at arbor.net (Spencer Ryan) Date: Mon, 6 Jun 2016 23:25:40 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: The tunnelbroker service acts exactly like a VPN. It allows you, from any arbitrary location in the world with an IPv4 address, to bring traffic out via one of HE's 4 POP's, while completely masking your actual location. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Mon, Jun 6, 2016 at 11:22 PM, Blair Trosper wrote: > It should be pointed out that -- the SPECIFIC accusation from Netflix -- is > that people on TunnelBroker are on a VPN or proxy unblocker. > > The data does not bear that out. Hash tag just saying. > > > > On Mon, Jun 6, 2016 at 7:53 PM, Ricky Beam wrote: > > > On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: > > > >> What lie? Truly who is lying here. Not the end user. Not HE. There > is > >> no requirement to report physical location. > >> > > > > The general lie that is IP Geolocation. HE only has what I tell them > (100% > > unverified), and what MaxMind (et.al.) tell them (~95% unverified.) They > > know my IPv4 endpoint address, but that doesn't give them a concrete > street > > address -- they're guessing in exactly the same way everyone else does. > And > > more to the point, HE doesn't share that information with anyone. (whois > is > > populated with your account information. they don't ask where your > tunnels > > are going.) > > > > Are they legally required to go to this level? > >> > > > > Possibly, but Netflix isn't going to push this. Win or Lose, they still > > lose distribution rights. > > > > Netflix (and their licensees) know people are using HE tunnels to get > >>> around region restrictions. Their hands are tied; they have to show > >>> they're doing something to limit this. > >>> > >> > >> No, they do not know. The purpose of HE tunnels is to get IPv6 service. > >> The fact that the endpoints are in different countries some of the time > >> is incidental to that. > >> > > > > YES. THEY. DO. There have been entire COMPANIES doing this. (which is > > likely what sparked this level of response.) Neither HE nor Netflix are > > naming names, but a short walk through the more colorful parts of the > > internet should be enlightening. > > > > Garbage. You have to establish the tunnel which requires registering > >> a account. It also requires a machine at the other end. Virtual > >> or physical they don't move around the world in a DDNS update. The > >> addresses associated with a tunnel don't change for the life of > >> that tunnel. > >> > > > > True. 'tho, you can list any nonsense address you want. They do nothing > to > > validate it. (Use my favorite BS address: Independence MT -- pop: zero. > > It's a dirt road across a mountain in the middle of absolutely nowhere. > > Google it!) > > > > The tunnel endpoint (your IPv4 address) is known only to HE, and not > > exposed to ANYONE. That's not going to EVER change. Once your tunnel has > > been setup, that address ("Client IPv4 Address") is not set in stone. > > People have dynamic addresses, and HE recognizes this, so there are > > numerous methods to change the tunnel endpoint address. (tunnel > > configuration page, update through an http(s) request, etc.) THUS, a > tunnel > > can move; it can be terminated anywhere, at anytime. Not only can one > > update the endpoint to a different address on the same box, but to a > > completely different box entirely. > > > > Furthermore, one account can have several tunnels through different > > servers that present addresses from different regions. Where I appear to > be > > in the world, thus, depends on which tunnel I have enabled. (and in which > > countries HE has prefixes, which currently appears to be 4) > > > From blair.trosper at gmail.com Tue Jun 7 03:27:26 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 6 Jun 2016 20:27:26 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: Right, but I think we know what Netflix is implying when they say "proxy unblocker" or "VPN" -- they mean people are deliberately going around GeoIP. In this case, I don't know anyone who uses TunnelBroker that way. They're using it for V6. That is to say, everyone I know with this issue could simply solve it by disabling IPv6 (and TunnelBroker) -- meaning they're already in the US (or $region) -- and the IPv6 detection on the CDN/web is what's wrong. I think I will go further here and say that the message sort if implies the user is acting in bad faith, which may raise some animosity towards Netflix. On Mon, Jun 6, 2016 at 8:25 PM, Spencer Ryan wrote: > The tunnelbroker service acts exactly like a VPN. It allows you, from any > arbitrary location in the world with an IPv4 address, to bring traffic out > via one of HE's 4 POP's, while completely masking your actual location. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Mon, Jun 6, 2016 at 11:22 PM, Blair Trosper > wrote: > >> It should be pointed out that -- the SPECIFIC accusation from Netflix -- >> is >> that people on TunnelBroker are on a VPN or proxy unblocker. >> >> The data does not bear that out. Hash tag just saying. >> >> >> >> On Mon, Jun 6, 2016 at 7:53 PM, Ricky Beam wrote: >> >> > On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: >> > >> >> What lie? Truly who is lying here. Not the end user. Not HE. There >> is >> >> no requirement to report physical location. >> >> >> > >> > The general lie that is IP Geolocation. HE only has what I tell them >> (100% >> > unverified), and what MaxMind (et.al.) tell them (~95% unverified.) >> They >> > know my IPv4 endpoint address, but that doesn't give them a concrete >> street >> > address -- they're guessing in exactly the same way everyone else does. >> And >> > more to the point, HE doesn't share that information with anyone. >> (whois is >> > populated with your account information. they don't ask where your >> tunnels >> > are going.) >> > >> > Are they legally required to go to this level? >> >> >> > >> > Possibly, but Netflix isn't going to push this. Win or Lose, they still >> > lose distribution rights. >> > >> > Netflix (and their licensees) know people are using HE tunnels to get >> >>> around region restrictions. Their hands are tied; they have to show >> >>> they're doing something to limit this. >> >>> >> >> >> >> No, they do not know. The purpose of HE tunnels is to get IPv6 >> service. >> >> The fact that the endpoints are in different countries some of the time >> >> is incidental to that. >> >> >> > >> > YES. THEY. DO. There have been entire COMPANIES doing this. (which is >> > likely what sparked this level of response.) Neither HE nor Netflix are >> > naming names, but a short walk through the more colorful parts of the >> > internet should be enlightening. >> > >> > Garbage. You have to establish the tunnel which requires registering >> >> a account. It also requires a machine at the other end. Virtual >> >> or physical they don't move around the world in a DDNS update. The >> >> addresses associated with a tunnel don't change for the life of >> >> that tunnel. >> >> >> > >> > True. 'tho, you can list any nonsense address you want. They do nothing >> to >> > validate it. (Use my favorite BS address: Independence MT -- pop: zero. >> > It's a dirt road across a mountain in the middle of absolutely nowhere. >> > Google it!) >> > >> > The tunnel endpoint (your IPv4 address) is known only to HE, and not >> > exposed to ANYONE. That's not going to EVER change. Once your tunnel has >> > been setup, that address ("Client IPv4 Address") is not set in stone. >> > People have dynamic addresses, and HE recognizes this, so there are >> > numerous methods to change the tunnel endpoint address. (tunnel >> > configuration page, update through an http(s) request, etc.) THUS, a >> tunnel >> > can move; it can be terminated anywhere, at anytime. Not only can one >> > update the endpoint to a different address on the same box, but to a >> > completely different box entirely. >> > >> > Furthermore, one account can have several tunnels through different >> > servers that present addresses from different regions. Where I appear >> to be >> > in the world, thus, depends on which tunnel I have enabled. (and in >> which >> > countries HE has prefixes, which currently appears to be 4) >> > >> > > From matthew at matthew.at Tue Jun 7 03:32:44 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 07 Jun 2016 03:32:44 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Message-ID: Yes. Just like any Internet connection, anywhere. The official place where my ISP provides my service is 14 miles from my house, and I use microwave between the two. Some of the things that are on that same port are 50 miles in the opposite direction. With a satellite uplink, I could make that anywhere in about 1/3rd of the earth. When I travel, my IPSEC VPN extends that port to anywhere in the world. And? Matthew Kaufman ------ Original Message ------ From: "Spencer Ryan" To: "Blair Trosper" Cc: "nanog at nanog.org" Sent: 6/6/2016 8:25:40 PM Subject: Re: Netflix VPN detection - actual engineer needed >The tunnelbroker service acts exactly like a VPN. It allows you, from >any >arbitrary location in the world with an IPv4 address, to bring traffic >out >via one of HE's 4 POP's, while completely masking your actual location. > From nanog-post at rsuc.gweep.net Mon Jun 6 22:03:38 2016 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 6 Jun 2016 18:03:38 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160606155418.GD35417@22.rev.meerval.net> References: <20160606155418.GD35417@22.rev.meerval.net> Message-ID: <20160606220338.GA80412@gweep.net> On Mon, Jun 06, 2016 at 05:54:18PM +0200, Job Snijders wrote: > On Mon, Jun 06, 2016 at 11:41:52AM +0000, Sriram, Kotikalapudi (Fed) wrote: > > I am a co-author on a route-leak detection/mitigation/prevention draft > > in the IDR WG in the IETF: > > https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 > > > > Question: Are there other means of conveying this information > > in common use today (i.e. for prevention of route leaks)? [snip] > > For instance AT&T and NTT agreed (through email) that there should be no > intermediate networks between 2914 & 7018, therefore NTT blocks > announcements that match as-path-regexp '_7018_' on any and all eBGP > sessions, except the direct sessions with 7018. NTT calls this concept > "peerlocking". > > I'll cover this approach at the upcoming NANOG meeting in Chicago: > https://www.nanog.org/meetings/abstract?id=2860 Dropping unexpected AS vectors was frequently used in the 1990s by folks, especially in the context of seeking to ensure traffic intended for direct/private interconnections stayed on them. I know some folks would also just filter "big networks" (to avoid that marketing term) from other peers to sidestep the impact of leaks. It doesn't fit for all peers/networks (eg content which will seek alternate paths around congestion), but if you can fold it into your automation it is helpful. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From matt at conundrum.com Mon Jun 6 17:17:39 2016 From: matt at conundrum.com (Matthew Pounsett) Date: Mon, 6 Jun 2016 10:17:39 -0700 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: On 6 June 2016 at 07:18, Manuel Mar?n wrote: > Dear Nanog community > > We are currently planning to upgrade our monitoring system (Opsview) due to > scalability issues and I was wondering what do you recommend for monitoring > 5000 hosts and 35000 services. We would like to use a monitoring system > that is compatible with the nagios plugin format, however we are not sure > if systems like Icinga/Shinken/Op5 are the way to go. > > Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? > Would you recommend commercial systems like Sevone, Zabbix, etc instead of > open source ones? > Although I haven't ever scaled it that high, I've had a lot of luck using Gearman (mod_gearman) to make Nagios horizontally scalable. It allows you to use Nagios itself only as a scheduler and reporting UI, and offload all of the actual probing to other servers. There'll be a theoretical limit to the amount of scale you get get out of that due to relying on a single Nagios instance to schedule checks and receive reports of success, but I imagine it's much higher than your current requirements. From mvm at transtelco.net Mon Jun 6 20:59:51 2016 From: mvm at transtelco.net (Maximino Velazquez) Date: Mon, 6 Jun 2016 14:59:51 -0600 Subject: syslog server Message-ID: Hi nanog community I need help !! What is the best syslog server (opensource)? Thanks for your help Regards. -- Max Velazquez | From trelane at trelane.net Tue Jun 7 05:11:30 2016 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 7 Jun 2016 01:11:30 -0400 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: I once worked for Zenoss and still suggest them. Zenoss supports NAGIOS plugins, and my $DAYJOB is at a Zenoss Partner who can help you achieve your goals. If you need some help with Zenoss feel free to contact me off list. Andrew On Monday, June 6, 2016, Manuel Mar?n wrote: > Dear Nanog community > > We are currently planning to upgrade our monitoring system (Opsview) due to > scalability issues and I was wondering what do you recommend for monitoring > 5000 hosts and 35000 services. We would like to use a monitoring system > that is compatible with the nagios plugin format, however we are not sure > if systems like Icinga/Shinken/Op5 are the way to go. > > Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? > Would you recommend commercial systems like Sevone, Zabbix, etc instead of > open source ones? > > Your input is really appreciated it > > Thank you and have a great day > > Regards > From owen at delong.com Tue Jun 7 05:53:15 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 22:53:15 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> ! Message-ID: > On Jun 6, 2016, at 6:44 PM, Harald Koch wrote: > > On 6 June 2016 at 19:40, Owen DeLong wrote: > >> >> The problem is that some users travel and they try to watch Netflix using >> their home account in far away lands. >> > > Interestingly, audible.com (the audio book people) actually warn you about > this up front - they point out on their site that many titles may not be > available in foreign countries and therefore you should download your > audiobooks before you leave your home country. > > In other words, it's not just Netflix that has this problem? > Yes and no? Audible at least let?s you download them before you leave. Netflix, not so much? Owen > -- > Harald From owen at delong.com Tue Jun 7 05:59:34 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 22:59:34 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: <0B78EBED-C5F9-46DC-B87C-017F79E15B70@delong.com> I believe there are a lot more than 4. Owen > On Jun 6, 2016, at 8:25 PM, Spencer Ryan wrote: > > The tunnelbroker service acts exactly like a VPN. It allows you, from any > arbitrary location in the world with an IPv4 address, to bring traffic out > via one of HE's 4 POP's, while completely masking your actual location. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Mon, Jun 6, 2016 at 11:22 PM, Blair Trosper > wrote: > >> It should be pointed out that -- the SPECIFIC accusation from Netflix -- is >> that people on TunnelBroker are on a VPN or proxy unblocker. >> >> The data does not bear that out. Hash tag just saying. >> >> >> >> On Mon, Jun 6, 2016 at 7:53 PM, Ricky Beam wrote: >> >>> On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: >>> >>>> What lie? Truly who is lying here. Not the end user. Not HE. There >> is >>>> no requirement to report physical location. >>>> >>> >>> The general lie that is IP Geolocation. HE only has what I tell them >> (100% >>> unverified), and what MaxMind (et.al.) tell them (~95% unverified.) They >>> know my IPv4 endpoint address, but that doesn't give them a concrete >> street >>> address -- they're guessing in exactly the same way everyone else does. >> And >>> more to the point, HE doesn't share that information with anyone. (whois >> is >>> populated with your account information. they don't ask where your >> tunnels >>> are going.) >>> >>> Are they legally required to go to this level? >>>> >>> >>> Possibly, but Netflix isn't going to push this. Win or Lose, they still >>> lose distribution rights. >>> >>> Netflix (and their licensees) know people are using HE tunnels to get >>>>> around region restrictions. Their hands are tied; they have to show >>>>> they're doing something to limit this. >>>>> >>>> >>>> No, they do not know. The purpose of HE tunnels is to get IPv6 service. >>>> The fact that the endpoints are in different countries some of the time >>>> is incidental to that. >>>> >>> >>> YES. THEY. DO. There have been entire COMPANIES doing this. (which is >>> likely what sparked this level of response.) Neither HE nor Netflix are >>> naming names, but a short walk through the more colorful parts of the >>> internet should be enlightening. >>> >>> Garbage. You have to establish the tunnel which requires registering >>>> a account. It also requires a machine at the other end. Virtual >>>> or physical they don't move around the world in a DDNS update. The >>>> addresses associated with a tunnel don't change for the life of >>>> that tunnel. >>>> >>> >>> True. 'tho, you can list any nonsense address you want. They do nothing >> to >>> validate it. (Use my favorite BS address: Independence MT -- pop: zero. >>> It's a dirt road across a mountain in the middle of absolutely nowhere. >>> Google it!) >>> >>> The tunnel endpoint (your IPv4 address) is known only to HE, and not >>> exposed to ANYONE. That's not going to EVER change. Once your tunnel has >>> been setup, that address ("Client IPv4 Address") is not set in stone. >>> People have dynamic addresses, and HE recognizes this, so there are >>> numerous methods to change the tunnel endpoint address. (tunnel >>> configuration page, update through an http(s) request, etc.) THUS, a >> tunnel >>> can move; it can be terminated anywhere, at anytime. Not only can one >>> update the endpoint to a different address on the same box, but to a >>> completely different box entirely. >>> >>> Furthermore, one account can have several tunnels through different >>> servers that present addresses from different regions. Where I appear to >> be >>> in the world, thus, depends on which tunnel I have enabled. (and in which >>> countries HE has prefixes, which currently appears to be 4) >>> >> From owen at delong.com Tue Jun 7 06:00:43 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2016 23:00:43 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: I?m sorry to say, Blair, that there are, in fact, many who do use HE tunnels for Geo Fence evasion. Sure, it doesn?t represent even a significant fraction of tunnel users, but they exist and they?ve been vocal, thus spoiling it for the rest of us. Owen > On Jun 6, 2016, at 8:27 PM, Blair Trosper wrote: > > Right, but I think we know what Netflix is implying when they say "proxy > unblocker" or "VPN" -- they mean people are deliberately going around > GeoIP. In this case, I don't know anyone who uses TunnelBroker that way. > They're using it for V6. That is to say, everyone I know with this issue > could simply solve it by disabling IPv6 (and TunnelBroker) -- meaning > they're already in the US (or $region) -- and the IPv6 detection on the > CDN/web is what's wrong. > > I think I will go further here and say that the message sort if implies the > user is acting in bad faith, which may raise some animosity towards Netflix. > > On Mon, Jun 6, 2016 at 8:25 PM, Spencer Ryan wrote: > >> The tunnelbroker service acts exactly like a VPN. It allows you, from any >> arbitrary location in the world with an IPv4 address, to bring traffic out >> via one of HE's 4 POP's, while completely masking your actual location. >> >> >> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net >> *Arbor Networks* >> +1.734.794.5033 (d) | +1.734.846.2053 (m) >> www.arbornetworks.com >> >> On Mon, Jun 6, 2016 at 11:22 PM, Blair Trosper >> wrote: >> >>> It should be pointed out that -- the SPECIFIC accusation from Netflix -- >>> is >>> that people on TunnelBroker are on a VPN or proxy unblocker. >>> >>> The data does not bear that out. Hash tag just saying. >>> >>> >>> >>> On Mon, Jun 6, 2016 at 7:53 PM, Ricky Beam wrote: >>> >>>> On Mon, 06 Jun 2016 19:41:14 -0400, Mark Andrews wrote: >>>> >>>>> What lie? Truly who is lying here. Not the end user. Not HE. There >>> is >>>>> no requirement to report physical location. >>>>> >>>> >>>> The general lie that is IP Geolocation. HE only has what I tell them >>> (100% >>>> unverified), and what MaxMind (et.al.) tell them (~95% unverified.) >>> They >>>> know my IPv4 endpoint address, but that doesn't give them a concrete >>> street >>>> address -- they're guessing in exactly the same way everyone else does. >>> And >>>> more to the point, HE doesn't share that information with anyone. >>> (whois is >>>> populated with your account information. they don't ask where your >>> tunnels >>>> are going.) >>>> >>>> Are they legally required to go to this level? >>>>> >>>> >>>> Possibly, but Netflix isn't going to push this. Win or Lose, they still >>>> lose distribution rights. >>>> >>>> Netflix (and their licensees) know people are using HE tunnels to get >>>>>> around region restrictions. Their hands are tied; they have to show >>>>>> they're doing something to limit this. >>>>>> >>>>> >>>>> No, they do not know. The purpose of HE tunnels is to get IPv6 >>> service. >>>>> The fact that the endpoints are in different countries some of the time >>>>> is incidental to that. >>>>> >>>> >>>> YES. THEY. DO. There have been entire COMPANIES doing this. (which is >>>> likely what sparked this level of response.) Neither HE nor Netflix are >>>> naming names, but a short walk through the more colorful parts of the >>>> internet should be enlightening. >>>> >>>> Garbage. You have to establish the tunnel which requires registering >>>>> a account. It also requires a machine at the other end. Virtual >>>>> or physical they don't move around the world in a DDNS update. The >>>>> addresses associated with a tunnel don't change for the life of >>>>> that tunnel. >>>>> >>>> >>>> True. 'tho, you can list any nonsense address you want. They do nothing >>> to >>>> validate it. (Use my favorite BS address: Independence MT -- pop: zero. >>>> It's a dirt road across a mountain in the middle of absolutely nowhere. >>>> Google it!) >>>> >>>> The tunnel endpoint (your IPv4 address) is known only to HE, and not >>>> exposed to ANYONE. That's not going to EVER change. Once your tunnel has >>>> been setup, that address ("Client IPv4 Address") is not set in stone. >>>> People have dynamic addresses, and HE recognizes this, so there are >>>> numerous methods to change the tunnel endpoint address. (tunnel >>>> configuration page, update through an http(s) request, etc.) THUS, a >>> tunnel >>>> can move; it can be terminated anywhere, at anytime. Not only can one >>>> update the endpoint to a different address on the same box, but to a >>>> completely different box entirely. >>>> >>>> Furthermore, one account can have several tunnels through different >>>> servers that present addresses from different regions. Where I appear >>> to be >>>> in the world, thus, depends on which tunnel I have enabled. (and in >>> which >>>> countries HE has prefixes, which currently appears to be 4) >>>> >>> >> >> From Valdis.Kletnieks at vt.edu Tue Jun 7 06:25:12 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Jun 2016 02:25:12 -0400 Subject: syslog server In-Reply-To: References: Message-ID: <90451.1465280712@turing-police.cc.vt.edu> On Mon, 06 Jun 2016 14:59:51 -0600, Maximino Velazquez said: > What is the best syslog server (opensource)? Step 0: Define what "best" means in your environment. What features do you need? Routing to a central aggregation server over TLS? Powerful regex-based routing? Ingestion into a database (a la splunk or Elk) for data mining? Ability to deal with insanely high message rates? Other must-have or don't-care features? License pricing? Vendor support? Step 1: After figuring out what you need, make a matrix of the available options and how well they fit. (We have in production syslog-ng, rsyslog, splunk, Elk, and probably a few others I've forgotten, for different purposes....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mark.tinka at seacom.mu Tue Jun 7 06:35:53 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 7 Jun 2016 08:35:53 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160606155418.GD35417@22.rev.meerval.net> References: <20160606155418.GD35417@22.rev.meerval.net> Message-ID: <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> On 6/Jun/16 17:54, Job Snijders wrote: > There is the "human network" approach, where operators share information > with each other which be used to generate config to help block > "unlikely" announcements from eBGP neighbors. > > For instance AT&T and NTT agreed (through email) that there should be no > intermediate networks between 2914 & 7018, therefore NTT blocks > announcements that match as-path-regexp '_7018_' on any and all eBGP > sessions, except the direct sessions with 7018. NTT calls this concept > "peerlocking". I suppose if one is performing prefix- and ASN-based filtering, then you "should" not learn peer paths via customers. If you augment that with AS_PATH-based filtering, you "will not" learn peer paths via customers. One thing we do to reduce opportunistically hazardous vectors is to not learn customer paths via peers. Mark. From mark.tinka at seacom.mu Tue Jun 7 06:46:14 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 7 Jun 2016 08:46:14 +0200 Subject: Traffic engineering and peering for CDNs In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> <125980230.9402.1465235590241.JavaMail.mhammett@ThunderFuck> Message-ID: <276869f3-d10a-8b44-795c-cb6673c7082f@seacom.mu> On 6/Jun/16 20:03, Tom Smyth wrote: > as far as im aware ... a friend of mine on INEX in Ireland said most cdns > use source ip of the DNS requests to determine which network to direct them > to ... so if you use you have your own resolver on an ip address in your > network range cdns can accurately determine what network the request is > comming from and determine what ip address / what network that the cdn has > nearest to your network... > > ff you use 3rd party dns servers for your clients... you may not get an > optimal ip answer for your dns queries from the CDNS involved Some CDN's use DNS (in addition to latency, congestion levels, busy state, e.t.c.). Others use Anycast routing, which I tend to prefer. The problem is the latter run a network while the former may typically not. Mark. From mark.tinka at seacom.mu Tue Jun 7 06:48:21 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 7 Jun 2016 08:48:21 +0200 Subject: IPv6 is better than ipv4 In-Reply-To: References: Message-ID: <5c4df7c2-accb-99cc-7c58-7a6dc1f83a9b@seacom.mu> On 7/Jun/16 03:28, Ca By wrote: > > AWS / Cloudfront / Fastly - please have a look at how it is done. I think > Cloudflare already did this. CloudFlare already do. Mark. From guillaume at ironie.org Tue Jun 7 06:52:36 2016 From: guillaume at ironie.org (Guillaume Tournat) Date: Tue, 7 Jun 2016 08:52:36 +0200 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: <8AE1A57C-34B0-4AFB-9CFD-121ABD9CAB81@ironie.org> Things to notice, as I prefer Zabbix over nagios (real database related, more functionalities) : - Zabbix actually is open source. You can buy support from them or from partners if you want - Zabbix can be distributed through central/proxies architecture to scale - nagios plugins can be adapted for Zabbix, as the later only needs numerical value (no status or text) > Le 7 juin 2016 ? 07:11, Andrew Kirch a ?crit : > > I once worked for Zenoss and still suggest them. Zenoss supports NAGIOS > plugins, and my $DAYJOB is at a Zenoss Partner who can help you achieve > your goals. If you need some help with Zenoss feel free to contact me off > list. > > Andrew > >> On Monday, June 6, 2016, Manuel Mar?n wrote: >> >> Dear Nanog community >> >> We are currently planning to upgrade our monitoring system (Opsview) due to >> scalability issues and I was wondering what do you recommend for monitoring >> 5000 hosts and 35000 services. We would like to use a monitoring system >> that is compatible with the nagios plugin format, however we are not sure >> if systems like Icinga/Shinken/Op5 are the way to go. >> >> Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? >> Would you recommend commercial systems like Sevone, Zabbix, etc instead of >> open source ones? >> >> Your input is really appreciated it >> >> Thank you and have a great day >> >> Regards >> From dhubbard at dino.hostasaurus.com Tue Jun 7 07:02:04 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 7 Jun 2016 07:02:04 +0000 Subject: syslog server In-Reply-To: References: Message-ID: <7515284E-BE03-49CD-AC75-ED9A59C11F93@dino.hostasaurus.com> https://www.graylog.org/ On 6/6/16, 4:59 PM, "NANOG on behalf of Maximino Velazquez" wrote: >Hi nanog community > >I need help !! > >What is the best syslog server (opensource)? > >Thanks for your help > >Regards. > >-- > > > >Max Velazquez | From shopik+lists at nvcube.net Tue Jun 7 07:10:54 2016 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Tue, 7 Jun 2016 10:10:54 +0300 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606110813.255c66d! a@jpeach-desktop.anbg.mssm.edu> <1465235902.2073976.629540273.66BE1887@webmail.messagingengine.com> <1465236980.2077465.629558809.59E26953@webmail.messagingengine.com> <72971.1465242254@turing-police.cc.vt.edu> Message-ID: <9bb15a9d-e80b-f9f1-2263-2627fd573869@nvcube.net> RDAP is same across RIRs. Yes old REST API was PITA On 07/06/2016 02:08, Ricky Beam wrote: > Yes, ARIN and RIPE have REST APIs, but they're completely different > interfaces with different schemas (and different capabilities.) I have > independent applications for talking to each. And those are the only two > I'm going to bother with. From mikael.falkvidd at op5.com Tue Jun 7 07:42:12 2016 From: mikael.falkvidd at op5.com (Mikael Falkvidd) Date: Tue, 7 Jun 2016 09:42:12 +0200 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: > > On Monday, June 6, 2016, Manuel Mar?n wrote: > > > Dear Nanog community > > > > We are currently planning to upgrade our monitoring system (Opsview) due > to > > scalability issues and I was wondering what do you recommend for > monitoring > > 5000 hosts and 35000 services. We would like to use a monitoring system > > that is compatible with the nagios plugin format, however we are not sure > > if systems like Icinga/Shinken/Op5 are the way to go. > > > > Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? > > Would you recommend commercial systems like Sevone, Zabbix, etc instead > of > > open source ones? > We (op5) have customers running > 50,000 hosts and > 300,000 services. So 5,000 hosts is generally not a problem. As mentioned by Jeff, the forking model *can* become a problem. Small binaries that don't load a lot of libraries fork pretty fast. A test we made some time ago showed a 15 minute load peak at 3.89 (on 24 cores/hyperthreads) when checking 100,000 services every 5 minutes. Check latencies were 0.8 seconds max and 0.002 seconds avg. Average cpu load was 15%. Specs for the machine used: Dell PowerEdge R620 2x Intel Xeon E5-2620 24 GB ram Dell PERC H710 hardware RAID card RAID10 on 4x300GB 15kRPM SAS drives So a single (now almost vintage) server can handle 300 plugin executions per second without breaking a sweat. Scaling up is definitely a possibility, but scaling out (using mod gearman, mk or merlin, all open source) is available as well. Complex plugins, for example check_vmware_api which loads the large VMware perl SDK can get you in trouble though. I suggest you run a test with the plugin mix you are planning to use. If scaling out is not an option, and you want to stay in the nagios/naemon world, a custom worker can be developed to get rid of the loading overhead. Documentation is available at http://www.naemon.org/documentation/developer/workers.html Full disclosure: I work as development team lead at op5 best regards Mikael Falkvidd From diotonante at gmail.com Tue Jun 7 11:23:53 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 7 Jun 2016 13:23:53 +0200 Subject: Netflix banning HE tunnels Message-ID: Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I can't use it if I don't disable the HE tunnel, which is the only way for me to have IPv6 at the moment. But the fun part has been Netflix tech support: "Oh I see, yeah we have been receiving reports of some other members with ipv6 having this issues, at the moment Netflix is not really designed to work with ipv6 connections, in this case I can recommend you two things, one is to turn off the ipv6 and the other one will be to contact directly with Hurricane Electric, there are some customers that were able to use Netflix with an ipv6 under some specific settings set by Hurricane Electric." I don't obviously expect HE to fix it, I don't pay for shit, it's a free service, why should they? But it's fun to know that " Netflix is not really designed to work with ipv6 connections ". Who did it say on this ML that the best way to solve these issues is Netflix tech support? :) Ciao, Davide Davini From Curtis.Starnes at granburyisd.org Tue Jun 7 11:26:36 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 7 Jun 2016 11:26:36 +0000 Subject: syslog server In-Reply-To: <7515284E-BE03-49CD-AC75-ED9A59C11F93@dino.hostasaurus.com> References: <7515284E-BE03-49CD-AC75-ED9A59C11F93@dino.hostasaurus.com> Message-ID: +1 on Graylog -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Tuesday, June 07, 2016 2:02 AM To: Maximino Velazquez ; nanog at nanog.org Subject: Re: syslog server https://www.graylog.org/ On 6/6/16, 4:59 PM, "NANOG on behalf of Maximino Velazquez" wrote: >Hi nanog community > >I need help !! > >What is the best syslog server (opensource)? > >Thanks for your help > >Regards. > >-- > > > >Max Velazquez | From jcurran at arin.net Tue Jun 7 11:31:07 2016 From: jcurran at arin.net (John Curran) Date: Tue, 7 Jun 2016 11:31:07 +0000 Subject: IPv6 is better than ipv4 In-Reply-To: <815775958.4219.1464889122318.JavaMail.mhammett@ThunderFuck> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <815775958.4219.1464889122318.JavaMail.mhammett@ThunderFuck> Message-ID: <71F70DBE-E378-418A-9A62-F7BA307F9F79@arin.net> On Jun 2, 2016, at 1:38 PM, Mike Hammett wrote: > > I would be surprised if more than 10% - 20% of networks have received effective marketing on IPv6. > > Look at how many network operators that don't "get" basic network security alerts like "There is a long since patched vulnerability being actively exploited on the Internet right now. Your equipment will reset to default in 18.5 hours of infection. Please patch now." Equipment resetting to default is a metric crap ton more serious than IPv6 implementation and people don't take that seriously. > > Think outside of the NANOG bubble. I hesitated to reply on this thread, but want to reiterate the point Mike?s makes above, as he is spot on - There is a large number of Internet service providers who: - Don?t attend NANOG, or follow this mailing list - Don?t attend ARIN, or follow its mailing lists - Don?t have sales reps for the large-box vendors stopping by every quarter to tell them about the latest trend or gadget to buy? - Either run their Internet services in addition to many other tasks (e.g. small MSO?s handling cable channels, telephone services, and everything else), or - Operate their Internet services on behalf of a small community (community ISPs, wireless ISPs in rural areas) on shoestring or even completely donated budgets. These folks are your peers, but not literally, as they are often downstream of a single ISP providing service to a small customer base with not much growth. For them, IPv6 reality is only just beginning, as each now comes into ARIN (usually several years since their last time in) and gets told ?Yes, the regional IPv4 free pool really has run out - we simply don?t have any IPv4 blocks to issue to you.? Sometimes they?ve heard of IPv6, but having heard about it for more than a decade before it was actually needed, they just figured it was a failed technology waiting to die? (None of this was helped by the fact that the IPv6 marketing also occurred without any meaningful technologies or strategy to enable transition - these only appeared after the fact in the last five years when several operators realized that they had to actually make IPv6 deployable in the real world?) These smaller ISPs who are just now newly discovering IPv6 are not ?ignorant? - they just haven?t had time or resources to worry about a problem that always seemed theoretical until today. Some go to the transfer market, some go to the wait list, and some suddenly decide to learn about IPv6 in a hurry - some do a combination of the above. What these organizations need is realistic pointers to information (e.g. NANOG archives, IPv6 World Congress info, ARIN?s IPv6 wiki) that lets them understand exactly what and how others are handling this transition. We do need to do outreach to them so that they know they?ve got something real to deal with, and to start learning - what isn?t particularly helpful is pure marketing to the effect that ?delivering Internet services over IPv6 is easy? or ?you don?t need IPv6 at all?? /John From swmike at swm.pp.se Tue Jun 7 11:51:56 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Jun 2016 13:51:56 +0200 (CEST) Subject: IPv6 is better than ipv4 In-Reply-To: <71F70DBE-E378-418A-9A62-F7BA307F9F79@arin.net> References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <815775958.4219.1464889122318.JavaMail.mhammett@ThunderFuck> <71F70DBE-E378-418A-9A62-F7BA307F9F79@arin.net> Message-ID: On Tue, 7 Jun 2016, John Curran wrote: > There is a large number of Internet service providers who: Not only ISPs, but also content: https://tech.slashdot.org/story/16/06/05/1744246/distrowatch-finally-adds-support-for-ipv6 "When asked why DistroWatch enabled IPv6 access to their server at this time, Smith answered: "Partly it was an experiment to see how much interest there was in IPv6. Partly it was because it is a little embarrassing (in 2016) to have a technology focused website that is not making use of IPv6." " Slashdot, Github etc, still no IPv6 though. I talked to LWN.net (who does have IPv6) about if they could write an article about IPv6. I offered to contribute text. We'll see how that goes. Linux Foundation seems to have some IPv6 related presentations etc. Perhaps it's time to re-do this and say "now we're not only talking about IPv6, it's actually happening and there are hundreds of millions of devices out there now with IPv6 access". I think a lot of people haven't heard of this. They've heard of IPv6 but as you say, they still think it's in the future. It would be helpful if they would get an update that this is happening NOW, and everything is ready to go. -- Mikael Abrahamsson email: swmike at swm.pp.se From Brent.Crier at nsight.com Tue Jun 7 12:32:50 2016 From: Brent.Crier at nsight.com (Crier, Brent) Date: Tue, 7 Jun 2016 12:32:50 +0000 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: We use Zabbix here pretty heavily. Monitoring roughly 10,000 hosts 13,000 interfaces and a mirage of services. -Brent > On Jun 7, 2016, at 2:42 AM, Mikael Falkvidd wrote: > >> >> On Monday, June 6, 2016, Manuel Mar?n wrote: >> >>> Dear Nanog community >>> >>> We are currently planning to upgrade our monitoring system (Opsview) due >> to >>> scalability issues and I was wondering what do you recommend for >> monitoring >>> 5000 hosts and 35000 services. We would like to use a monitoring system >>> that is compatible with the nagios plugin format, however we are not sure >>> if systems like Icinga/Shinken/Op5 are the way to go. >>> >>> Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? >>> Would you recommend commercial systems like Sevone, Zabbix, etc instead >> of >>> open source ones? >> > > We (op5) have customers running > 50,000 hosts and > 300,000 services. So > 5,000 hosts is generally not a problem. > > As mentioned by Jeff, the forking model *can* become a problem. Small > binaries > that don't load a lot of libraries fork pretty fast. A test we made some > time ago > showed a 15 minute load peak at 3.89 (on 24 cores/hyperthreads) when > checking > 100,000 services every 5 minutes. Check latencies were 0.8 seconds max and > 0.002 seconds avg. Average cpu load was 15%. > > Specs for the machine used: > Dell PowerEdge R620 > 2x Intel Xeon E5-2620 > 24 GB ram > Dell PERC H710 hardware RAID card > RAID10 on 4x300GB 15kRPM SAS drives > > So a single (now almost vintage) server can handle 300 plugin executions per > second without breaking a sweat. Scaling up is definitely a possibility, but > scaling out (using mod gearman, mk or merlin, all open source) is available > as > well. > > Complex plugins, for example check_vmware_api which loads the large VMware > perl SDK can get you in trouble though. I suggest you run a test with the > plugin > mix you are planning to use. > > If scaling out is not an option, and you want to stay in the nagios/naemon > world, > a custom worker can be developed to get rid of the loading overhead. > Documentation is available at > http://www.naemon.org/documentation/developer/workers.html > > Full disclosure: I work as development team lead at op5 > > best regards > Mikael Falkvidd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ahebert at pubnix.net Tue Jun 7 12:36:45 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 7 Jun 2016 08:36:45 -0400 Subject: syslog server In-Reply-To: References: <7515284E-BE03-49CD-AC75-ED9A59C11F93@dino.hostasaurus.com> Message-ID: <2539059a-9157-40c4-cccb-39031d62d9a7@pubnix.net> Well, I'll say an ELK stack, but seeing the original question... I got to ponder on the capacity of the OP. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 06/07/16 07:26, STARNES, CURTIS wrote: > +1 on Graylog > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard > Sent: Tuesday, June 07, 2016 2:02 AM > To: Maximino Velazquez ; nanog at nanog.org > Subject: Re: syslog server > > https://www.graylog.org/ > > On 6/6/16, 4:59 PM, "NANOG on behalf of Maximino Velazquez" wrote: > >> Hi nanog community >> >> I need help !! >> >> What is the best syslog server (opensource)? >> >> Thanks for your help >> >> Regards. >> >> -- >> >> >> >> Max Velazquez | From nanog at ics-il.net Tue Jun 7 12:49:27 2016 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 7 Jun 2016 07:49:27 -0500 (CDT) Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: <586047483.10345.1465303766210.JavaMail.mhammett@ThunderFuck> I'm not at that scale, but I've seen some fairly impressive performance searching through a friend's NetXMS system with a couple years of verbose syslog and monitoring to go through. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Manuel Mar?n" To: "NANOG" Sent: Monday, June 6, 2016 9:18:07 AM Subject: Monitoring system recommendation Dear Nanog community We are currently planning to upgrade our monitoring system (Opsview) due to scalability issues and I was wondering what do you recommend for monitoring 5000 hosts and 35000 services. We would like to use a monitoring system that is compatible with the nagios plugin format, however we are not sure if systems like Icinga/Shinken/Op5 are the way to go. Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? Would you recommend commercial systems like Sevone, Zabbix, etc instead of open source ones? Your input is really appreciated it Thank you and have a great day Regards From diotonante at gmail.com Tue Jun 7 12:55:29 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 7 Jun 2016 14:55:29 +0200 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <9dfdfec2-a4b9-8802-acf4-f8e8dcd26e6c@gmail.com> On 07/06/2016 13:23, Davide Davini wrote: > Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I > can't use it if I don't disable the HE tunnel, which is the only way for > me to have IPv6 at the moment. Apologies I saw the huge thread only after I posted. Ciao, Davide Davini From feld at feld.me Tue Jun 7 13:13:25 2016 From: feld at feld.me (Mark Felder) Date: Tue, 7 Jun 2016 08:13:25 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> Message-ID: <4F8A70C8-2140-49E4-A36B-83EDE0A11422@feld.me> > On Jun 6, 2016, at 18:12, Baldur Norddahl wrote: > > It is a bit surprising that your browser would choose the ipv6 path via > tunnel over the more direct ipv4 path. Anyway, you could blackhole the > Netflix ipv6 prefix to force the situation. > On modern Apple devices IPv6 is chosen 99% of the time now. https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html -- Mark Felder feld at feld.me From feld at feld.me Tue Jun 7 13:21:16 2016 From: feld at feld.me (Mark Felder) Date: Tue, 7 Jun 2016 08:21:16 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> Message-ID: <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> > On Jun 6, 2016, at 22:25, Spencer Ryan wrote: > > The tunnelbroker service acts exactly like a VPN. It allows you, from any > arbitrary location in the world with an IPv4 address, to bring traffic out > via one of HE's 4 POP's, while completely masking your actual location. > Perhaps Netflix should automatically block any connection that's not from a known residential ISP or mobile ISP as anything else could be a server someone is proxying through. It's very easy to get these subnets -- the spam filtering folks have these subnets well documented. /s -- Mark Felder feld at feld.me From morrowc.lists at gmail.com Tue Jun 7 13:38:46 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Jun 2016 09:38:46 -0400 Subject: IPv6 is better than ipv4 In-Reply-To: References: <431949A3-E0C6-4641-96F8-409A6BD06269@hammerfiber.com> <138390613.4128.1464887876094.JavaMail.mhammett@ThunderFuck> <815775958.4219.1464889122318.JavaMail.mhammett@ThunderFuck> <71F70DBE-E378-418A-9A62-F7BA307F9F79@arin.net> Message-ID: On Tue, Jun 7, 2016 at 7:51 AM, Mikael Abrahamsson wrote: > Slashdot, Github etc, still no IPv6 though. ?oddly github has ipv6 being announced from their ASN: AS?36459 | 2620:112:3000::/44 | GITHUB - GitHub, Inc., US From michael at supermathie.net Tue Jun 7 13:43:35 2016 From: michael at supermathie.net (Michael Brown) Date: Tue, 7 Jun 2016 09:43:35 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <5756CF87.6060709@supermathie.net> On 2016-06-07 07:23 AM, Davide Davini wrote: > Who did it say on this ML that the best way to solve these issues is > Netflix tech support? :) Netflix tech support isn't useful for *anything* - even when asked about this specific issue while I was going through my own diagnosis: Me: are you blocking he dot net IPv6 tunnels? Netflix Jerry: IPv6 tunnels as far as I know, no, we have no issues there. You: can you please check? Netflix Jerry: Gimme a sec. You: so if I have a he dot net IPv6 tunnel that is marked as geolocated in Canada, would you still flag that as a VPN/unblocker? Netflix Jerry: OK, Im back... Netflix Jerry: There is no issue with IPV6 as far as today. You: so IPv6 access won't EVER trigger the unblocker/proxy detection? Netflix Jerry: Not at the moment. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From cryptographrix at gmail.com Tue Jun 7 13:55:10 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Tue, 07 Jun 2016 13:55:10 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: As I said to Netflix's tech support - if they advocate for people to turn off IPv6 on their end, maybe Netflix should stop supporting it on their end. It's in the air whether it's just an HE tunnel issue or an IPv6 issue at the moment, and if their tech support is telling people to turn off IPv6, maybe they should just instead remove their AAAA records. (or fail back to ipv4 when v6 looks like a tunnel) On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: > > > On Jun 6, 2016, at 22:25, Spencer Ryan wrote: > > > > The tunnelbroker service acts exactly like a VPN. It allows you, from any > > arbitrary location in the world with an IPv4 address, to bring traffic > out > > via one of HE's 4 POP's, while completely masking your actual location. > > > > Perhaps Netflix should automatically block any connection that's not from > a known residential ISP or mobile ISP as anything else could be a server > someone is proxying through. It's very easy to get these subnets -- the > spam filtering folks have these subnets well documented. /s > > -- > Mark Felder > feld at feld.me > > From nanog at ics-il.net Tue Jun 7 13:58:58 2016 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 7 Jun 2016 08:58:58 -0500 (CDT) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <1130580453.10430.1465307937752.JavaMail.mhammett@ThunderFuck> (not specifically to Cryptographrix) Anyone that expects any consumer-focused support to be able to address any legal or high level technical situation is a fool for having thought appropriate. These sorts of issues are things you start with Tempkin and others that frequent NOGs and other telecom events. You don't go to the web site support chat to get them to make a change to how they handle IPv6 on their end. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Cryptographrix" To: "Mark Felder" , nanog at nanog.org Sent: Tuesday, June 7, 2016 8:55:10 AM Subject: Re: Netflix VPN detection - actual engineer needed As I said to Netflix's tech support - if they advocate for people to turn off IPv6 on their end, maybe Netflix should stop supporting it on their end. It's in the air whether it's just an HE tunnel issue or an IPv6 issue at the moment, and if their tech support is telling people to turn off IPv6, maybe they should just instead remove their AAAA records. (or fail back to ipv4 when v6 looks like a tunnel) On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: > > > On Jun 6, 2016, at 22:25, Spencer Ryan wrote: > > > > The tunnelbroker service acts exactly like a VPN. It allows you, from any > > arbitrary location in the world with an IPv4 address, to bring traffic > out > > via one of HE's 4 POP's, while completely masking your actual location. > > > > Perhaps Netflix should automatically block any connection that's not from > a known residential ISP or mobile ISP as anything else could be a server > someone is proxying through. It's very easy to get these subnets -- the > spam filtering folks have these subnets well documented. /s > > -- > Mark Felder > feld at feld.me > > From joelja at bogus.com Tue Jun 7 14:06:57 2016 From: joelja at bogus.com (joel jaeggli) Date: Tue, 7 Jun 2016 07:06:57 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <9f9d5ae6-788d-7bfb-e64e-f10c236262c5@bogus.com> On 6/7/16 6:55 AM, Cryptographrix wrote: > As I said to Netflix's tech support - if they advocate for people to turn > off IPv6 on their end, maybe Netflix should stop supporting it on their end. > > It's in the air whether it's just an HE tunnel issue or an IPv6 issue at > the moment, and if their tech support is telling people to turn off IPv6, > maybe they should just instead remove their AAAA records. it clearly works with prefixes delegated from other isps. ... http://i.imgur.com/sJUM7tn.png > (or fail back to ipv4 when v6 looks like a tunnel) > > > > On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: > >> >>> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>> >>> The tunnelbroker service acts exactly like a VPN. It allows you, from any >>> arbitrary location in the world with an IPv4 address, to bring traffic >> out >>> via one of HE's 4 POP's, while completely masking your actual location. >>> >> >> Perhaps Netflix should automatically block any connection that's not from >> a known residential ISP or mobile ISP as anything else could be a server >> someone is proxying through. It's very easy to get these subnets -- the >> spam filtering folks have these subnets well documented. /s >> >> -- >> Mark Felder >> feld at feld.me >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From cb.list6 at gmail.com Tue Jun 7 14:22:39 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 7 Jun 2016 07:22:39 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: On Tuesday, June 7, 2016, Cryptographrix wrote: > As I said to Netflix's tech support - if they advocate for people to turn > off IPv6 on their end, maybe Netflix should stop supporting it on their > end. > > It's in the air whether it's just an HE tunnel issue or an IPv6 issue at > the moment, and if their tech support is telling people to turn off IPv6, > maybe they should just instead remove their AAAA records. > > (or fail back to ipv4 when v6 looks like a tunnel) > > I think you need to reset your expectations of a free tunnel service. he.net tunnels are a toy for geeks looking to play with v6. In terms of Netflix subcriber base, it is amazing insignificant number of users. At the end of the day, anonymous tunnels, just like linux, are not supported by Netflix. And, he.net tunnel users are hurting ipv6 overall just like 6to4 by injecting FUD and other nonesense complexity.... For a toy. Move on to a real issue instead of beating this dead horse. CB > > > On Tue, Jun 7, 2016 at 9:22 AM Mark Felder > > wrote: > > > > > > On Jun 6, 2016, at 22:25, Spencer Ryan > > wrote: > > > > > > The tunnelbroker service acts exactly like a VPN. It allows you, from > any > > > arbitrary location in the world with an IPv4 address, to bring traffic > > out > > > via one of HE's 4 POP's, while completely masking your actual location. > > > > > > > Perhaps Netflix should automatically block any connection that's not from > > a known residential ISP or mobile ISP as anything else could be a server > > someone is proxying through. It's very easy to get these subnets -- the > > spam filtering folks have these subnets well documented. /s > > > > -- > > Mark Felder > > feld at feld.me > > > > > From cryptographrix at gmail.com Tue Jun 7 14:46:44 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Tue, 07 Jun 2016 14:46:44 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: Very true - I was being a bit extremist out of frustration, but I think you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6 support, not actually IPv6 support. And I'm quite frustrated because there's so little actual v6 support, and I *do* actually need it on a daily basis for work. Because there's no actual ISP IPv6 support anywhere else (in parts of the US that *have* multiple ISPs), you can't even make the case to your ISP that it's a legitimate requirement for you because they know you're not really going to get v6 elsewhere. On Tue, Jun 7, 2016 at 10:22 AM Ca By wrote: > > > On Tuesday, June 7, 2016, Cryptographrix wrote: > >> As I said to Netflix's tech support - if they advocate for people to turn >> off IPv6 on their end, maybe Netflix should stop supporting it on their >> end. >> >> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >> the moment, and if their tech support is telling people to turn off IPv6, >> maybe they should just instead remove their AAAA records. >> >> (or fail back to ipv4 when v6 looks like a tunnel) >> >> > I think you need to reset your expectations of a free tunnel service. > > he.net tunnels are a toy for geeks looking to play with v6. In terms of > Netflix subcriber base, it is amazing insignificant number of users. > > At the end of the day, anonymous tunnels, just like linux, are not > supported by Netflix. And, he.net tunnel users are hurting ipv6 overall > just like 6to4 by injecting FUD and other nonesense complexity.... For a > toy. > > Move on to a real issue instead of beating this dead horse. > > CB > > >> >> >> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: >> >> > >> > > On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >> > > >> > > The tunnelbroker service acts exactly like a VPN. It allows you, from >> any >> > > arbitrary location in the world with an IPv4 address, to bring traffic >> > out >> > > via one of HE's 4 POP's, while completely masking your actual >> location. >> > > >> > >> > Perhaps Netflix should automatically block any connection that's not >> from >> > a known residential ISP or mobile ISP as anything else could be a server >> > someone is proxying through. It's very easy to get these subnets -- the >> > spam filtering folks have these subnets well documented. /s >> > >> > -- >> > Mark Felder >> > feld at feld.me >> > >> > >> > From cb.list6 at gmail.com Tue Jun 7 15:00:16 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 7 Jun 2016 08:00:16 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: On Tuesday, June 7, 2016, Cryptographrix wrote: > Very true - I was being a bit extremist out of frustration, but I think > you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6 > support, not actually IPv6 support. > > And I'm quite frustrated because there's so little actual v6 support, and > I *do* actually need it on a daily basis for work. > > Because there's no actual ISP IPv6 support anywhere else (in parts of the > US that *have* multiple ISPs), you can't even make the case to your ISP > that it's a legitimate requirement for you because they know you're not > really going to get v6 elsewhere. > > I think we have different definitions of "no actual isp ipv6 support" Again, a helpful akamai blog https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have meaningful deployments of ipv6. The only thing holding back greater deployment for those networks are legacy CPE that will age out slowly. All 4 of the national mobile operator have ipv6 default on for most new phone models. Yes, many gaps to fill still. But, on "my network" with shy of 70 million users, everything has ipv6 except the iPhone, and that will change RSN. And for users with v6, the majority of their traffic is ipv6 e2e since the whales (google, fb, netflix, increasingly Akamai) are dual stack. CB > > > On Tue, Jun 7, 2016 at 10:22 AM Ca By > wrote: > >> >> >> On Tuesday, June 7, 2016, Cryptographrix > > wrote: >> >>> As I said to Netflix's tech support - if they advocate for people to turn >>> off IPv6 on their end, maybe Netflix should stop supporting it on their >>> end. >>> >>> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >>> the moment, and if their tech support is telling people to turn off IPv6, >>> maybe they should just instead remove their AAAA records. >>> >>> (or fail back to ipv4 when v6 looks like a tunnel) >>> >>> >> I think you need to reset your expectations of a free tunnel service. >> >> he.net tunnels are a toy for geeks looking to play with v6. In terms of >> Netflix subcriber base, it is amazing insignificant number of users. >> >> At the end of the day, anonymous tunnels, just like linux, are not >> supported by Netflix. And, he.net tunnel users are hurting ipv6 overall >> just like 6to4 by injecting FUD and other nonesense complexity.... For a >> toy. >> >> Move on to a real issue instead of beating this dead horse. >> >> CB >> >> >>> >>> >>> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: >>> >>> > >>> > > On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>> > > >>> > > The tunnelbroker service acts exactly like a VPN. It allows you, >>> from any >>> > > arbitrary location in the world with an IPv4 address, to bring >>> traffic >>> > out >>> > > via one of HE's 4 POP's, while completely masking your actual >>> location. >>> > > >>> > >>> > Perhaps Netflix should automatically block any connection that's not >>> from >>> > a known residential ISP or mobile ISP as anything else could be a >>> server >>> > someone is proxying through. It's very easy to get these subnets -- the >>> > spam filtering folks have these subnets well documented. /s >>> > >>> > -- >>> > Mark Felder >>> > feld at feld.me >>> > >>> > >>> >> From diotonante at gmail.com Tue Jun 7 15:57:14 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 7 Jun 2016 17:57:14 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> Message-ID: On 04/06/2016 20:46, Owen DeLong wrote: > Get your own /48 and advertise to HE Tunnel via BGP. Problem solved. Even though that sounds like an awesome idea it does not seem trivial to me to obtain your own /48. I mean: "You can only request IPv6 assignments and Autonomous System Numbers through a Sponsoring LIR (a RIPE NCC member)" https://www.ripe.net/manage-ips-and-asns/resource-management/number-resources/independent-resources But you know, my knowledge on the matter is half an hour old, I might be dead wrong. Ciao, Davide Davini. From diotonante at gmail.com Tue Jun 7 16:02:49 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 7 Jun 2016 18:02:49 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <7cfc6b0e-56db-dadd-e251-1a47af457a92@gmail.com> On 07/06/2016 17:00, Ca By wrote: > fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have > meaningful deployments of ipv6. The only thing holding back greater > deployment for those networks are legacy CPE that will age out slowly. It is probably totally off topic as this is NANOG but the issue at end affects other continents too. Where I live good providers are few and expensive. The ones I use and I'm otherwise happy with give me no IPv6 connectivity, that's a shame, it's despicable and I don't lose any opportunity to remind them, but still, I have to use something else if I want to "play" with IPv6. This Netlix thing is just an annoyance, granted, I just wanted to point out that not everyone has a clear way out of this. Ciao, Davide Davini From peterl at standingwave.org Tue Jun 7 17:24:50 2016 From: peterl at standingwave.org (Peter Loron) Date: Tue, 07 Jun 2016 10:24:50 -0700 Subject: syslog server In-Reply-To: References: Message-ID: <94A00C0A-9AA6-4B94-9462-76D6338F0A0C@standingwave.org> I?m a big fan of Graylog. -Pete On 6/6/16, 13:59, "NANOG on behalf of Maximino Velazquez" wrote: >Hi nanog community > >I need help !! > >What is the best syslog server (opensource)? > >Thanks for your help > >Regards. > >-- > > > >Max Velazquez | > From bzs at theworld.com Tue Jun 7 21:59:22 2016 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 7 Jun 2016 17:59:22 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <9E7F25E6-62D7-4B43-93A7-B1E4BD9F5996@delong.com> <2d7c162c-a54f-ad58-24b7-a7a3dfec1344@heliacal.net> <2a51a7ac36d54b59b4c06a696358402b@pur-vm-exch13n2.ox.com> <20160606172123.42825d2d@envy.e5.y.home> <8CC4F66A-8CA2-409B-A161-BED97068AD69@orthanc.ca> Message-ID: <22359.17338.89818.617228@pcls8.std.com> Some of this reminds me of talking to IBM the the other day about problems I was having with their "Rapport Trusteer" security package which one of my banks requires to be running when I try to log in. Invariably the bank claims it's not running, I restart it that software, still no-go, the error msg offers to re-download and install, I do (sometimes that's their "clever" way of saying your version is out of date, why not just say that? who knows), it says to complete you must reboot...hey I just wanted a bank balance, one number, I have all these spread sheets open etc now I have to reboot to get that??? It took over an hour until I got that bank balance. And this happens every other time. (I KNOW change banks, I'm getting there, this is biz banking so not all that simple. And more banks are using this particular drek.) So IBM support calls me back and this person starts explaining to me about drivers and DLLs and how it takes a reboot, standard stuff, why don't you just schedule a reboot every night (HUH? I'm not kidding!) etc. Finally I interrupt him and say NOT MY PROBLEM! I just want my bank balance. I don't care about drivers, I don't care about DLLs, I don't care about why my bank may have chosen this security package, I don't care about your problems with Microsoft's operating system or how your software works... Not...my...problem. A lot of this netflix conversation is similar, suddenly we all have to be empathetic to their licensing challenges and understand the intricacies of regional licensing and how it can be affected by VPN usage etc. Not...my...problem. Ya got what I want, OR NOT? There really is a point where one can make themselves completely nuts trying to gain perspective into why you're not simply getting what you believe you showed up as a customer for and see it as a long-winded way of saying well, you won't get anything for your money, but for a very good reason, have a seat and we'll explain...what a shell game! P.S. I don't sub to netflix and never have because their selection never seemed interesting to me not that I can be sure because you can't really browse it UNLESS you're a customer (clever marketing!) but some people publish "unauthorized" lists and it looked like exactly the sort of stuff I avoid, rom-coms, junk comedies, nothing before about 2000 (I like old movies), etc. YMMV. Ok, go ahead and tell me how difficult it would be for them to get licensing to the sorts of movies I would like...I don't care! Gak! ``No one's ever wanted a 1/4" drill-bit, all they ever wanted was a 1/4" hole'' -- -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 tknchris at gmail.com Tue Jun 7 22:01:13 2016 From: tknchris at gmail.com (chris) Date: Tue, 7 Jun 2016 18:01:13 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: I am also in the same boat with a whole subnet affected even without a tunnel, tried multiple netflix support channels starting in early march and the ranges is still blocked 3 months later. I was a big fan of the service and somewhat of an addict up till this but I've really been shocked how this has been (mis)handled chris On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini wrote: > Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I > can't use it if I don't disable the HE tunnel, which is the only way for > me to have IPv6 at the moment. > > But the fun part has been Netflix tech support: > "Oh I see, yeah we have been receiving reports of some other members > with ipv6 having this issues, at the moment Netflix is not really > designed to work with ipv6 connections, in this case I can recommend you > two things, one is to turn off the ipv6 and the other one will be to > contact directly with Hurricane Electric, there are some customers that > were able to use Netflix with an ipv6 under some specific settings set > by Hurricane Electric." > > I don't obviously expect HE to fix it, I don't pay for shit, it's a free > service, why should they? > > But it's fun to know that " Netflix is not really designed to work with > ipv6 connections ". > > Who did it say on this ML that the best way to solve these issues is > Netflix tech support? :) > > Ciao, > Davide Davini > > From shortdudey123 at gmail.com Wed Jun 8 00:28:09 2016 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 7 Jun 2016 17:28:09 -0700 Subject: syslog server In-Reply-To: <90451.1465280712@turing-police.cc.vt.edu> References: <90451.1465280712@turing-police.cc.vt.edu> Message-ID: +1 for ELKK (with kafka) Doing several hundred GB of log per day with a dozen instances on AWS (ES cluster + logstash hosts + kafak cluster) -Grant On Mon, Jun 6, 2016 at 11:25 PM, wrote: > On Mon, 06 Jun 2016 14:59:51 -0600, Maximino Velazquez said: > > What is the best syslog server (opensource)? > > Step 0: Define what "best" means in your environment. > > What features do you need? Routing to a central aggregation server over > TLS? > Powerful regex-based routing? Ingestion into a database (a la splunk or > Elk) > for data mining? Ability to deal with insanely high message rates? Other > must-have or don't-care features? License pricing? Vendor support? > > Step 1: After figuring out what you need, make a matrix of the available > options and how well they fit. > > (We have in production syslog-ng, rsyslog, splunk, Elk, and probably a few > others I've forgotten, for different purposes....) > > From trelane at trelane.net Wed Jun 8 01:04:34 2016 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 7 Jun 2016 21:04:34 -0400 Subject: syslog server In-Reply-To: References: <90451.1465280712@turing-police.cc.vt.edu> Message-ID: Journald is excellent. The binary storage format is a huge leap forward. Andrew On Tuesday, June 7, 2016, Grant Ridder wrote: > +1 for ELKK (with kafka) > Doing several hundred GB of log per day with a dozen instances on AWS (ES > cluster + logstash hosts + kafak cluster) > > -Grant > > On Mon, Jun 6, 2016 at 11:25 PM, > > wrote: > > > On Mon, 06 Jun 2016 14:59:51 -0600, Maximino Velazquez said: > > > What is the best syslog server (opensource)? > > > > Step 0: Define what "best" means in your environment. > > > > What features do you need? Routing to a central aggregation server over > > TLS? > > Powerful regex-based routing? Ingestion into a database (a la splunk or > > Elk) > > for data mining? Ability to deal with insanely high message rates? Other > > must-have or don't-care features? License pricing? Vendor support? > > > > Step 1: After figuring out what you need, make a matrix of the available > > options and how well they fit. > > > > (We have in production syslog-ng, rsyslog, splunk, Elk, and probably a > few > > others I've forgotten, for different purposes....) > > > > > From CPCashell at west.com Tue Jun 7 21:55:11 2016 From: CPCashell at west.com (Cashell, Christopher P.) Date: Tue, 7 Jun 2016 21:55:11 +0000 Subject: syslog server In-Reply-To: References: Message-ID: There is no "best" when it comes to something like Syslog. There is only "best fit for your requirements". In order to determine that, you'll have to figure out what your goals and requirements are. If you're just trying to do something basic and simple, like get logs from one machine to another, you should probably use what is available and supported by your vendor/distribution. For Debian/Ubuntu, you have Syslog-NG and RSyslog available. For Red Hat/CentOS, you have RSyslog as the default, and Syslog-NG available in EPEL. For other Operating Systems, you'll have to talk to your vendor or do some additional research. If you want to do more than basic log shipping, then you've got some research to do. You need to map out the problem you're trying to solve, and decide on the requirements to accomplish it. Basic syslog is pretty easy. Enterprise log management is a lot more complicated. You start throwing in log aggregation, retention requirements, reliability requirements, encryption, log search, monitoring and alerting, etc., and you've got yourself a project. There are multiple excellent Open Source solutions, but without knowing what you're trying to accomplish, it's difficult to recommend anything. -- Christopher P. Cashell EIT Platform Engineering E-Mail: cpcashell at west.com Infrastructure Monitoring, Management, and Automation Division EIT ~ Converging People and Technologies West Corporation -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maximino Velazquez Sent: Monday, June 6, 2016 4:00 PM To: nanog at nanog.org Subject: syslog server Hi nanog community I need help !! What is the best syslog server (opensource)? Thanks for your help Regards. -- Max Velazquez | From elvis at velea.eu Tue Jun 7 22:35:59 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 8 Jun 2016 01:35:59 +0300 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: apparently, all they see is 3 people complaining on this mailing list.. well, this makes it 4 with me (and I have a bunch of people in various countries complaining on facebook that they have been banned from using netflix because they use an HE tunnel. their answer - TURN IPV6 OFF!!! you're a techie so if you know how to setup a tunnel, you must know how to redirect netflix to use IPv4 only... really? the answer just pisses me off! Netflix, YOU are the ones forcing people to turn IPv4 off... this is just insane. tens (if not hundred) of thousands of people chose to use HE tunnels because their ISP does not offer IPv6.. do you really expect all of them to turn it off? do you really want IPv6 usage in the world to go down by a few percent because you are unable to figure out how to serve content? I know nobody at Netflix will even answer to the e-mails on this list.. but I hope that they will at least acknowledge the problem and figure an other way to block content by country. ie: they could try to talk to HE to register each tunnel in a database that points to the country of the user.. cheers, elvis On 6/8/16 1:01 AM, chris wrote: > I am also in the same boat with a whole subnet affected even without a > tunnel, tried multiple netflix support channels starting in early march and > the ranges is still blocked 3 months later. > > I was a big fan of the service and somewhat of an addict up till this but > I've really been shocked how this has been (mis)handled > > chris > > On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini wrote: > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I >> can't use it if I don't disable the HE tunnel, which is the only way for >> me to have IPv6 at the moment. >> >> But the fun part has been Netflix tech support: >> "Oh I see, yeah we have been receiving reports of some other members >> with ipv6 having this issues, at the moment Netflix is not really >> designed to work with ipv6 connections, in this case I can recommend you >> two things, one is to turn off the ipv6 and the other one will be to >> contact directly with Hurricane Electric, there are some customers that >> were able to use Netflix with an ipv6 under some specific settings set >> by Hurricane Electric." >> >> I don't obviously expect HE to fix it, I don't pay for shit, it's a free >> service, why should they? >> >> But it's fun to know that " Netflix is not really designed to work with >> ipv6 connections ". >> >> Who did it say on this ML that the best way to solve these issues is >> Netflix tech support? :) >> >> Ciao, >> Davide Davini >> >> From tknchris at gmail.com Wed Jun 8 02:41:44 2016 From: tknchris at gmail.com (chris) Date: Tue, 7 Jun 2016 22:41:44 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: it really feels alot like what net neutrality was supposed to avoid. making a policy where there is different treatment of one set of bits over another "your ipv6 bits are bad but if you turn it off the ipv4 bits are just fine" someone mentioned the fact that netflix is not just a content company but also acting as a network operator maybe the two should be separate i also find it ironic that they arent big fans of ISPs who use NAT or CGN and dont have 1 customer per IP yet their stifiling ipv6 and telling users to turn it off. you really cant have it both ways and complain about NAT and also say you recommend shutting off ipv6 :) hopefully they will realize imposing their own policy on how customers use their networks and the internet this isnt worth losing customers over chris On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea wrote: > apparently, all they see is 3 people complaining on this mailing list.. > well, this makes it 4 with me (and I have a bunch of people in various > countries complaining on facebook that they have been banned from using > netflix because they use an HE tunnel. > > their answer - TURN IPV6 OFF!!! you're a techie so if you know how to > setup a tunnel, you must know how to redirect netflix to use IPv4 only... > really? > the answer just pisses me off! > > Netflix, YOU are the ones forcing people to turn IPv4 off... this is just > insane. tens (if not hundred) of thousands of people chose to use HE > tunnels because their ISP does not offer IPv6.. > do you really expect all of them to turn it off? do you really want IPv6 > usage in the world to go down by a few percent because you are unable to > figure out how to serve content? > > I know nobody at Netflix will even answer to the e-mails on this list.. > but I hope that they will at least acknowledge the problem and figure an > other way to block content by country. > ie: they could try to talk to HE to register each tunnel in a database > that points to the country of the user.. > > cheers, > elvis > > > On 6/8/16 1:01 AM, chris wrote: > >> I am also in the same boat with a whole subnet affected even without a >> tunnel, tried multiple netflix support channels starting in early march >> and >> the ranges is still blocked 3 months later. >> >> I was a big fan of the service and somewhat of an addict up till this but >> I've really been shocked how this has been (mis)handled >> >> chris >> >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini >> wrote: >> >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I >>> can't use it if I don't disable the HE tunnel, which is the only way for >>> me to have IPv6 at the moment. >>> >>> But the fun part has been Netflix tech support: >>> "Oh I see, yeah we have been receiving reports of some other members >>> with ipv6 having this issues, at the moment Netflix is not really >>> designed to work with ipv6 connections, in this case I can recommend you >>> two things, one is to turn off the ipv6 and the other one will be to >>> contact directly with Hurricane Electric, there are some customers that >>> were able to use Netflix with an ipv6 under some specific settings set >>> by Hurricane Electric." >>> >>> I don't obviously expect HE to fix it, I don't pay for shit, it's a free >>> service, why should they? >>> >>> But it's fun to know that " Netflix is not really designed to work with >>> ipv6 connections ". >>> >>> Who did it say on this ML that the best way to solve these issues is >>> Netflix tech support? :) >>> >>> Ciao, >>> Davide Davini >>> >>> >>> > From cb.list6 at gmail.com Wed Jun 8 03:10:22 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 7 Jun 2016 20:10:22 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: On Tuesday, June 7, 2016, chris wrote: > it really feels alot like what net neutrality was supposed to avoid. making > a policy where there is different treatment of one set of bits over another > > "your ipv6 bits are bad but if you turn it off the ipv4 bits are just fine" > > someone mentioned the fact that netflix is not just a content company but > also acting as a network operator maybe the two should be separate > > i also find it ironic that they arent big fans of ISPs who use NAT or CGN > and dont have 1 customer per IP yet their stifiling ipv6 and telling users > to turn it off. you really cant have it both ways and complain about NAT > and also say you recommend shutting off ipv6 :) > > hopefully they will realize imposing their own policy on how customers use > their networks and the internet this isnt worth losing customers over > > chris > > Again. An HE tunnel is not production ipv6. It is a toy. Telling people to turn of HE tunnel is NOT the same as turning off production ipv6. CB > On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea > wrote: > > > apparently, all they see is 3 people complaining on this mailing list.. > > well, this makes it 4 with me (and I have a bunch of people in various > > countries complaining on facebook that they have been banned from using > > netflix because they use an HE tunnel. > > > > their answer - TURN IPV6 OFF!!! you're a techie so if you know how to > > setup a tunnel, you must know how to redirect netflix to use IPv4 only... > > really? > > the answer just pisses me off! > > > > Netflix, YOU are the ones forcing people to turn IPv4 off... this is just > > insane. tens (if not hundred) of thousands of people chose to use HE > > tunnels because their ISP does not offer IPv6.. > > do you really expect all of them to turn it off? do you really want IPv6 > > usage in the world to go down by a few percent because you are unable to > > figure out how to serve content? > > > > I know nobody at Netflix will even answer to the e-mails on this list.. > > but I hope that they will at least acknowledge the problem and figure an > > other way to block content by country. > > ie: they could try to talk to HE to register each tunnel in a database > > that points to the country of the user.. > > > > cheers, > > elvis > > > > > > On 6/8/16 1:01 AM, chris wrote: > > > >> I am also in the same boat with a whole subnet affected even without a > >> tunnel, tried multiple netflix support channels starting in early march > >> and > >> the ranges is still blocked 3 months later. > >> > >> I was a big fan of the service and somewhat of an addict up till this > but > >> I've really been shocked how this has been (mis)handled > >> > >> chris > >> > >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini > > >> wrote: > >> > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I > >>> can't use it if I don't disable the HE tunnel, which is the only way > for > >>> me to have IPv6 at the moment. > >>> > >>> But the fun part has been Netflix tech support: > >>> "Oh I see, yeah we have been receiving reports of some other members > >>> with ipv6 having this issues, at the moment Netflix is not really > >>> designed to work with ipv6 connections, in this case I can recommend > you > >>> two things, one is to turn off the ipv6 and the other one will be to > >>> contact directly with Hurricane Electric, there are some customers that > >>> were able to use Netflix with an ipv6 under some specific settings set > >>> by Hurricane Electric." > >>> > >>> I don't obviously expect HE to fix it, I don't pay for shit, it's a > free > >>> service, why should they? > >>> > >>> But it's fun to know that " Netflix is not really designed to work with > >>> ipv6 connections ". > >>> > >>> Who did it say on this ML that the best way to solve these issues is > >>> Netflix tech support? :) > >>> > >>> Ciao, > >>> Davide Davini > >>> > >>> > >>> > > > From tknchris at gmail.com Wed Jun 8 03:16:02 2016 From: tknchris at gmail.com (chris) Date: Tue, 7 Jun 2016 23:16:02 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: I disagree. if they have no native v6 then theres no reason why they shouldnt be able to use the v6 from HE and why should the internet treat that users traffic any differently because its coming from HE or tunneled? Theres also tons of folks affected who arent on HE, arent tunneling, etc. Theres been many people affected who are being told something is wrong with their network that works fine for anything other than netflix. chris On Tue, Jun 7, 2016 at 11:10 PM, Ca By wrote: > > > On Tuesday, June 7, 2016, chris wrote: > >> it really feels alot like what net neutrality was supposed to avoid. >> making >> a policy where there is different treatment of one set of bits over >> another >> >> "your ipv6 bits are bad but if you turn it off the ipv4 bits are just >> fine" >> >> someone mentioned the fact that netflix is not just a content company but >> also acting as a network operator maybe the two should be separate >> >> i also find it ironic that they arent big fans of ISPs who use NAT or CGN >> and dont have 1 customer per IP yet their stifiling ipv6 and telling users >> to turn it off. you really cant have it both ways and complain about NAT >> and also say you recommend shutting off ipv6 :) >> >> hopefully they will realize imposing their own policy on how customers use >> their networks and the internet this isnt worth losing customers over >> >> chris >> >> > > Again. An HE tunnel is not production ipv6. It is a toy. > > Telling people to turn of HE tunnel is NOT the same as turning off > production ipv6. > > CB > > > >> On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea >> wrote: >> >> > apparently, all they see is 3 people complaining on this mailing list.. >> > well, this makes it 4 with me (and I have a bunch of people in various >> > countries complaining on facebook that they have been banned from using >> > netflix because they use an HE tunnel. >> > >> > their answer - TURN IPV6 OFF!!! you're a techie so if you know how to >> > setup a tunnel, you must know how to redirect netflix to use IPv4 >> only... >> > really? >> > the answer just pisses me off! >> > >> > Netflix, YOU are the ones forcing people to turn IPv4 off... this is >> just >> > insane. tens (if not hundred) of thousands of people chose to use HE >> > tunnels because their ISP does not offer IPv6.. >> > do you really expect all of them to turn it off? do you really want IPv6 >> > usage in the world to go down by a few percent because you are unable to >> > figure out how to serve content? >> > >> > I know nobody at Netflix will even answer to the e-mails on this list.. >> > but I hope that they will at least acknowledge the problem and figure an >> > other way to block content by country. >> > ie: they could try to talk to HE to register each tunnel in a database >> > that points to the country of the user.. >> > >> > cheers, >> > elvis >> > >> > >> > On 6/8/16 1:01 AM, chris wrote: >> > >> >> I am also in the same boat with a whole subnet affected even without a >> >> tunnel, tried multiple netflix support channels starting in early march >> >> and >> >> the ranges is still blocked 3 months later. >> >> >> >> I was a big fan of the service and somewhat of an addict up till this >> but >> >> I've really been shocked how this has been (mis)handled >> >> >> >> chris >> >> >> >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini >> >> wrote: >> >> >> >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and >> I >> >>> can't use it if I don't disable the HE tunnel, which is the only way >> for >> >>> me to have IPv6 at the moment. >> >>> >> >>> But the fun part has been Netflix tech support: >> >>> "Oh I see, yeah we have been receiving reports of some other members >> >>> with ipv6 having this issues, at the moment Netflix is not really >> >>> designed to work with ipv6 connections, in this case I can recommend >> you >> >>> two things, one is to turn off the ipv6 and the other one will be to >> >>> contact directly with Hurricane Electric, there are some customers >> that >> >>> were able to use Netflix with an ipv6 under some specific settings set >> >>> by Hurricane Electric." >> >>> >> >>> I don't obviously expect HE to fix it, I don't pay for shit, it's a >> free >> >>> service, why should they? >> >>> >> >>> But it's fun to know that " Netflix is not really designed to work >> with >> >>> ipv6 connections ". >> >>> >> >>> Who did it say on this ML that the best way to solve these issues is >> >>> Netflix tech support? :) >> >>> >> >>> Ciao, >> >>> Davide Davini >> >>> >> >>> >> >>> >> > >> > From cb.list6 at gmail.com Wed Jun 8 03:25:35 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 7 Jun 2016 20:25:35 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: On Tuesday, June 7, 2016, chris wrote: > I disagree. if they have no native v6 then theres no reason why they > shouldnt be able to use the v6 from HE and why should the internet treat > that users traffic any differently because its coming from HE or tunneled? > > This is not about ipv6, it is about an anonymous tunnel. > Theres also tons of folks affected who arent on HE, arent tunneling, etc. > Theres been many people affected who are being told something is wrong with > their network that works fine for anything other than netflix. > > chris > Agreed. This is also not about ipv6. Doing geo-location based DRM is hard and IMHO painful for all parties involved. My point is IPv6 should not be the collateral damage or conflated in an issue that has nothing to do ipv6. This is about an anonymous tunnel service and strict DRM rules. IPv6 works fine. Tunnels and VPN and Netflix do not work fine. CB > > > On Tue, Jun 7, 2016 at 11:10 PM, Ca By > wrote: > >> >> >> On Tuesday, June 7, 2016, chris > > wrote: >> >>> it really feels alot like what net neutrality was supposed to avoid. >>> making >>> a policy where there is different treatment of one set of bits over >>> another >>> >>> "your ipv6 bits are bad but if you turn it off the ipv4 bits are just >>> fine" >>> >>> someone mentioned the fact that netflix is not just a content company but >>> also acting as a network operator maybe the two should be separate >>> >>> i also find it ironic that they arent big fans of ISPs who use NAT or CGN >>> and dont have 1 customer per IP yet their stifiling ipv6 and telling >>> users >>> to turn it off. you really cant have it both ways and complain about NAT >>> and also say you recommend shutting off ipv6 :) >>> >>> hopefully they will realize imposing their own policy on how customers >>> use >>> their networks and the internet this isnt worth losing customers over >>> >>> chris >>> >>> >> >> Again. An HE tunnel is not production ipv6. It is a toy. >> >> Telling people to turn of HE tunnel is NOT the same as turning off >> production ipv6. >> >> CB >> >> >> >>> On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea >>> wrote: >>> >>> > apparently, all they see is 3 people complaining on this mailing list.. >>> > well, this makes it 4 with me (and I have a bunch of people in various >>> > countries complaining on facebook that they have been banned from using >>> > netflix because they use an HE tunnel. >>> > >>> > their answer - TURN IPV6 OFF!!! you're a techie so if you know how to >>> > setup a tunnel, you must know how to redirect netflix to use IPv4 >>> only... >>> > really? >>> > the answer just pisses me off! >>> > >>> > Netflix, YOU are the ones forcing people to turn IPv4 off... this is >>> just >>> > insane. tens (if not hundred) of thousands of people chose to use HE >>> > tunnels because their ISP does not offer IPv6.. >>> > do you really expect all of them to turn it off? do you really want >>> IPv6 >>> > usage in the world to go down by a few percent because you are unable >>> to >>> > figure out how to serve content? >>> > >>> > I know nobody at Netflix will even answer to the e-mails on this list.. >>> > but I hope that they will at least acknowledge the problem and figure >>> an >>> > other way to block content by country. >>> > ie: they could try to talk to HE to register each tunnel in a database >>> > that points to the country of the user.. >>> > >>> > cheers, >>> > elvis >>> > >>> > >>> > On 6/8/16 1:01 AM, chris wrote: >>> > >>> >> I am also in the same boat with a whole subnet affected even without a >>> >> tunnel, tried multiple netflix support channels starting in early >>> march >>> >> and >>> >> the ranges is still blocked 3 months later. >>> >> >>> >> I was a big fan of the service and somewhat of an addict up till this >>> but >>> >> I've really been shocked how this has been (mis)handled >>> >> >>> >> chris >>> >> >>> >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini >>> >> wrote: >>> >> >>> >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" >>> and I >>> >>> can't use it if I don't disable the HE tunnel, which is the only way >>> for >>> >>> me to have IPv6 at the moment. >>> >>> >>> >>> But the fun part has been Netflix tech support: >>> >>> "Oh I see, yeah we have been receiving reports of some other members >>> >>> with ipv6 having this issues, at the moment Netflix is not really >>> >>> designed to work with ipv6 connections, in this case I can recommend >>> you >>> >>> two things, one is to turn off the ipv6 and the other one will be to >>> >>> contact directly with Hurricane Electric, there are some customers >>> that >>> >>> were able to use Netflix with an ipv6 under some specific settings >>> set >>> >>> by Hurricane Electric." >>> >>> >>> >>> I don't obviously expect HE to fix it, I don't pay for shit, it's a >>> free >>> >>> service, why should they? >>> >>> >>> >>> But it's fun to know that " Netflix is not really designed to work >>> with >>> >>> ipv6 connections ". >>> >>> >>> >>> Who did it say on this ML that the best way to solve these issues is >>> >>> Netflix tech support? :) >>> >>> >>> >>> Ciao, >>> >>> Davide Davini >>> >>> >>> >>> >>> >>> >>> > >>> >> > From michael at supermathie.net Wed Jun 8 03:49:34 2016 From: michael at supermathie.net (Michael Brown) Date: Tue, 07 Jun 2016 23:49:34 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <20160608034934.7159891.52772.22813@supermathie.net> Or even easier, just block the he.net tunnel networks! Have them reject the traffic? so it falls back to IPv4! Better than a vague error message combined with poorly or mistrained ?support staff. M. ? Original Message ? From: Elvis Daniel Velea Sent: Tuesday, June 7, 2016 22:12 To: nanog at nanog.org Reply To: elvis at velea.eu Subject: Re: Netflix banning HE tunnels apparently, all they see is 3 people complaining on this mailing list.. well, this makes it 4 with me (and I have a bunch of people in various countries complaining on facebook that they have been banned from using netflix because they use an HE tunnel. their answer - TURN IPV6 OFF!!! you're a techie so if you know how to setup a tunnel, you must know how to redirect netflix to use IPv4 only... really? the answer just pisses me off! Netflix, YOU are the ones forcing people to turn IPv4 off... this is just insane. tens (if not hundred) of thousands of people chose to use HE tunnels because their ISP does not offer IPv6.. do you really expect all of them to turn it off? do you really want IPv6 usage in the world to go down by a few percent because you are unable to figure out how to serve content? I know nobody at Netflix will even answer to the e-mails on this list.. but I hope that they will at least acknowledge the problem and figure an other way to block content by country. ie: they could try to talk to HE to register each tunnel in a database that points to the country of the user.. cheers, elvis On 6/8/16 1:01 AM, chris wrote: > I am also in the same boat with a whole subnet affected even without a > tunnel, tried multiple netflix support channels starting in early march and > the ranges is still blocked 3 months later. > > I was a big fan of the service and somewhat of an addict up till this but > I've really been shocked how this has been (mis)handled > > chris > > On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini wrote: > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I >> can't use it if I don't disable the HE tunnel, which is the only way for >> me to have IPv6 at the moment. >> >> But the fun part has been Netflix tech support: >> "Oh I see, yeah we have been receiving reports of some other members >> with ipv6 having this issues, at the moment Netflix is not really >> designed to work with ipv6 connections, in this case I can recommend you >> two things, one is to turn off the ipv6 and the other one will be to >> contact directly with Hurricane Electric, there are some customers that >> were able to use Netflix with an ipv6 under some specific settings set >> by Hurricane Electric." >> >> I don't obviously expect HE to fix it, I don't pay for shit, it's a free >> service, why should they? >> >> But it's fun to know that " Netflix is not really designed to work with >> ipv6 connections ". >> >> Who did it say on this ML that the best way to solve these issues is >> Netflix tech support? :) >> >> Ciao, >> Davide Davini >> >> From tore at fud.no Wed Jun 8 05:05:25 2016 From: tore at fud.no (Tore Anderson) Date: Wed, 8 Jun 2016 07:05:25 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> Message-ID: <20160608070525.06fd5995@echo.ms.redpill-linpro.com> * Davide Davini > On 04/06/2016 20:46, Owen DeLong wrote: > > Get your own /48 and advertise to HE Tunnel via BGP. Problem > > solved. > > Even though that sounds like an awesome idea it does not seem trivial > to me to obtain your own /48. Which is a good thing, as every new PI /48 advertised to the DFZ will bloat the routing tables of thousands upon thousands of routers world wide. It might solve the Netflix problem, but what has actually happened is that you've split the original problem into a thousand small bits and thrown one piece into each of your neighbours' gardens. I'd encourage everyone to try to fix their Netflix problem a more proper way before deciding to litter everyone else's routing tables with another PI prefix. Blocking access to Netflix via the tunnel seems like an obvious solution to me, for what it's worth. I wonder if anyone has attempted to estimate approx. how much RIB/FIB space a single DFZ route requires in total across the entire internet... Tore From marka at isc.org Wed Jun 8 05:27:04 2016 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jun 2016 15:27:04 +1000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: Your message of "Wed, 08 Jun 2016 07:05:25 +0200." <20160608070525.06fd5995@echo.ms.redpill-linpro.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> Message-ID: <20160608052705.15C904B00B9F@rock.dv.isc.org> In message <20160608070525.06fd5995 at echo.ms.redpill-linpro.com>, Tore Anderson writes: > * Davide Davini > > > On 04/06/2016 20:46, Owen DeLong wrote: > > > Get your own /48 and advertise to HE Tunnel via BGP. Problem > > > solved. > > > > Even though that sounds like an awesome idea it does not seem trivial > > to me to obtain your own /48. > > Which is a good thing, as every new PI /48 advertised to the DFZ will > bloat the routing tables of thousands upon thousands of routers world > wide. It might solve the Netflix problem, but what has actually > happened is that you've split the original problem into a thousand > small bits and thrown one piece into each of your neighbours' gardens. > > I'd encourage everyone to try to fix their Netflix problem a more proper > way before deciding to litter everyone else's routing tables with > another PI prefix. > > Blocking access to Netflix via the tunnel seems like an obvious > solution to me, for what it's worth. And which set of prefixes is that? How often do they change? etc. When Netfix turned on IPv6 support HE's tunnels existed. They should be dealing with the existing environment rather than making others work around their short comings. Tunnels, as much as some people may not like them, will continue to be a part of the IPv6 landscape for many years to come. Mark > I wonder if anyone has attempted to estimate approx. how much RIB/FIB > space a single DFZ route requires in total across the entire internet... > > Tore -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From swmike at swm.pp.se Wed Jun 8 05:32:51 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Jun 2016 07:32:51 +0200 (CEST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160608070525.06fd5995@echo.ms.redpill-linpro.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> Message-ID: On Wed, 8 Jun 2016, Tore Anderson wrote: > I wonder if anyone has attempted to estimate approx. how much RIB/FIB > space a single DFZ route requires in total across the entire internet... You mean in money? A lot. The problem is that we have so far no feasible way to make "polluter pay". So people de-aggreggate left/right, because there is no marginal cost to them, because that cost is instead shared by everybody. I'd imagine the cost to us all is thousands of USD per DFZ slot, if not more. Per month this might not be huge though... Let's say we have 100k routers with all DFZ routes (should be correct magnitude, right?), let's say a router that can take full DFZ instead of smaller number of routes differ 10kUSD? (right magnitude on average?). That's a billion dollars in CAPEX then. Divide that by 5 year lifetime of router, that's 200MUSD per year. Divide that by 100k extra routes that are in the DFZ because nobody is paying for it and you get 2kUSD per year per route. I hope I got the math right... But even 2kUSD per year per route isn't significant amount of money, I still think quite a lot of these routes would get advertised even if each DFZ-prefix came with a cost. So I also think that is part of the reason we don't have a charging system for DFZ slots, because getting that charging infrastructure to work isn't worth it, the benefit of this complication isn't enough. -- Mikael Abrahamsson email: swmike at swm.pp.se From arnold at nipper.de Wed Jun 8 05:36:40 2016 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 8 Jun 2016 07:36:40 +0200 Subject: Bogon ASN Filter Policy In-Reply-To: <22353.33101.968191.138056@oz.mt.att.com> References: <20160602194138.GM15096@57.rev.meerval.net> <22353.33101.968191.138056@oz.mt.att.com> Message-ID: <82502792-912e-b6df-6477-27f6ba573222@nipper.de> On 03.06.2016 15:08, Jay Borkenhagen wrote: > AT&T/as7018 is also now in the process of updating its as-path bogon > filters to match those cited below. We have long employed such > filters, and our changes at this time are primarily to extend them to > prohibit as23456 and the reserved blocks > as65535. > > So to Job and Adam and anyone else who deploys such filters: Thanks! > I would like to extend to you this laurel, and hearty handshake... > Well done, NTT, GTT, AT&T. You may want to notice that most of the IXP around the world which operate route servers since long do strict filtering. Both on ASN as well as on prefixes. So it's really nice to see, that the big ISP take care as well now. As I have learnt yesterday at ENOG11 a way more challenging issue is to cope with route leaks. Cheers and cu in chi Arnold > > On 02-June-2016, Adam Davenport writes: > > I personally applaud this effort as initiatives like this that help > > prevent the global propagation of Bogons and other "bad things" only > > serves to help us all. With that said, notice went out to potentially > > affected GTT / AS3257 customers this week that by the end of June we too > > will be filtering prefixes that contain any of the Bogon ASNs listed > > below in the in the as-path. I highly encourage other networks to > > follow suit, as again it only helps us all. > > > > Thanks Job for kicking this one off, and I look forward to others to > > doing the same! > > > > Adam Davenport / adam.davenport at gtt.net > > > > > > > > On 6/2/16 3:41 PM, Job Snijders wrote: > > > Dear fellow network operators, > > > > > > In July 2016, NTT Communications' Global IP Network AS2914 will deploy a > > > new routing policy to block Bogon ASNs from its view of the default-free > > > zone. This notification is provided as a courtesy to the network > > > community at large. > > > > > > After the Bogon ASN filter policy has been deployed, AS 2914 will not > > > accept route announcements from any eBGP neighbor which contains a Bogon > > > ASN anywhere in the AS_PATH or its atomic aggregate attribute. > > > > > > The reasoning behind this policy is twofold: > > > > > > - Private or Reserved ASNs have no place in the public DFZ. Barring > > > these from the DFZ helps improve accountability and dampen > > > accidental exposure of internal routing artifacts. > > > > > > - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" > > > in the DFZ is a either a misconfiguration or software issue. > > > > > > We are undertaking this effort to improve the quality of routing data as > > > part of the global ecosystem. This should improve the security posture > > > and provide additional certainty [1] to those undertaking network > > > troubleshooting. > > > > > > Bogon ASNs are currently defined as following: > > > > > > 0 # Reserved RFC7607 > > > 23456 # AS_TRANS RFC6793 > > > 64496-64511 # Reserved for use in docs and code RFC5398 > > > 64512-65534 # Reserved for Private Use RFC6996 > > > 65535 # Reserved RFC7300 > > > 65536-65551 # Reserved for use in docs and code RFC5398 > > > 65552-131071 # Reserved > > > 4200000000-4294967294 # Reserved for Private Use RFC6996 > > > 4294967295 # Reserved RFC7300 > > > > > > A current overview of what are considered Bogon ASNs is maintained at > > > NTT's Routing Policies page [2]. The IANA Autonomous System Number > > > Registry [3] is closely tracked and the NTT Bogon ASN definitions are > > > updated accordingly. > > > > > > We encourage network operators to consider deploying similar policies. > > > Configuration examples for various platforms can be found here [4]. > > > > > > NTT staff is monitoring current occurrences of Bogon ASNs in the routing > > > system and reaching out to impacted parties on a weekly basis. > > > > > > Kind regards, > > > > > > Job > > > > > > Contact persons: > > > > > > Job Snijders , Jared Mauch , > > > NTT Communications NOC > > > > > > References: > > > [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > > > [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon > > > [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml > > > [4]: http://as2914.net/bogon_asns/configuration_examples.txt > -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From kotikalapudi.sriram at nist.gov Wed Jun 8 11:48:36 2016 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Wed, 8 Jun 2016 11:48:36 +0000 Subject: intra-AS messaging for route leak prevention In-Reply-To: <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> References: <20160606155418.GD35417@22.rev.meerval.net>, <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> Message-ID: Thanks for the inputs about the inter-AS messaging and route-leak prevention techniques between neighboring ASes. Certainly helpful information and also useful for the draft (draft-ietf-idr-route-leak-detection-mitigation). However, my question was focused on "intra-AS" messaging. About conveying from ingress to egress router (within your AS), the info regarding the type of peer from which the route was received at ingress. This info is used at the egress router to avoid leaking a route. Question: Is the "common practice" described in the original message http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html (see the stuff in quotes) sufficient or are there other ways in common use in which network operators convey the said information from ingress to egress router? Sriram From nanog-post at rsuc.gweep.net Wed Jun 8 12:48:11 2016 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 8 Jun 2016 08:48:11 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> Message-ID: <20160608124811.GA75603@gweep.net> On Wed, Jun 08, 2016 at 11:48:36AM +0000, Sriram, Kotikalapudi (Fed) wrote: > Thanks for the inputs about the inter-AS messaging and route-leak prevention > techniques between neighboring ASes. Certainly helpful information and also useful > for the draft (draft-ietf-idr-route-leak-detection-mitigation). > > However, my question was focused on "intra-AS" messaging. > About conveying from ingress to egress router (within your AS), > the info regarding the type of peer from which the route was received at ingress. > This info is used at the egress router to avoid leaking a route. > > Question: Is the "common practice" described in the original message > http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html (see the stuff in quotes) > sufficient or are there other ways in common use in which network operators > convey the said information from ingress to egress router? "There are more routing policies in heavan and earth, Sriram Than are dreamt of in your draft." But in my experience, community tagging is by far the widest deployment due to the broad support and extent of information which can be carried. It is useful to note that AS_PATH if often also involved on egress decisions. The sadness is that some platforms' processing of prefixes and policies coupled with certain operational practices mean we still see leaks beyond intended scope during maintenance windows. cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From michael.hare at wisc.edu Wed Jun 8 12:56:18 2016 From: michael.hare at wisc.edu (Michael Hare) Date: Wed, 08 Jun 2016 12:56:18 +0000 Subject: Bogon ASN Filter Policy In-Reply-To: <82502792-912e-b6df-6477-27f6ba573222@nipper.de> References: <20160602194138.GM15096@57.rev.meerval.net> <22353.33101.968191.138056@oz.mt.att.com> <82502792-912e-b6df-6477-27f6ba573222@nipper.de> Message-ID: I'm not against the theory of what is being proposed, but I was surprised to see little discussion of this announcement on list. Upon examination on my view of the DFZ from AS3128 I see over 400 upstream routes falling into this category, mostly in the 64512 - 65534 range. Based on our flow bandwidth stats we chose to reach out to several origin ASN, two fairly well known, as a courtesy. For the *TT's who are planning on implementing shortly, have you went through a similar diagnostic effort and what might you share or report on such endeavors? -Michael > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Arnold Nipper > Sent: Wednesday, June 08, 2016 12:37 AM > To: Jay Borkenhagen ; nanog at nanog.org > Subject: Re: Bogon ASN Filter Policy > > On 03.06.2016 15:08, Jay Borkenhagen wrote: > > > AT&T/as7018 is also now in the process of updating its as-path bogon > > filters to match those cited below. We have long employed such > > filters, and our changes at this time are primarily to extend them to > > prohibit as23456 and the reserved blocks > as65535. > > > > So to Job and Adam and anyone else who deploys such filters: Thanks! > > I would like to extend to you this laurel, and hearty handshake... > > > > Well done, NTT, GTT, AT&T. You may want to notice that most of the IXP > around the world which operate route servers since long do strict > filtering. Both on ASN as well as on prefixes. So it's really nice to > see, that the big ISP take care as well now. > > As I have learnt yesterday at ENOG11 a way more challenging issue is to > cope with route leaks. > > > Cheers and cu in chi > Arnold > > > > > On 02-June-2016, Adam Davenport writes: > > > I personally applaud this effort as initiatives like this that help > > > prevent the global propagation of Bogons and other "bad things" only > > > serves to help us all. With that said, notice went out to potentially > > > affected GTT / AS3257 customers this week that by the end of June we too > > > will be filtering prefixes that contain any of the Bogon ASNs listed > > > below in the in the as-path. I highly encourage other networks to > > > follow suit, as again it only helps us all. > > > > > > Thanks Job for kicking this one off, and I look forward to others to > > > doing the same! > > > > > > Adam Davenport / adam.davenport at gtt.net > > > > > > > > > > > > On 6/2/16 3:41 PM, Job Snijders wrote: > > > > Dear fellow network operators, > > > > > > > > In July 2016, NTT Communications' Global IP Network AS2914 will deploy > a > > > > new routing policy to block Bogon ASNs from its view of the default-free > > > > zone. This notification is provided as a courtesy to the network > > > > community at large. > > > > > > > > After the Bogon ASN filter policy has been deployed, AS 2914 will not > > > > accept route announcements from any eBGP neighbor which contains a > Bogon > > > > ASN anywhere in the AS_PATH or its atomic aggregate attribute. > > > > > > > > The reasoning behind this policy is twofold: > > > > > > > > - Private or Reserved ASNs have no place in the public DFZ. Barring > > > > these from the DFZ helps improve accountability and dampen > > > > accidental exposure of internal routing artifacts. > > > > > > > > - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" > > > > in the DFZ is a either a misconfiguration or software issue. > > > > > > > > We are undertaking this effort to improve the quality of routing data as > > > > part of the global ecosystem. This should improve the security posture > > > > and provide additional certainty [1] to those undertaking network > > > > troubleshooting. > > > > > > > > Bogon ASNs are currently defined as following: > > > > > > > > 0 # Reserved RFC7607 > > > > 23456 # AS_TRANS RFC6793 > > > > 64496-64511 # Reserved for use in docs and code RFC5398 > > > > 64512-65534 # Reserved for Private Use RFC6996 > > > > 65535 # Reserved RFC7300 > > > > 65536-65551 # Reserved for use in docs and code RFC5398 > > > > 65552-131071 # Reserved > > > > 4200000000-4294967294 # Reserved for Private Use RFC6996 > > > > 4294967295 # Reserved RFC7300 > > > > > > > > A current overview of what are considered Bogon ASNs is maintained at > > > > NTT's Routing Policies page [2]. The IANA Autonomous System Number > > > > Registry [3] is closely tracked and the NTT Bogon ASN definitions are > > > > updated accordingly. > > > > > > > > We encourage network operators to consider deploying similar policies. > > > > Configuration examples for various platforms can be found here [4]. > > > > > > > > NTT staff is monitoring current occurrences of Bogon ASNs in the routing > > > > system and reaching out to impacted parties on a weekly basis. > > > > > > > > Kind regards, > > > > > > > > Job > > > > > > > > Contact persons: > > > > > > > > Job Snijders , Jared Mauch , > > > > NTT Communications NOC > > > > > > > > References: > > > > [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 > > > > [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon > > > > [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml > > > > [4]: http://as2914.net/bogon_asns/configuration_examples.txt > > > > > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arnold at nipper.de phone: +49 6224 5593407 2 > mobile: +49 172 2650958 fax: +49 6224 5593407 9 From mark.tinka at seacom.mu Wed Jun 8 13:24:15 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jun 2016 15:24:15 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160608124811.GA75603@gweep.net> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> Message-ID: <14cdb926-c2fa-a726-46fb-c0554e92ac54@seacom.mu> On 8/Jun/16 14:48, Joe Provo wrote: > > "There are more routing policies in heavan and earth, Sriram > Than are dreamt of in your draft." > > But in my experience, community tagging is by far the widest > deployment due to the broad support and extent of information > which can be carried. It is useful to note that AS_PATH if > often also involved on egress decisions. Agree. We use BGP communities extensively on all eBGP sessions to identify upstreams, peers, customers, special partners, e.t.c., on the inbound routing policy. Outbound routing policies will depend on the type of neighbor, i.e., upstream, peer, customer, special partner, e.t.c. At any rate, we use communities to determine what routes will be announced to what eBGP neighbor. Those communities will need to match the intended source of the route at some other point in the network. The only time we look at prefix lists is to ensure we send (or accept) nothing longer than a /24 (IPv4) or a /48 (IPv6) to (and from) an eBGP neighbor of any kind. That said, further granularity in the outbound routing policy toward upstreams will allow for transmission of longest-match (/32 IPv4 and /128 IPv6) to support RTBH requirements. This is a co-ordinated routing policy, so it is not harmful to us, our upstreams or the wider Internet. We'd also accept these prefix lengths from BGP customers as part of their standard RTBH capability they get when they buy IP Transit from us; again, highly controlled and co-ordinated to never cause any harm to us, the customer or the wider Internet, while still being 100% functional for the customer. Ultimately, once a routing policy is in place on a specific router, we are never touching that router again as the edge moves around, i.e., customers, peers, special partners, e.t.c., come on-board, move around, e.t.c. This creates natural safe guards against cock-ups, although the goal is always to eliminate cock-ups from the get-go (automation of repetitive provisioning tasks makes this goal easier to attain). Coupled with our insistence on creating matching prefix and AS_PATH filters for all customers (after being checked against the relevant RIR WHOIS database to avoid hijack), we've been fortunate to never be in a position where our network is leaking routes, unintentionally or otherwise. Work continues to further harden this so that it never happens. Mark. From mark.tinka at seacom.mu Wed Jun 8 13:25:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jun 2016 15:25:28 +0200 Subject: Bogon ASN Filter Policy In-Reply-To: References: <20160602194138.GM15096@57.rev.meerval.net> <22353.33101.968191.138056@oz.mt.att.com> <82502792-912e-b6df-6477-27f6ba573222@nipper.de> Message-ID: <6f0c12bf-0af0-d7c2-f95b-c6bb358be7b1@seacom.mu> On 8/Jun/16 14:56, Michael Hare wrote: > I'm not against the theory of what is being proposed, but I was surprised to see little discussion of this announcement on list. > > Upon examination on my view of the DFZ from AS3128 I see over 400 upstream routes falling into this category, mostly in the 64512 - 65534 range. Based on our flow bandwidth stats we chose to reach out to several origin ASN, two fairly well known, as a courtesy. > > For the *TT's who are planning on implementing shortly, have you went through a similar diagnostic effort and what might you share or report on such endeavors? At the very least, "remove-private-as" should be a standard step in the procedure of turning up any eBGP session. Mark. From job at instituut.net Wed Jun 8 13:26:11 2016 From: job at instituut.net (Job Snijders) Date: Wed, 8 Jun 2016 14:26:11 +0100 Subject: Bogon ASN Filter Policy In-Reply-To: References: <20160602194138.GM15096@57.rev.meerval.net> <22353.33101.968191.138056@oz.mt.att.com> <82502792-912e-b6df-6477-27f6ba573222@nipper.de> Message-ID: <20160608132611.GZ35417@22.rev.meerval.net> Dear Michael, On Wed, Jun 08, 2016 at 12:56:18PM +0000, Michael Hare wrote: > Upon examination on my view of the DFZ from AS3128 I see over 400 > upstream routes falling into this category, mostly in the 64512 - > 65534 range. Based on our flow bandwidth stats we chose to reach out > to several origin ASN, two fairly well known, as a courtesy. > > For the *TT's who are planning on implementing shortly, have you went > through a similar diagnostic effort and what might you share or report > on such endeavors? Below is a copy+paste from the weekly report which drives our outreach effort. We recognise two types of prefixes: "Problem prefixes" and "problems resolved by a less specific". It seems likely that the "saved by overlapping less-specific" ones are the result of accidental exposure of something that should remain internal, and the "problem prefixes" are likely to be misconfigurations or software issues. Hopefully, by the time we actually deploy the new policy, all of these have been resolved. When we started the outreach 3 weeks ago, the "problem prefixes" count was at ~ 250 prefixes, and today its just 100. --------------------------------------- Dear reader, This is an automated report to provide insight into the effects of the new Bogon ASN as-path filters NTT will deploy in July 2016. This script parses a full table RIB dump as seen from a customer perspective (kiera.meerval.net in Amsterdam) and searches which prefixes would be dropped without causing too much concern, and which prefixes might fall off the routing table. Bogon ASNs are defined as: 0, 23456, 64496-131071, 4200000000-4294967295 Problem prefixes: (100 issues) ----------------------------- 23.111.250.0/24 (path: 2914 174 15003 15003 15003 15003 15003 15003 15003 64666 ) 185.153.56.0/24 (path: 2914 174 199203 64600 ) 185.5.141.0/24 (path: 2914 174 5563 65300 5563 ) 108.57.142.0/23 (path: 2914 701 64512 ) 108.57.144.0/21 (path: 2914 701 64512 ) 108.57.152.0/21 (path: 2914 701 64512 ) 112.133.192.0/18 (path: 2914 1273 55410 24186 45851 59194 64608 ) 122.15.0.0/16 (path: 2914 1273 55410 26685 55917 65001 65002 65003 134007 134041 134304 ) 182.19.80.0/21 (path: 2914 1273 55410 58906 65001 ) 91.233.214.0/23 (path: 2914 1299 24589 23456 ) 176.103.176.0/20 (path: 2914 1299 24589 23456 ) 176.103.192.0/21 (path: 2914 1299 24589 23456 ) 208.78.104.0/21 (path: 2914 2828 13703 22626 64512 ) 103.199.88.0/22 (path: 2914 3257 9498 9730 23456 ) 188.247.64.0/19 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) 111.235.148.0/22 (path: 2914 3257 9498 9730 23456 ) 103.197.240.0/22 (path: 2914 3257 9498 9730 23456 ) 103.225.224.0/22 (path: 2914 3257 9498 9730 23456 ) 137.59.8.0/22 (path: 2914 3257 9498 9730 23456 ) 80.90.160.0/20 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) 192.96.139.0/24 (path: 2914 3356 11845 65610 ) 186.226.16.0/20 (path: 2914 3356 3549 16594 23456 262763 ) 194.169.32.0/20 (path: 2914 4589 8190 4200000246 ) 2001:df0:458::/48 (path: 2914 4755 18229 64701 65502 65309 ) 103.57.64.0/22 (path: 2914 4755 133987 65350 ) 162.247.245.0/24 (path: 2914 6327 55117 64512 ) 185.103.109.0/24 (path: 2914 6461 43350 23456 ) 31.220.112.0/21 (path: 2914 6663 31317 65528 ) 200.0.209.0/24 (path: 2914 6762 7303 262195 23456 7005 7005 7005 ) 200.0.210.0/24 (path: 2914 6762 7303 262195 23456 7005 7005 7005 ) 200.0.211.0/24 (path: 2914 6762 7303 262195 23456 7005 7005 7005 ) 200.59.127.0/24 (path: 2914 6762 7303 262195 23456 262195 262195 10617 ) 200.59.120.0/24 (path: 2914 6762 7303 262195 23456 262195 262195 10617 ) 200.59.121.0/24 (path: 2914 6762 7303 262195 23456 262195 262195 10617 ) 190.13.94.0/24 (path: 2914 6762 7303 262195 23456 52351 ) 2a07:33c0::/29 (path: 2914 6830 12676 54431 65100 ) 192.108.127.0/24 (path: 2914 7029 393543 65001 ) 70.40.139.0/24 (path: 2914 7029 19397 64712 ) 93.95.176.0/24 (path: 2914 8928 15924 65411 ) 79.170.168.0/24 (path: 2914 8928 15924 65411 ) 213.252.251.0/24 (path: 2914 9002 9002 9002 9002 9002 42979 201201 199527 65529 199527 199527 ) 2a03:7380:4000::/42 (path: 2914 9002 13188 64604 ) 2a03:7380:4040::/42 (path: 2914 9002 13188 64604 ) 185.91.236.0/23 (path: 2914 9009 9009 9009 65052 ) 93.113.208.0/22 (path: 2914 9009 6910 65002 ) 91.102.64.0/21 (path: 2914 9009 9009 9009 65433 ) 103.16.229.0/24 (path: 2914 9304 133398 64513 ) 103.195.55.0/24 (path: 2914 9498 58601 24323 65005 64058 ) 103.57.151.0/24 (path: 2914 9498 58717 58736 58599 65534 38026 63984 ) 188.65.30.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 188.65.31.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 188.65.26.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 15679 15679 15679 15679 15679 ) 188.65.27.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 15679 15679 15679 15679 15679 ) 188.65.24.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 188.65.25.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 2400:5200:1400::/40 (path: 2914 9498 55410 38266 65001 65010 ) 210.24.216.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.218.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.219.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.212.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.214.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.210.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.208.0/24 (path: 2914 10026 4628 9255 65010 ) 210.24.209.0/24 (path: 2914 10026 4628 9255 65010 ) 142.148.224.0/24 (path: 2914 12179 14630 64512 ) 142.148.225.0/24 (path: 2914 12179 14630 64512 ) 2a02:4680:f::/48 (path: 2914 12389 42608 65500 65501 ) 195.135.240.0/22 (path: 2914 12389 21453 49893 50802 65001 ) 46.229.74.0/23 (path: 2914 12389 25549 65526 ) 46.151.104.0/21 (path: 2914 12389 21453 49893 50802 65001 ) 192.150.214.0/23 (path: 2914 13768 65013 ) 208.86.242.0/24 (path: 2914 14265 46926 65001 46926 46926 46926 46926 46926 46926 ) 192.16.2.0/24 (path: 2914 15133 65405 ) 192.16.3.0/24 (path: 2914 15133 65405 ) 194.69.42.0/24 (path: 2914 15830 65501 21160 21160 ) 91.208.64.0/24 (path: 2914 20485 198816 65005 47593 ) 199.7.166.0/24 (path: 2914 22626 64512 ) 199.7.167.0/24 (path: 2914 22626 64512 ) 208.83.6.0/23 (path: 2914 22626 64512 ) 2620:be:8000::/48 (path: 2914 22773 64514 ) 2602:ff61::/48 (path: 2914 22773 65005 ) 130.0.231.0/24 (path: 2914 23352 39470 18919 65156 ) 143.41.0.0/21 (path: 2914 25180 4200000368 ) 143.41.8.0/21 (path: 2914 25180 4200000501 ) 185.129.208.0/24 (path: 2914 25180 4200000382 ) 185.129.209.0/24 (path: 2914 25180 4200000382 ) 185.52.36.0/22 (path: 2914 25180 4200000090 ) 176.122.192.0/23 (path: 2914 25180 4200000402 ) 139.143.0.0/16 (path: 2914 25180 4200000318 ) 195.95.131.0/24 (path: 2914 25180 4200000365 ) 82.139.64.0/18 (path: 2914 41887 41887 65031 ) 185.117.10.0/24 (path: 2914 44217 65500 ) 185.117.11.0/24 (path: 2914 44217 65500 ) 185.117.8.0/24 (path: 2914 44217 65500 ) 185.117.9.0/24 (path: 2914 44217 65500 ) 91.234.228.0/24 (path: 2914 47872 20771 16010 65009 198874 ) 119.235.130.0/24 (path: 2914 63928 24427 64928 ) 119.235.131.0/24 (path: 2914 63928 24427 64928 ) 119.235.128.0/24 (path: 2914 63928 24427 64928 ) 119.235.129.0/24 (path: 2914 63928 24427 64928 ) resolved by virtue of existing overlapping prefix: -------------------------------------------------- 116.50.64.0/18 (path: 2914 3257 9498 38529 ) contains: 116.50.78.0/23 (path: 2914 9498 38529 64520 ) 116.50.90.0/24 (path: 2914 4755 38529 64520 ) 116.50.80.0/24 (path: 2914 9498 38529 64520 ) 116.50.85.0/24 (path: 2914 9498 38529 64520 ) 123.30.64.0/20 (path: 2914 58453 45899 7643 ) contains: 123.30.74.0/24 (path: 2914 58453 45899 45899 65512 ) 123.30.75.0/24 (path: 2914 58453 45899 45899 65512 ) 124.92.0.0/14 (path: 2914 4837 4837 ) contains: 124.93.212.0/23 (path: 2914 4837 65501 ) 124.93.214.0/23 (path: 2914 4837 65501 ) 135.84.176.0/22 (path: 2914 13768 54527 ) contains: 135.84.177.0/24 (path: 2914 6327 54527 63213 65002 ) 152.176.0.0/12 (path: 2914 701 ) contains: 152.178.135.0/24 (path: 2914 701 64512 ) 154.72.52.0/23 (path: 2914 174 327797 ) contains: 154.72.52.0/24 (path: 2914 174 327797 65502 ) 157.254.228.0/22 (path: 2914 174 7332 11648 ) contains: 157.254.229.0/24 (path: 2914 4755 65805 ) 167.219.60.0/23 (path: 2914 703 30337 30337 30337 30337 30337 30337 30337 30337 30337 30337 30337 ) contains: 167.219.60.0/24 (path: 2914 4755 30337 65001 ) 173.231.64.0/19 (path: 2914 174 26801 19159 ) contains: 173.231.76.0/24 (path: 2914 174 26801 19159 19159 64573 ) 174.35.0.0/17 (path: 2914 3257 36408 ) contains: 174.35.0.0/24 (path: 2914 14265 65204 ) 178.60.192.0/18 (path: 2914 174 12334 ) contains: 178.60.197.0/24 (path: 2914 174 12334 199949 64555 ) 185.66.84.0/22 (path: 2914 9002 9049 201706 ) contains: 185.66.86.0/24 (path: 2914 9002 9049 201706 65555 ) 188.247.64.0/19 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) contains: 188.247.72.0/21 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) 188.65.28.0/23 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 ) contains: 188.65.28.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 188.65.29.0/24 (path: 2914 9498 8529 8529 8529 8529 8529 8529 8529 8529 28885 65535 15679 15679 ) 190.131.192.0/18 (path: 2914 23520 ) contains: 190.131.193.0/24 (path: 2914 23520 262191 65499 ) 190.131.198.0/24 (path: 2914 23520 262191 65475 ) 190.68.128.0/19 (path: 2914 12956 3816 ) contains: 190.68.130.0/24 (path: 2914 12956 3816 3816 3816 3816 3816 65329 3816 ) 194.204.192.0/18 (path: 2914 12956 6713 ) contains: 194.204.217.0/24 (path: 2914 174 6713 6713 6713 6713 6713 6713 6713 36956 65375 ) 194.70.0.0/16 (path: 2914 1273 2529 ) contains: 194.70.246.0/24 (path: 2914 1273 65539 ) 195.135.240.0/22 (path: 2914 12389 21453 49893 50802 65001 ) contains: 195.135.240.0/23 (path: 2914 12389 21453 49893 50802 65001 ) 195.135.242.0/23 (path: 2914 12389 21453 49893 50802 65001 ) 195.46.128.0/19 (path: 2914 8928 15924 ) contains: 195.46.147.0/24 (path: 2914 8928 15924 65121 ) 195.87.0.0/16 (path: 2914 8928 15924 8386 ) contains: 195.87.13.0/24 (path: 2914 8928 15924 8386 65412 ) 195.87.42.0/24 (path: 2914 8928 15924 64512 ) 199.204.224.0/22 (path: 2914 3356 4323 40059 ) contains: 199.204.224.0/24 (path: 2914 2828 6181 40059 65433 ) 199.45.32.0/19 (path: 2914 701 ) contains: 199.45.53.0/24 (path: 2914 701 65403 ) 199.45.54.0/24 (path: 2914 701 65403 ) 2001:578::/30 (path: 2914 22773 ) contains: 2001:57a:eff1::/48 (path: 2914 22773 64517 ) 204.76.144.0/21 (path: 2914 2828 6128 63254 ) contains: 204.76.148.0/22 (path: 2914 174 46887 63254 64512 ) 205.177.0.0/16 (path: 2914 3491 ) contains: 205.177.67.0/24 (path: 2914 3491 65536 ) 205.177.68.0/24 (path: 2914 3491 65536 ) 206.154.0.0/19 (path: 2914 209 17402 ) contains: 206.154.0.0/20 (path: 2914 209 4200000006 ) 207.245.64.0/18 (path: 2914 3491 6372 ) contains: 207.245.119.0/24 (path: 2914 2828 6372 65006 ) 207.250.0.0/16 (path: 2914 3356 4323 ) contains: 207.250.99.0/24 (path: 2914 17054 13492 64600 ) 208.78.104.0/21 (path: 2914 2828 13703 22626 64512 ) contains: 208.78.111.0/24 (path: 2914 22626 64512 ) 208.97.0.0/19 (path: 2914 174 31877 ) contains: 208.97.12.0/22 (path: 2914 40111 40111 65003 ) 208.97.19.0/24 (path: 2914 174 31877 65004 ) 212.139.0.0/16 (path: 2914 13285 13285 13285 13285 13285 13285 13285 9105 ) contains: 212.139.133.0/24 (path: 2914 6453 13285 65160 ) 212.15.0.0/19 (path: 2914 8928 15924 ) contains: 212.15.5.0/24 (path: 2914 8928 15924 65077 ) 212.154.128.0/17 (path: 2914 12389 9198 50482 ) contains: 212.154.167.0/24 (path: 2914 12389 9198 50482 64605 ) 212.154.205.0/24 (path: 2914 12389 9198 50482 64605 ) 212.26.224.0/19 (path: 2914 12389 12730 ) contains: 212.26.238.0/24 (path: 2914 12389 12730 65001 ) 213.160.128.0/19 (path: 2914 702 3252 12963 ) contains: 213.160.148.0/24 (path: 2914 702 3252 12963 64564 ) 213.52.192.0/18 (path: 2914 15830 ) contains: 213.52.252.0/22 (path: 2914 15830 65501 39882 ) 217.20.32.0/20 (path: 2914 15830 ) contains: 217.20.41.0/24 (path: 2914 15830 65501 39882 ) 221.200.0.0/14 (path: 2914 4837 4837 ) contains: 221.203.248.0/22 (path: 2914 4837 64920 ) 221.203.252.0/22 (path: 2914 4837 64920 ) 221.203.244.0/23 (path: 2914 4837 64920 ) 221.203.246.0/23 (path: 2914 4837 64920 ) 27.248.0.0/14 (path: 2914 9498 10201 10201 10201 10201 10201 10201 ) contains: 27.248.64.0/18 (path: 2914 9498 10201 65500 ) 27.248.128.0/19 (path: 2914 9498 10201 65500 ) 27.248.96.0/19 (path: 2914 9498 10201 65500 ) 37.1.240.0/20 (path: 2914 6461 8218 48072 ) contains: 37.1.241.0/24 (path: 2914 1299 29075 48072 31167 65623 ) 37.1.250.0/23 (path: 2914 6461 8218 48072 48072 65623 31167 ) 37.142.0.0/16 (path: 2914 174 12849 ) contains: 37.142.0.0/17 (path: 2914 174 12849 12849 21450 65024 65500 ) 37.235.32.0/21 (path: 2914 8928 12715 43160 ) contains: 37.235.36.0/24 (path: 2914 174 43160 65501 ) 37.26.104.0/21 (path: 2914 39326 52148 ) contains: 37.26.105.0/24 (path: 2914 34555 64522 ) 38.0.0.0/8 (path: 2914 174 ) contains: 38.88.85.0/24 (path: 2914 174 393544 64532 ) 41.89.0.0/16 (path: 2914 30844 36914 ) contains: 41.89.7.0/24 (path: 2914 6762 37219 36866 36866 36866 65412 ) 46.151.104.0/21 (path: 2914 12389 21453 49893 50802 65001 ) contains: 46.151.104.0/22 (path: 2914 12389 21453 49893 50802 65001 ) 46.151.108.0/22 (path: 2914 12389 21453 49893 50802 65001 ) 60.16.0.0/13 (path: 2914 4837 4837 ) contains: 60.23.240.0/21 (path: 2914 4837 64920 ) 60.23.248.0/21 (path: 2914 4837 64920 ) 60.23.248.0/24 (path: 2914 4837 65501 ) 60.23.249.0/24 (path: 2914 4837 65501 ) 60.23.246.0/24 (path: 2914 4837 65501 ) 60.23.247.0/24 (path: 2914 4837 65501 ) 64.27.240.0/20 (path: 2914 209 16931 ) contains: 64.27.253.0/24 (path: 2914 1273 65538 ) 64.72.224.0/19 (path: 2914 6327 6407 6407 ) contains: 64.72.224.0/24 (path: 2914 812 812 812 4264800033 ) 64.72.226.0/24 (path: 2914 812 812 812 4264800033 ) 64.72.227.0/24 (path: 2914 812 812 812 4264800033 ) 64.83.64.0/20 (path: 2914 7029 ) contains: 64.83.78.0/24 (path: 2914 7029 1785 65233 ) 66.110.192.0/19 (path: 2914 174 31877 ) contains: 66.110.220.0/24 (path: 2914 40111 40111 65003 ) 66.110.218.0/24 (path: 2914 40111 40111 65003 ) 66.110.219.0/24 (path: 2914 40111 40111 65003 ) 66.134.0.0/16 (path: 2914 2828 18566 ) contains: 66.134.62.0/24 (path: 2914 2828 18566 65505 ) 66.134.72.0/24 (path: 2914 2828 18566 65505 ) 66.134.75.0/24 (path: 2914 2828 18566 65505 ) 66.194.0.0/16 (path: 2914 3356 4323 ) contains: 66.194.233.0/24 (path: 2914 174 36188 65009 ) 67.100.0.0/14 (path: 2914 2828 18566 ) contains: 67.103.100.0/23 (path: 2914 2828 18566 65505 ) 67.100.42.0/24 (path: 2914 2828 18566 65515 ) 67.206.64.0/19 (path: 2914 2828 16399 26895 ) contains: 67.206.84.0/24 (path: 2914 2828 16399 26895 64533 64533 64533 64533 64533 64533 64533 ) 69.10.192.0/19 (path: 2914 11404 18530 18530 30170 20394 ) contains: 69.10.192.0/20 (path: 2914 20394 65503 65530 ) 69.166.128.0/19 (path: 2914 7029 7349 ) contains: 69.166.142.0/24 (path: 2914 7029 7349 64900 ) 70.128.0.0/12 (path: 2914 7018 ) contains: 70.134.46.0/24 (path: 2914 14265 46926 65001 46926 46926 46926 46926 46926 46926 46926 46926 ) 71.252.0.0/17 (path: 2914 701 ) contains: 71.252.67.0/24 (path: 2914 701 64512 ) 72.15.144.0/20 (path: 2914 812 812 812 ) contains: 72.15.149.0/24 (path: 2914 6461 15290 19835 812 812 812 812 4264800030 ) 74.213.144.0/20 (path: 2914 7029 7349 ) contains: 74.213.146.0/24 (path: 2914 7029 7349 64900 ) 79.139.72.0/21 (path: 2914 174 24709 29232 ) contains: 79.139.76.0/24 (path: 2914 174 24709 29232 65007 ) 79.139.77.0/24 (path: 2914 174 24709 29232 65008 ) 79.172.0.0/18 (path: 2914 174 5563 ) contains: 79.172.48.0/24 (path: 2914 9002 5563 65300 5563 ) 79.172.7.0/24 (path: 2914 9002 5563 65300 5563 ) 79.172.16.0/21 (path: 2914 9002 5563 65300 5563 ) 8.0.0.0/8 (path: 2914 3356 ) contains: 8.41.195.0/24 (path: 2914 13789 13789 13789 13789 30372 65603 ) 80.90.160.0/20 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) contains: 80.90.160.0/21 (path: 2914 3257 48832 48832 48832 48832 48832 48832 48832 48832 48832 48832 65545 ) 82.113.96.0/19 (path: 2914 6805 39706 ) contains: 82.113.112.0/23 (path: 2914 6805 39706 65002 ) 82.113.124.0/22 (path: 2914 6805 39706 65004 ) 84.44.0.0/17 (path: 2914 8928 15924 ) contains: 84.44.37.0/24 (path: 2914 8928 15924 65121 ) 86.51.0.0/16 (path: 2914 3257 48237 35819 ) contains: 86.51.177.0/24 (path: 2914 3356 48237 35819 65557 ) 91.229.96.0/22 (path: 2914 12389 25549 56957 56957 56957 56957 56957 ) contains: 91.229.99.0/24 (path: 2914 12389 25549 56957 56957 56957 56957 56957 65157 ) 91.230.232.0/24 (path: 2914 31313 48338 ) contains: 91.230.232.128/27 (path: 2914 31313 48338 65534 ) 92.240.218.0/23 (path: 2914 9002 39735 ) contains: 92.240.218.0/24 (path: 2914 9002 39735 65001 ) 92.240.219.0/24 (path: 2914 9002 39735 65001 ) 92.245.128.0/19 (path: 2914 6461 8218 48072 ) contains: 92.245.153.0/24 (path: 2914 1299 29075 48072 48072 65623 31167 ) 92.245.154.0/23 (path: 2914 1299 29075 48072 48072 65623 31167 ) 92.245.146.0/24 (path: 2914 174 48072 31167 65623 ) 92.245.148.0/24 (path: 2914 174 48072 31167 65623 ) 92.245.141.0/24 (path: 2914 1299 29075 48072 48072 65623 31167 ) 92.245.128.0/24 (path: 2914 174 48072 31167 65623 ) 92.245.134.0/24 (path: 2914 6461 8218 48072 48072 65623 31167 ) 92.245.135.0/24 (path: 2914 6461 8218 48072 48072 65623 31167 ) 93.170.0.0/15 (path: 2914 3257 50245 44546 ) contains: 93.171.227.0/24 (path: 2914 12389 34205 34205 65001 61014 ) 94.103.16.0/20 (path: 2914 47886 ) contains: 94.103.25.0/24 (path: 2914 174 36180 64842 ) 94.247.224.0/21 (path: 2914 702 3252 12963 ) contains: 94.247.231.0/24 (path: 2914 702 3252 12963 64564 ) From chuckchurch at gmail.com Wed Jun 8 14:42:25 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 8 Jun 2016 10:42:25 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <049401d1c193$fad7b950$f0872bf0$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Elvis Daniel Velea Sent: Tuesday, June 07, 2016 6:36 PM To: nanog at nanog.org Subject: Re: Netflix banning HE tunnels Netflix, YOU are the ones forcing people to turn IPv4 off... this is just insane. tens (if not hundred) of thousands of people chose to use HE tunnels because their ISP does not offer IPv6.. do you really expect all of them to turn it off? do you really want IPv6 usage in the world to go down by a few percent because you are unable to figure out how to serve content? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ I hate to say it, but I'm willing to bet that for every one person who setup an HE tunnel to get functional IPv6 ahead of native via ISP, there are probably 10 who set it up solely to get around geo-lockout. Honestly though, is there any reason the Netflix 'client' as part of its login can't be queried for an IPv4 address if Netflix sees (or thinks) a tunnel is involved? If there is a tunnel involved, you most likely have IPv4 access on the client. Then do a geo-lookup on the IPv4. I guess the ~500 people on NANOG using HE to get to NetFlix could all cancel their subscriptions, but that's just a drop of water in the bucket. It sucks. The true jerks who used HE to bypass geo-lockout probably changed to something else the next day. But we suffer still. The FCC or some other federal entity probably needs to step in. Chuck From baldur.norddahl at gmail.com Wed Jun 8 15:13:04 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 8 Jun 2016 17:13:04 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160608052705.15C904B00B9F@rock.dv.isc.org> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> Message-ID: <57583600.3020902@gmail.com> On 2016-06-08 07:27, Mark Andrews wrote: > In message <20160608070525.06fd5995 at echo.ms.redpill-linpro.com>, Tore Anderson writes: >> * Davide Davini >> >> Blocking access to Netflix via the tunnel seems like an obvious >> solution to me, for what it's worth. > And which set of prefixes is that? How often do they change? etc. > A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) and I am not blocked from accessing Netflix over IPv6 so can't really try it. I am curious however that none of the vocal HE tunnel users here appears to have tried even simple counter measures such as a simple firewall rule to drop traffic to that one /64 prefix. It might be that more needs to be blocked, but in that case it will be trivial to find the required prefixes by launching Wireshark and observe the IPv6 traffic generated when accessing netflix.com. Maybe someone could do that and post the results, as it is apparent that many people are in need of a solution. Regards, Baldur From owen at delong.com Wed Jun 8 15:19:52 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 11:19:52 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> > On Jun 7, 2016, at 11:25 PM, Ca By wrote: > > On Tuesday, June 7, 2016, chris wrote: > >> I disagree. if they have no native v6 then theres no reason why they >> shouldnt be able to use the v6 from HE and why should the internet treat >> that users traffic any differently because its coming from HE or tunneled? >> >> > This is not about ipv6, it is about an anonymous tunnel. Contrary to your repeated assertions, HE tunnels are NOT anonymous. HE operates a perfectly fine RWHOIS server that provides sufficient information about each tunnel that it cannot be considered anonymous. > > >> Theres also tons of folks affected who arent on HE, arent tunneling, etc. >> Theres been many people affected who are being told something is wrong with >> their network that works fine for anything other than netflix. >> >> chris >> > > Agreed. This is also not about ipv6. Doing geo-location based DRM is hard > and IMHO painful for all parties involved. > > My point is IPv6 should not be the collateral damage or conflated in an > issue that has nothing to do ipv6. This is about an anonymous tunnel > service and strict DRM rules. No, Cameron, this is about Netflix telling people to turn off IPv6. Admittedly, the above issues are what is leading them to this point, but their proposed solution ?turn off IPv6? remains the core problem being raised here. > IPv6 works fine. Tunnels and VPN and Netflix do not work fine. This is like saying ?airplanes work fine, it?s just airlines that suck.? While it?s technically true, airlines are the only experience of airplanes that most people every get access to. Owen > > CB > >> >> >> On Tue, Jun 7, 2016 at 11:10 PM, Ca By > > wrote: >> >>> >>> >>> On Tuesday, June 7, 2016, chris >> > wrote: >>> >>>> it really feels alot like what net neutrality was supposed to avoid. >>>> making >>>> a policy where there is different treatment of one set of bits over >>>> another >>>> >>>> "your ipv6 bits are bad but if you turn it off the ipv4 bits are just >>>> fine" >>>> >>>> someone mentioned the fact that netflix is not just a content company but >>>> also acting as a network operator maybe the two should be separate >>>> >>>> i also find it ironic that they arent big fans of ISPs who use NAT or CGN >>>> and dont have 1 customer per IP yet their stifiling ipv6 and telling >>>> users >>>> to turn it off. you really cant have it both ways and complain about NAT >>>> and also say you recommend shutting off ipv6 :) >>>> >>>> hopefully they will realize imposing their own policy on how customers >>>> use >>>> their networks and the internet this isnt worth losing customers over >>>> >>>> chris >>>> >>>> >>> >>> Again. An HE tunnel is not production ipv6. It is a toy. >>> >>> Telling people to turn of HE tunnel is NOT the same as turning off >>> production ipv6. >>> >>> CB >>> >>> >>> >>>> On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea >>>> wrote: >>>> >>>>> apparently, all they see is 3 people complaining on this mailing list.. >>>>> well, this makes it 4 with me (and I have a bunch of people in various >>>>> countries complaining on facebook that they have been banned from using >>>>> netflix because they use an HE tunnel. >>>>> >>>>> their answer - TURN IPV6 OFF!!! you're a techie so if you know how to >>>>> setup a tunnel, you must know how to redirect netflix to use IPv4 >>>> only... >>>>> really? >>>>> the answer just pisses me off! >>>>> >>>>> Netflix, YOU are the ones forcing people to turn IPv4 off... this is >>>> just >>>>> insane. tens (if not hundred) of thousands of people chose to use HE >>>>> tunnels because their ISP does not offer IPv6.. >>>>> do you really expect all of them to turn it off? do you really want >>>> IPv6 >>>>> usage in the world to go down by a few percent because you are unable >>>> to >>>>> figure out how to serve content? >>>>> >>>>> I know nobody at Netflix will even answer to the e-mails on this list.. >>>>> but I hope that they will at least acknowledge the problem and figure >>>> an >>>>> other way to block content by country. >>>>> ie: they could try to talk to HE to register each tunnel in a database >>>>> that points to the country of the user.. >>>>> >>>>> cheers, >>>>> elvis >>>>> >>>>> >>>>> On 6/8/16 1:01 AM, chris wrote: >>>>> >>>>>> I am also in the same boat with a whole subnet affected even without a >>>>>> tunnel, tried multiple netflix support channels starting in early >>>> march >>>>>> and >>>>>> the ranges is still blocked 3 months later. >>>>>> >>>>>> I was a big fan of the service and somewhat of an addict up till this >>>> but >>>>>> I've really been shocked how this has been (mis)handled >>>>>> >>>>>> chris >>>>>> >>>>>> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini >>>>>> wrote: >>>>>> >>>>>> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" >>>> and I >>>>>>> can't use it if I don't disable the HE tunnel, which is the only way >>>> for >>>>>>> me to have IPv6 at the moment. >>>>>>> >>>>>>> But the fun part has been Netflix tech support: >>>>>>> "Oh I see, yeah we have been receiving reports of some other members >>>>>>> with ipv6 having this issues, at the moment Netflix is not really >>>>>>> designed to work with ipv6 connections, in this case I can recommend >>>> you >>>>>>> two things, one is to turn off the ipv6 and the other one will be to >>>>>>> contact directly with Hurricane Electric, there are some customers >>>> that >>>>>>> were able to use Netflix with an ipv6 under some specific settings >>>> set >>>>>>> by Hurricane Electric." >>>>>>> >>>>>>> I don't obviously expect HE to fix it, I don't pay for shit, it's a >>>> free >>>>>>> service, why should they? >>>>>>> >>>>>>> But it's fun to know that " Netflix is not really designed to work >>>> with >>>>>>> ipv6 connections ". >>>>>>> >>>>>>> Who did it say on this ML that the best way to solve these issues is >>>>>>> Netflix tech support? :) >>>>>>> >>>>>>> Ciao, >>>>>>> Davide Davini >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> From owen at delong.com Wed Jun 8 15:23:35 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 11:23:35 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: Mark, That would be bad. At least in my case. My addresses (192.159.10.0/24, 192.124.40.0/23, 2620:0:930::/48) are not from a known residential ISP or mobile ISP. However, they are within my household and nowhere else. There?s no valid reason for Netflix to block them. They are not a server or proxy host. They are not being used to subvert geo-fencing. They?re just my home addresses that I have had for many years and use in order to have stable addressing across provider changes. Owen > On Jun 7, 2016, at 9:21 AM, Mark Felder wrote: > > >> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >> >> The tunnelbroker service acts exactly like a VPN. It allows you, from any >> arbitrary location in the world with an IPv4 address, to bring traffic out >> via one of HE's 4 POP's, while completely masking your actual location. >> > > Perhaps Netflix should automatically block any connection that's not from a known residential ISP or mobile ISP as anything else could be a server someone is proxying through. It's very easy to get these subnets -- the spam filtering folks have these subnets well documented. /s > > -- > Mark Felder > feld at feld.me > From cma at cmadams.net Wed Jun 8 15:30:31 2016 From: cma at cmadams.net (Chris Adams) Date: Wed, 8 Jun 2016 10:30:31 -0500 Subject: Netflix banning HE tunnels In-Reply-To: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> Message-ID: <20160608153031.GA2257@cmadams.net> Once upon a time, Owen DeLong said: > Contrary to your repeated assertions, HE tunnels are NOT anonymous. > > HE operates a perfectly fine RWHOIS server that provides sufficient information > about each tunnel that it cannot be considered anonymous. Unless that information is verified, it is effectively anonymous. I had an HE tunnel years ago, and the only verified information was my email address. -- Chris Adams From steve at blighty.com Wed Jun 8 15:30:40 2016 From: steve at blighty.com (Steve Atkins) Date: Wed, 8 Jun 2016 08:30:40 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <57583600.3020902@gmail.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> <57583600.3020902@gmail.com> Message-ID: <16D93209-0A87-49FE-81BE-0524062389A5@blighty.com> > On Jun 8, 2016, at 8:13 AM, Baldur Norddahl wrote: > > > > On 2016-06-08 07:27, Mark Andrews wrote: >> In message <20160608070525.06fd5995 at echo.ms.redpill-linpro.com>, Tore Anderson writes: >>> * Davide Davini >>> >>> Blocking access to Netflix via the tunnel seems like an obvious >>> solution to me, for what it's worth. >> And which set of prefixes is that? How often do they change? etc. >> > > A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) and I am not blocked from accessing Netflix over IPv6 so can't really try it. I am curious however that none of the vocal HE tunnel users here appears to have tried even simple counter measures such as a simple firewall rule to drop traffic to that one /64 prefix. > > It might be that more needs to be blocked, but in that case it will be trivial to find the required prefixes by launching Wireshark and observe the IPv6 traffic generated when accessing netflix.com. Maybe someone could do that and post the results, as it is apparent that many people are in need of a solution. I don't think that "getting to Netflix over an HE tunnel" is something that people here need a solution to, rather it's "stopping Netflix from discouraging IPv6 usage" or perhaps "encouraging Netflix to stop breaking service to IPv6 users, including their lack of support for IPv4 fallback". The connection to NANOG isn't that NANOG users want to reach Netflix, it's that NANOG users have an interest in the broader health of the IPv6 ecosystem. Given the number of pieces of off-the-shelf packaged software that are designed to allow the end-user, with no technical expertise required, to proxy through an HE tunnel so as to avoid Netflix geolocation[1] I don't blame Netflix for blocking HE tunnels, but I do blame them for doing so badly. Cheers, Steve [1] e.g. https://github.com/ab77/netflix-proxy From john-nanog at peachfamily.net Wed Jun 8 15:33:44 2016 From: john-nanog at peachfamily.net (John Peach) Date: Wed, 8 Jun 2016 11:33:44 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <20160608153031.GA2257@cmadams.net> References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> Message-ID: <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> Mine, whilst not identifying me personally, has detail down to the correct town and zipcode. On Wed, 8 Jun 2016 10:30:31 -0500 Chris Adams wrote: > Once upon a time, Owen DeLong said: > > Contrary to your repeated assertions, HE tunnels are NOT anonymous. > > > > HE operates a perfectly fine RWHOIS server that provides sufficient > > information about each tunnel that it cannot be considered > > anonymous. > > Unless that information is verified, it is effectively anonymous. I > had an HE tunnel years ago, and the only verified information was my > email address. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From sryan at arbor.net Wed Jun 8 15:37:59 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 8 Jun 2016 11:37:59 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> Message-ID: It identifys where you told it you are. It doesn't tell Netflix that your v4 endpoint is in New Zeland and you are watching a bunch of content you are not supposed to have access to. Is this really that hard to understand? *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 8, 2016 at 11:33 AM, John Peach wrote: > Mine, whilst not identifying me personally, has detail down to the > correct town and zipcode. > > > On Wed, 8 Jun 2016 10:30:31 -0500 > Chris Adams wrote: > > > Once upon a time, Owen DeLong said: > > > Contrary to your repeated assertions, HE tunnels are NOT anonymous. > > > > > > HE operates a perfectly fine RWHOIS server that provides sufficient > > > information about each tunnel that it cannot be considered > > > anonymous. > > > > Unless that information is verified, it is effectively anonymous. I > > had an HE tunnel years ago, and the only verified information was my > > email address. > > > From nwolff at oar.net Wed Jun 8 15:40:44 2016 From: nwolff at oar.net (Wolff, Nick) Date: Wed, 8 Jun 2016 15:40:44 +0000 Subject: Traffic engineering and peering for CDNs In-Reply-To: <276869f3-d10a-8b44-795c-cb6673c7082f@seacom.mu> References: <82C0CE81789FE64D8F4D152631918297B18660@MSG6.westman.int> <125980230.9402.1465235590241.JavaMail.mhammett@ThunderFuck> <276869f3-d10a-8b44-795c-cb6673c7082f@seacom.mu> Message-ID: On 6/7/16, 2:46 AM, "NANOG on behalf of Mark Tinka" wrote: > > >On 6/Jun/16 20:03, Tom Smyth wrote: > >> as far as im aware ... a friend of mine on INEX in Ireland said most >>cdns >> use source ip of the DNS requests to determine which network to direct >>them >> to ... so if you use you have your own resolver on an ip address in >>your >> network range cdns can accurately determine what network the request is >> comming from and determine what ip address / what network that the cdn >>has >> nearest to your network... >> >> ff you use 3rd party dns servers for your clients... you may not get an >> optimal ip answer for your dns queries from the CDNS involved > >Some CDN's use DNS (in addition to latency, congestion levels, busy >state, e.t.c.). > >Others use Anycast routing, which I tend to prefer. The problem is the >latter run a network while the former may typically not. > >Mark. Also some companies make layer 7 decisions for their CDN?s in conjunction with these other methods. Their applications makes a decision on what host to send you to based on routing information, your source address, and other accumulated data. From feld at feld.me Wed Jun 8 15:44:55 2016 From: feld at feld.me (Mark Felder) Date: Wed, 08 Jun 2016 10:44:55 -0500 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <1465400695.1461263.631757641.29996664@webmail.messagingengine.com> On Wed, Jun 8, 2016, at 10:23, Owen DeLong wrote: > Mark, > > That would be bad. > > At least in my case. > The trailing /s at the end was the sarcasm tag :-) -- Mark Felder feld at feld.me From hugo at slabnet.com Wed Jun 8 15:49:54 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 8 Jun 2016 08:49:54 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <20160608154954.GI6467@bamboo.slabnet.com> On Wed 2016-Jun-08 11:23:35 -0400, Owen DeLong wrote: >> On Jun 7, 2016, at 9:21 AM, Mark Felder wrote: >> >> >>> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>> >>> The tunnelbroker service acts exactly like a VPN. It allows you, from any >>> arbitrary location in the world with an IPv4 address, to bring traffic out >>> via one of HE's 4 POP's, while completely masking your actual location. >>> >> >> Perhaps Netflix should automatically block any connection that's not from a known residential ISP or mobile ISP as anything else could be a server someone is proxying through. It's very easy to get these subnets -- the spam filtering folks have these subnets well documented. /s >> >> -- >> Mark Felder >> feld at feld.me >Mark, > >That would be bad. The "/s" was of particular importance in Mark's email and I believe intended to apply to the whole line of reasoning, not just the "it's easy to get those blocks" section at the end. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From elvis at velea.eu Wed Jun 8 15:54:31 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 8 Jun 2016 18:54:31 +0300 Subject: Netflix banning HE tunnels In-Reply-To: References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> Message-ID: <-2653102140228768616@unknownmsgid> So, how do you identify where an IP address is used? /elvis Excuse the briefness of this mail, it was sent from a mobile device. > On Jun 8, 2016, at 18:41, Spencer Ryan wrote: > > It identifys where you told it you are. It doesn't tell Netflix that your > v4 endpoint is in New Zeland and you are watching a bunch of content you > are not supposed to have access to. > > Is this really that hard to understand? > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Wed, Jun 8, 2016 at 11:33 AM, John Peach > wrote: > >> Mine, whilst not identifying me personally, has detail down to the >> correct town and zipcode. >> >> >> On Wed, 8 Jun 2016 10:30:31 -0500 >> Chris Adams wrote: >> >>> Once upon a time, Owen DeLong said: >>>> Contrary to your repeated assertions, HE tunnels are NOT anonymous. >>>> >>>> HE operates a perfectly fine RWHOIS server that provides sufficient >>>> information about each tunnel that it cannot be considered >>>> anonymous. >>> >>> Unless that information is verified, it is effectively anonymous. I >>> had an HE tunnel years ago, and the only verified information was my >>> email address. >> From nsuan at nonexiste.net Wed Jun 8 15:58:23 2016 From: nsuan at nonexiste.net (Nicholas Suan) Date: Wed, 8 Jun 2016 11:58:23 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <57583600.3020902@gmail.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> <57583600.3020902@gmail.com> Message-ID: On Wednesday, June 8, 2016, Baldur Norddahl wrote: > > > On 2016-06-08 07:27, Mark Andrews wrote: > >> In message <20160608070525.06fd5995 at echo.ms.redpill-linpro.com>, Tore >> Anderson writes: >> >>> * Davide Davini >>> >>> Blocking access to Netflix via the tunnel seems like an obvious >>> solution to me, for what it's worth. >>> >> And which set of prefixes is that? How often do they change? etc. >> >> > A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS > lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) > and I am not blocked from accessing Netflix over IPv6 so can't really try > it. I am curious however that none of the vocal HE tunnel users here > appears to have tried even simple counter measures such as a simple > firewall rule to drop traffic to that one /64 prefix. > That's a start but Netflix has a few more prefixes than that: http://bgp.he.net/AS2906#_prefixes6 From ahebert at pubnix.net Wed Jun 8 15:59:44 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 8 Jun 2016 11:59:44 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> Message-ID: Well, They're clearly to " enraged " to accept/comprehend the situation. Lets go back talking about how to help deploy IPv6 and break the paradigm that was build during the silent film era. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 06/08/16 11:37, Spencer Ryan wrote: > It identifys where you told it you are. It doesn't tell Netflix that your > v4 endpoint is in New Zeland and you are watching a bunch of content you > are not supposed to have access to. > > Is this really that hard to understand? > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Wed, Jun 8, 2016 at 11:33 AM, John Peach > wrote: > >> Mine, whilst not identifying me personally, has detail down to the >> correct town and zipcode. >> >> >> On Wed, 8 Jun 2016 10:30:31 -0500 >> Chris Adams wrote: >> >>> Once upon a time, Owen DeLong said: >>>> Contrary to your repeated assertions, HE tunnels are NOT anonymous. >>>> >>>> HE operates a perfectly fine RWHOIS server that provides sufficient >>>> information about each tunnel that it cannot be considered >>>> anonymous. >>> Unless that information is verified, it is effectively anonymous. I >>> had an HE tunnel years ago, and the only verified information was my >>> email address. >>> From javier at advancedmachines.us Wed Jun 8 16:04:22 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 8 Jun 2016 12:04:22 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <-2653102140228768616@unknownmsgid> References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> <-2653102140228768616@unknownmsgid> Message-ID: Getting back on topic here, the biggest group to blame here is the content producers and the MPAA who insist on only giving licenses out for content on a regional/country basis, and I would bet the balance of my bank account that they have forced netflix to block VPNs Tunnels and anything else by force, in order to keep the licensed content they have. Remember that the industry has been at war with Netflix from the beginning, the cable companies (some are also content producers) hate netflix. I am sure that netflix doesn't give a crap where you are located as long as you pay the subscription, it is their licensing agreements for content that has forced their hand and created this mess. Shame on the content producers, and shame on the MPAA. - J On Wed, Jun 8, 2016 at 11:54 AM, Elvis Daniel Velea wrote: > So, how do you identify where an IP address is used? > > /elvis > > Excuse the briefness of this mail, it was sent from a mobile device. > > > On Jun 8, 2016, at 18:41, Spencer Ryan wrote: > > > > It identifys where you told it you are. It doesn't tell Netflix that your > > v4 endpoint is in New Zeland and you are watching a bunch of content you > > are not supposed to have access to. > > > > Is this really that hard to understand? > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > *Arbor Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Wed, Jun 8, 2016 at 11:33 AM, John Peach > > wrote: > > > >> Mine, whilst not identifying me personally, has detail down to the > >> correct town and zipcode. > >> > >> > >> On Wed, 8 Jun 2016 10:30:31 -0500 > >> Chris Adams wrote: > >> > >>> Once upon a time, Owen DeLong said: > >>>> Contrary to your repeated assertions, HE tunnels are NOT anonymous. > >>>> > >>>> HE operates a perfectly fine RWHOIS server that provides sufficient > >>>> information about each tunnel that it cannot be considered > >>>> anonymous. > >>> > >>> Unless that information is verified, it is effectively anonymous. I > >>> had an HE tunnel years ago, and the only verified information was my > >>> email address. > >> > From owen at delong.com Wed Jun 8 16:12:23 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 12:12:23 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <0A15922F-B537-43E4-A266-D1C2BF3D6E8F@delong.com> > On Jun 7, 2016, at 10:22 AM, Ca By wrote: > > On Tuesday, June 7, 2016, Cryptographrix wrote: > >> As I said to Netflix's tech support - if they advocate for people to turn >> off IPv6 on their end, maybe Netflix should stop supporting it on their >> end. >> >> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >> the moment, and if their tech support is telling people to turn off IPv6, >> maybe they should just instead remove their AAAA records. >> >> (or fail back to ipv4 when v6 looks like a tunnel) >> >> > I think you need to reset your expectations of a free tunnel service. > > he.net tunnels are a toy for geeks looking to play with v6. In terms of > Netflix subcriber base, it is amazing insignificant number of users. If it?s so insignificant, why did Netflix go to the effort to implement blocking based on address ranges associated with those tunnels? > At the end of the day, anonymous tunnels, just like linux, are not > supported by Netflix. And, he.net tunnel users are hurting ipv6 overall > just like 6to4 by injecting FUD and other nonesense complexity.... For a > toy. I disagree. Calling he.net tunnels a toy is absurd. It?s a link, just like any other link, over which IPv6 can be transmitted. You can argue that it?s a lower quality link than some alternatives, but I have to tell you I?ve gotten much more reliable service at higher bandwidth from that link than from my T-Mobile LTE service, so I?d argue that it is a higher quality service than T-Mobile. It?s not the only link I have for my IPv6 packets, in fact, it is one of three links over which my IPv6 packets are able to travel. > Move on to a real issue instead of beating this dead horse. So we should start beating on unreliable LTE services instead? ;-) Owen > > CB > > >> >> >> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder > >> wrote: >> >>> >>>> On Jun 6, 2016, at 22:25, Spencer Ryan > >> wrote: >>>> >>>> The tunnelbroker service acts exactly like a VPN. It allows you, from >> any >>>> arbitrary location in the world with an IPv4 address, to bring traffic >>> out >>>> via one of HE's 4 POP's, while completely masking your actual location. >>>> >>> >>> Perhaps Netflix should automatically block any connection that's not from >>> a known residential ISP or mobile ISP as anything else could be a server >>> someone is proxying through. It's very easy to get these subnets -- the >>> spam filtering folks have these subnets well documented. /s >>> >>> -- >>> Mark Felder >>> feld at feld.me >>> >>> >> From owen at delong.com Wed Jun 8 16:13:28 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 12:13:28 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <7f4454ef-51df-b97b-4315-e5efd27771fb@heliacal.net> <20160603212808.61A794AC8EC8@rock.dv.isc.org> <9578293AE169674F9A048B2BC9A081B401E661A0BD@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401E661A134@MUNPRDMBXA1.medline.com> <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> Message-ID: <649828D1-3D86-4852-9584-409D07260E65@delong.com> As of last week, I still wasn?t getting an IPv6 address by default on my iPhone 6S+ on T-Mobile. Just saying. Owen > On Jun 7, 2016, at 11:00 AM, Ca By wrote: > > On Tuesday, June 7, 2016, Cryptographrix wrote: > >> Very true - I was being a bit extremist out of frustration, but I think >> you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6 >> support, not actually IPv6 support. >> >> And I'm quite frustrated because there's so little actual v6 support, and >> I *do* actually need it on a daily basis for work. >> >> Because there's no actual ISP IPv6 support anywhere else (in parts of the >> US that *have* multiple ISPs), you can't even make the case to your ISP >> that it's a legitimate requirement for you because they know you're not >> really going to get v6 elsewhere. >> >> > I think we have different definitions of "no actual isp ipv6 support" > > Again, a helpful akamai blog > https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html > > fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have > meaningful deployments of ipv6. The only thing holding back greater > deployment for those networks are legacy CPE that will age out slowly. > > All 4 of the national mobile operator have ipv6 default on for most > new phone models. > > Yes, many gaps to fill still. But, on "my network" with shy of 70 million > users, everything has ipv6 except the iPhone, and that will change RSN. And > for users with v6, the majority of their traffic is ipv6 e2e since the > whales (google, fb, netflix, increasingly Akamai) are dual stack. > > CB > > >> >> >> On Tue, Jun 7, 2016 at 10:22 AM Ca By > > wrote: >> >>> >>> >>> On Tuesday, June 7, 2016, Cryptographrix >> > wrote: >>> >>>> As I said to Netflix's tech support - if they advocate for people to turn >>>> off IPv6 on their end, maybe Netflix should stop supporting it on their >>>> end. >>>> >>>> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >>>> the moment, and if their tech support is telling people to turn off IPv6, >>>> maybe they should just instead remove their AAAA records. >>>> >>>> (or fail back to ipv4 when v6 looks like a tunnel) >>>> >>>> >>> I think you need to reset your expectations of a free tunnel service. >>> >>> he.net tunnels are a toy for geeks looking to play with v6. In terms of >>> Netflix subcriber base, it is amazing insignificant number of users. >>> >>> At the end of the day, anonymous tunnels, just like linux, are not >>> supported by Netflix. And, he.net tunnel users are hurting ipv6 overall >>> just like 6to4 by injecting FUD and other nonesense complexity.... For a >>> toy. >>> >>> Move on to a real issue instead of beating this dead horse. >>> >>> CB >>> >>> >>>> >>>> >>>> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: >>>> >>>>> >>>>>> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>>>>> >>>>>> The tunnelbroker service acts exactly like a VPN. It allows you, >>>> from any >>>>>> arbitrary location in the world with an IPv4 address, to bring >>>> traffic >>>>> out >>>>>> via one of HE's 4 POP's, while completely masking your actual >>>> location. >>>>>> >>>>> >>>>> Perhaps Netflix should automatically block any connection that's not >>>> from >>>>> a known residential ISP or mobile ISP as anything else could be a >>>> server >>>>> someone is proxying through. It's very easy to get these subnets -- the >>>>> spam filtering folks have these subnets well documented. /s >>>>> >>>>> -- >>>>> Mark Felder >>>>> feld at feld.me >>>>> >>>>> >>>> >>> From owen at delong.com Wed Jun 8 16:17:36 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 12:17:36 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> Message-ID: > On Jun 7, 2016, at 11:50 AM, Davide Davini wrote: > > On 04/06/2016 20:46, Owen DeLong wrote: >> Get your own /48 and advertise to HE Tunnel via BGP. Problem solved. > > Even though that sounds like an awesome idea it does not seem trivial to > me to obtain your own /48. It?s trivial in the ARIN region. Other regions are YMMV. > I mean: "You can only request IPv6 assignments and Autonomous System > Numbers through a Sponsoring LIR (a RIPE NCC member)" > https://www.ripe.net/manage-ips-and-asns/resource-management/number-resources/independent-resources I would suggest trying to work through the RIPE PDWG to get that policy changed if you feel it is a hinderance to your deployment. I do know that RIPE has this (rather silly IMHO) process for keeping PI end users at arms length, but as I understand it, it?s also not very hard to find an LIR that will charge you a fee to acquire the addresses and pass them along to you. > But you know, my knowledge on the matter is half an hour old, I might be > dead wrong. I think you?re right, but my understanding is that it is fairly trivial to comply with that requirement. I?ll be surprised if some LIRs don?t contact you as a result of this email. Owen From laszlo at heliacal.net Wed Jun 8 16:23:35 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 8 Jun 2016 16:23:35 +0000 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <0A15922F-B537-43E4-A266-D1C2BF3D6E8F@delong.com> References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> <0A15922F-B537-43E4-A266-D1C2BF3D6E8F@delong.com> Message-ID: <62285ddd-b85f-0723-8cc6-d0f6820864e3@heliacal.net> On 2016-06-08 16:12, Owen DeLong wrote: > > It?s a link, just like any other link, over which IPv6 can be transmitted. > You can argue that it?s a lower quality link than some alternatives, but I have > to tell you I?ve gotten much more reliable service at higher bandwidth from > that link than from my T-Mobile LTE service, so I?d argue that it is a higher > quality service than T-Mobile. > > Well there is one good thing that might come out of this if you're a tunnel user.. the tunnels can have even more bandwidth now, with all the Netflix traffic moving off them. I have no special visibility into how (over)loaded they are, just speculating. -Laszlo From baldur.norddahl at gmail.com Wed Jun 8 17:03:55 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 8 Jun 2016 19:03:55 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> <57583600.3020902@gmail.com> Message-ID: <57584FFB.7080805@gmail.com> On 2016-06-08 17:58, Nicholas Suan wrote: > > > On Wednesday, June 8, 2016, Baldur Norddahl > wrote: > > > A start would be blocking 2620:108:700f::/64 as discovered by a > simple DNS lookup on netflix.com . I am not > running a HE tunnel (I got native IPv6) and I am not blocked from > accessing Netflix over IPv6 so can't really try it. I am curious > however that none of the vocal HE tunnel users here appears to > have tried even simple counter measures such as a simple firewall > rule to drop traffic to that one /64 prefix. > > > That's a start but Netflix has a few more prefixes than that: > http://bgp.he.net/AS2906#_prefixes6 They do but that is irrelevant. Blocking just that one /64 prefix works because that is where their tunnel detector apparently lives. I think we are at the point where we can say it would be nice if Netflix could just redirect users from IPv6 to IPv4 when a tunnel is suspected. They do deserve flames for being bad guys here when they have such an easy out. But you can also just fix the issue yourself with a simple firewall rule. Regards, Baldur From baldur.norddahl at gmail.com Wed Jun 8 17:06:28 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 8 Jun 2016 19:06:28 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> <57583600.3020902@gmail.com> Message-ID: <57585094.9030800@gmail.com> On 2016-06-08 17:20, Javier J wrote: > > Maybe I missed the start of this conversation but why are we talking > about blocking Netflix? > By blocking the netflix.com IPv6 prefix your browser will automatically fall back to IPv4 because it is using the Happy Eyeballs algorithm. From joelja at bogus.com Wed Jun 8 17:25:00 2016 From: joelja at bogus.com (joel jaeggli) Date: Wed, 8 Jun 2016 10:25:00 -0700 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <649828D1-3D86-4852-9584-409D07260E65@delong.com> References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> <649828D1-3D86-4852-9584-409D07260E65@delong.com> Message-ID: <452a456d-1a73-2b9c-5806-b43f57d9f39f@bogus.com> On 6/8/16 9:13 AM, Owen DeLong wrote: > As of last week, I still wasn?t getting an IPv6 address by default on my iPhone 6S+ > on T-Mobile. turn off mobile hotspot... > Just saying. > > Owen > >> On Jun 7, 2016, at 11:00 AM, Ca By wrote: >> >> On Tuesday, June 7, 2016, Cryptographrix wrote: >> >>> Very true - I was being a bit extremist out of frustration, but I think >>> you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6 >>> support, not actually IPv6 support. >>> >>> And I'm quite frustrated because there's so little actual v6 support, and >>> I *do* actually need it on a daily basis for work. >>> >>> Because there's no actual ISP IPv6 support anywhere else (in parts of the >>> US that *have* multiple ISPs), you can't even make the case to your ISP >>> that it's a legitimate requirement for you because they know you're not >>> really going to get v6 elsewhere. >>> >>> >> I think we have different definitions of "no actual isp ipv6 support" >> >> Again, a helpful akamai blog >> https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html >> >> fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have >> meaningful deployments of ipv6. The only thing holding back greater >> deployment for those networks are legacy CPE that will age out slowly. >> >> All 4 of the national mobile operator have ipv6 default on for most >> new phone models. >> >> Yes, many gaps to fill still. But, on "my network" with shy of 70 million >> users, everything has ipv6 except the iPhone, and that will change RSN. And >> for users with v6, the majority of their traffic is ipv6 e2e since the >> whales (google, fb, netflix, increasingly Akamai) are dual stack. >> >> CB >> >> >>> >>> >>> On Tue, Jun 7, 2016 at 10:22 AM Ca By >> > wrote: >>> >>>> >>>> >>>> On Tuesday, June 7, 2016, Cryptographrix >>> > wrote: >>>> >>>>> As I said to Netflix's tech support - if they advocate for people to turn >>>>> off IPv6 on their end, maybe Netflix should stop supporting it on their >>>>> end. >>>>> >>>>> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >>>>> the moment, and if their tech support is telling people to turn off IPv6, >>>>> maybe they should just instead remove their AAAA records. >>>>> >>>>> (or fail back to ipv4 when v6 looks like a tunnel) >>>>> >>>>> >>>> I think you need to reset your expectations of a free tunnel service. >>>> >>>> he.net tunnels are a toy for geeks looking to play with v6. In terms of >>>> Netflix subcriber base, it is amazing insignificant number of users. >>>> >>>> At the end of the day, anonymous tunnels, just like linux, are not >>>> supported by Netflix. And, he.net tunnel users are hurting ipv6 overall >>>> just like 6to4 by injecting FUD and other nonesense complexity.... For a >>>> toy. >>>> >>>> Move on to a real issue instead of beating this dead horse. >>>> >>>> CB >>>> >>>> >>>>> >>>>> >>>>> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: >>>>> >>>>>> >>>>>>> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>>>>>> >>>>>>> The tunnelbroker service acts exactly like a VPN. It allows you, >>>>> from any >>>>>>> arbitrary location in the world with an IPv4 address, to bring >>>>> traffic >>>>>> out >>>>>>> via one of HE's 4 POP's, while completely masking your actual >>>>> location. >>>>>>> >>>>>> >>>>>> Perhaps Netflix should automatically block any connection that's not >>>>> from >>>>>> a known residential ISP or mobile ISP as anything else could be a >>>>> server >>>>>> someone is proxying through. It's very easy to get these subnets -- the >>>>>> spam filtering folks have these subnets well documented. /s >>>>>> >>>>>> -- >>>>>> Mark Felder >>>>>> feld at feld.me >>>>>> >>>>>> >>>>> >>>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Wed Jun 8 17:35:40 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2016 13:35:40 -0400 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <452a456d-1a73-2b9c-5806-b43f57d9f39f@bogus.com> References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> <649828D1-3D86-4852-9584-409D07260E65@delong.com> <452a456d-1a73-2b9c-5806-b43f5! 7d9f39f@bogus.com> Message-ID: <2F8FC448-058E-4DAC-9410-AD0093DA64DB@delong.com> Why? I use Mobile Hotspot? It?s part of the service I pay for. If Cameron can?t make that work, then that?s T-Mobile?s problem, not mine. Owen > On Jun 8, 2016, at 1:25 PM, joel jaeggli wrote: > > On 6/8/16 9:13 AM, Owen DeLong wrote: >> As of last week, I still wasn?t getting an IPv6 address by default on my iPhone 6S+ >> on T-Mobile. > > turn off mobile hotspot... > >> Just saying. >> >> Owen >> >>> On Jun 7, 2016, at 11:00 AM, Ca By wrote: >>> >>> On Tuesday, June 7, 2016, Cryptographrix wrote: >>> >>>> Very true - I was being a bit extremist out of frustration, but I think >>>> you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6 >>>> support, not actually IPv6 support. >>>> >>>> And I'm quite frustrated because there's so little actual v6 support, and >>>> I *do* actually need it on a daily basis for work. >>>> >>>> Because there's no actual ISP IPv6 support anywhere else (in parts of the >>>> US that *have* multiple ISPs), you can't even make the case to your ISP >>>> that it's a legitimate requirement for you because they know you're not >>>> really going to get v6 elsewhere. >>>> >>>> >>> I think we have different definitions of "no actual isp ipv6 support" >>> >>> Again, a helpful akamai blog >>> https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html >>> >>> fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have >>> meaningful deployments of ipv6. The only thing holding back greater >>> deployment for those networks are legacy CPE that will age out slowly. >>> >>> All 4 of the national mobile operator have ipv6 default on for most >>> new phone models. >>> >>> Yes, many gaps to fill still. But, on "my network" with shy of 70 million >>> users, everything has ipv6 except the iPhone, and that will change RSN. And >>> for users with v6, the majority of their traffic is ipv6 e2e since the >>> whales (google, fb, netflix, increasingly Akamai) are dual stack. >>> >>> CB >>> >>> >>>> >>>> >>>> On Tue, Jun 7, 2016 at 10:22 AM Ca By >>> > wrote: >>>> >>>>> >>>>> >>>>> On Tuesday, June 7, 2016, Cryptographrix >>>> > wrote: >>>>> >>>>>> As I said to Netflix's tech support - if they advocate for people to turn >>>>>> off IPv6 on their end, maybe Netflix should stop supporting it on their >>>>>> end. >>>>>> >>>>>> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at >>>>>> the moment, and if their tech support is telling people to turn off IPv6, >>>>>> maybe they should just instead remove their AAAA records. >>>>>> >>>>>> (or fail back to ipv4 when v6 looks like a tunnel) >>>>>> >>>>>> >>>>> I think you need to reset your expectations of a free tunnel service. >>>>> >>>>> he.net tunnels are a toy for geeks looking to play with v6. In terms of >>>>> Netflix subcriber base, it is amazing insignificant number of users. >>>>> >>>>> At the end of the day, anonymous tunnels, just like linux, are not >>>>> supported by Netflix. And, he.net tunnel users are hurting ipv6 overall >>>>> just like 6to4 by injecting FUD and other nonesense complexity.... For a >>>>> toy. >>>>> >>>>> Move on to a real issue instead of beating this dead horse. >>>>> >>>>> CB >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder wrote: >>>>>> >>>>>>> >>>>>>>> On Jun 6, 2016, at 22:25, Spencer Ryan wrote: >>>>>>>> >>>>>>>> The tunnelbroker service acts exactly like a VPN. It allows you, >>>>>> from any >>>>>>>> arbitrary location in the world with an IPv4 address, to bring >>>>>> traffic >>>>>>> out >>>>>>>> via one of HE's 4 POP's, while completely masking your actual >>>>>> location. >>>>>>>> >>>>>>> >>>>>>> Perhaps Netflix should automatically block any connection that's not >>>>>> from >>>>>>> a known residential ISP or mobile ISP as anything else could be a >>>>>> server >>>>>>> someone is proxying through. It's very easy to get these subnets -- the >>>>>>> spam filtering folks have these subnets well documented. /s >>>>>>> >>>>>>> -- >>>>>>> Mark Felder >>>>>>> feld at feld.me >>>>>>> >>>>>>> >>>>>> >>>>> >> >> > > From alh-ietf at tndh.net Wed Jun 8 17:45:54 2016 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 8 Jun 2016 10:45:54 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Ca By wrote: > On Tuesday, June 7, 2016, chris wrote: > > > it really feels alot like what net neutrality was supposed to avoid. > > making a policy where there is different treatment of one set of bits > > over another > > > > "your ipv6 bits are bad but if you turn it off the ipv4 bits are just fine" > > > > someone mentioned the fact that netflix is not just a content company > > but also acting as a network operator maybe the two should be separate > > > > i also find it ironic that they arent big fans of ISPs who use NAT or > > CGN and dont have 1 customer per IP yet their stifiling ipv6 and > > telling users to turn it off. you really cant have it both ways and > > complain about NAT and also say you recommend shutting off ipv6 :) > > > > hopefully they will realize imposing their own policy on how customers > > use their networks and the internet this isnt worth losing customers > > over > > > > chris > > > > > > Again. An HE tunnel is not production ipv6. It is a toy. Well, "service that works" from an OTT provider vs. "useless crap that is unsupported" from the L2 provider would beg to differ about the definition of toy. While there has been substantial effort by the participants on this list to get IPv6 deployed across their national network, the local support team from my ISP continues to give me the "IPv6 is not supported" crap response when I complain that all I am getting for a business class connection is a /64, and I need a /48. > > Telling people to turn of HE tunnel is NOT the same as turning off > production ipv6. Rather than telling people to turn off IPv6, Netflix should have just redirected to an IPv4-only name and let that geo-loc deal with it. If the account was trying to use a vpn to bypass geo-loc, it would still fail, but those trying to bypass lethargic ISP deployment/support of IPv6 would not notice unless they looked. Given that they are likely watching the Netflix content at the time, they would be very unlikely to notice the packet headers so this would never have become an issue. Fortunately in my case since I view Netflix through Chromecasts, I can turn off IPv6 on the media subnet and not impact the rest of my IPv6 use. I shouldn't have to do that, but the ability to isolate traffic is one reason people on this list need to get over the historic perception that a customer network is a single flat subnet. Allocating space on that assumption simply perpetuates the problems that come along with it. There is no technical reason to allocate anything longer than a /48, but for those that insist on doing so, please, please, please, don't go longer than a /56. Even a phone is a router that happens to have a voice app built in, so mobile providers need to stop the assumption that "it only needs a single subnet". Tony > > CB > > > > On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea > > wrote: > > > > > apparently, all they see is 3 people complaining on this mailing list.. > > > well, this makes it 4 with me (and I have a bunch of people in > > > various countries complaining on facebook that they have been banned > > > from using netflix because they use an HE tunnel. > > > > > > their answer - TURN IPV6 OFF!!! you're a techie so if you know how > > > to setup a tunnel, you must know how to redirect netflix to use IPv4 > only... > > > really? > > > the answer just pisses me off! > > > > > > Netflix, YOU are the ones forcing people to turn IPv4 off... this is > > > just insane. tens (if not hundred) of thousands of people chose to > > > use HE tunnels because their ISP does not offer IPv6.. > > > do you really expect all of them to turn it off? do you really want > > > IPv6 usage in the world to go down by a few percent because you are > > > unable to figure out how to serve content? > > > > > > I know nobody at Netflix will even answer to the e-mails on this list.. > > > but I hope that they will at least acknowledge the problem and > > > figure an other way to block content by country. > > > ie: they could try to talk to HE to register each tunnel in a > > > database that points to the country of the user.. > > > > > > cheers, > > > elvis > > > > > > > > > On 6/8/16 1:01 AM, chris wrote: > > > > > >> I am also in the same boat with a whole subnet affected even > > >> without a tunnel, tried multiple netflix support channels starting > > >> in early march and the ranges is still blocked 3 months later. > > >> > > >> I was a big fan of the service and somewhat of an addict up till > > >> this > > but > > >> I've really been shocked how this has been (mis)handled > > >> > > >> chris > > >> > > >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini > > > > >> wrote: > > >> > > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" > > >> and I > > >>> can't use it if I don't disable the HE tunnel, which is the only > > >>> way > > for > > >>> me to have IPv6 at the moment. > > >>> > > >>> But the fun part has been Netflix tech support: > > >>> "Oh I see, yeah we have been receiving reports of some other > > >>> members with ipv6 having this issues, at the moment Netflix is not > > >>> really designed to work with ipv6 connections, in this case I can > > >>> recommend > > you > > >>> two things, one is to turn off the ipv6 and the other one will be > > >>> to contact directly with Hurricane Electric, there are some > > >>> customers that were able to use Netflix with an ipv6 under some > > >>> specific settings set by Hurricane Electric." > > >>> > > >>> I don't obviously expect HE to fix it, I don't pay for shit, it's > > >>> a > > free > > >>> service, why should they? > > >>> > > >>> But it's fun to know that " Netflix is not really designed to work > > >>> with > > >>> ipv6 connections ". > > >>> > > >>> Who did it say on this ML that the best way to solve these issues > > >>> is Netflix tech support? :) > > >>> > > >>> Ciao, > > >>> Davide Davini > > >>> > > >>> > > >>> > > > > > From javier at advancedmachines.us Wed Jun 8 18:57:17 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 8 Jun 2016 14:57:17 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Message-ID: Tony, I agree 100% with you. Unfortunately I need ipv6 on my media subnet because it's part of my lab. And now that my teenage daughter is complaining about Netflix not working g on her Chromebook I'm starting to think consumers should just start complaining to Netflix. Why should I have to change my damn network to fix Netflix? In her eyes it's "daddy fix Netflix" but the heck with that. The man hours of the consumers who are affected to work around this issue is less than the man hours it would take for Netflix to redirect you with a 301 to an ipv4 only endpont. If Netflix needs help with this point me in the right direction. I'll be happy to fix it for them and send them a bill. On Jun 8, 2016 1:46 PM, "Tony Hain" wrote: > Ca By wrote: > > On Tuesday, June 7, 2016, chris wrote: > > > > > it really feels alot like what net neutrality was supposed to avoid. > > > making a policy where there is different treatment of one set of bits > > > over another > > > > > > "your ipv6 bits are bad but if you turn it off the ipv4 bits are just > fine" > > > > > > someone mentioned the fact that netflix is not just a content company > > > but also acting as a network operator maybe the two should be separate > > > > > > i also find it ironic that they arent big fans of ISPs who use NAT or > > > CGN and dont have 1 customer per IP yet their stifiling ipv6 and > > > telling users to turn it off. you really cant have it both ways and > > > complain about NAT and also say you recommend shutting off ipv6 :) > > > > > > hopefully they will realize imposing their own policy on how customers > > > use their networks and the internet this isnt worth losing customers > > > over > > > > > > chris > > > > > > > > > > Again. An HE tunnel is not production ipv6. It is a toy. > > Well, "service that works" from an OTT provider vs. "useless crap that is > unsupported" from the L2 provider would beg to differ about the definition > of toy. While there has been substantial effort by the participants on this > list to get IPv6 deployed across their national network, the local support > team from my ISP continues to give me the "IPv6 is not supported" crap > response when I complain that all I am getting for a business class > connection is a /64, and I need a /48. > > > > > Telling people to turn of HE tunnel is NOT the same as turning off > > production ipv6. > > Rather than telling people to turn off IPv6, Netflix should have just > redirected to an IPv4-only name and let that geo-loc deal with it. If the > account was trying to use a vpn to bypass geo-loc, it would still fail, but > those trying to bypass lethargic ISP deployment/support of IPv6 would not > notice unless they looked. Given that they are likely watching the Netflix > content at the time, they would be very unlikely to notice the packet > headers so this would never have become an issue. > > Fortunately in my case since I view Netflix through Chromecasts, I can > turn off IPv6 on the media subnet and not impact the rest of my IPv6 use. I > shouldn't have to do that, but the ability to isolate traffic is one reason > people on this list need to get over the historic perception that a > customer network is a single flat subnet. Allocating space on that > assumption simply perpetuates the problems that come along with it. There > is no technical reason to allocate anything longer than a /48, but for > those that insist on doing so, please, please, please, don't go longer than > a /56. Even a phone is a router that happens to have a voice app built in, > so mobile providers need to stop the assumption that "it only needs a > single subnet". > > Tony > > > > > > CB > > > > > > > On Tue, Jun 7, 2016 at 6:35 PM, Elvis Daniel Velea > > > wrote: > > > > > > > apparently, all they see is 3 people complaining on this mailing > list.. > > > > well, this makes it 4 with me (and I have a bunch of people in > > > > various countries complaining on facebook that they have been banned > > > > from using netflix because they use an HE tunnel. > > > > > > > > their answer - TURN IPV6 OFF!!! you're a techie so if you know how > > > > to setup a tunnel, you must know how to redirect netflix to use IPv4 > > only... > > > > really? > > > > the answer just pisses me off! > > > > > > > > Netflix, YOU are the ones forcing people to turn IPv4 off... this is > > > > just insane. tens (if not hundred) of thousands of people chose to > > > > use HE tunnels because their ISP does not offer IPv6.. > > > > do you really expect all of them to turn it off? do you really want > > > > IPv6 usage in the world to go down by a few percent because you are > > > > unable to figure out how to serve content? > > > > > > > > I know nobody at Netflix will even answer to the e-mails on this > list.. > > > > but I hope that they will at least acknowledge the problem and > > > > figure an other way to block content by country. > > > > ie: they could try to talk to HE to register each tunnel in a > > > > database that points to the country of the user.. > > > > > > > > cheers, > > > > elvis > > > > > > > > > > > > On 6/8/16 1:01 AM, chris wrote: > > > > > > > >> I am also in the same boat with a whole subnet affected even > > > >> without a tunnel, tried multiple netflix support channels starting > > > >> in early march and the ranges is still blocked 3 months later. > > > >> > > > >> I was a big fan of the service and somewhat of an addict up till > > > >> this > > > but > > > >> I've really been shocked how this has been (mis)handled > > > >> > > > >> chris > > > >> > > > >> On Tue, Jun 7, 2016 at 7:23 AM, Davide Davini > > > > > > >> wrote: > > > >> > > > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" > > > >> and I > > > >>> can't use it if I don't disable the HE tunnel, which is the only > > > >>> way > > > for > > > >>> me to have IPv6 at the moment. > > > >>> > > > >>> But the fun part has been Netflix tech support: > > > >>> "Oh I see, yeah we have been receiving reports of some other > > > >>> members with ipv6 having this issues, at the moment Netflix is not > > > >>> really designed to work with ipv6 connections, in this case I can > > > >>> recommend > > > you > > > >>> two things, one is to turn off the ipv6 and the other one will be > > > >>> to contact directly with Hurricane Electric, there are some > > > >>> customers that were able to use Netflix with an ipv6 under some > > > >>> specific settings set by Hurricane Electric." > > > >>> > > > >>> I don't obviously expect HE to fix it, I don't pay for shit, it's > > > >>> a > > > free > > > >>> service, why should they? > > > >>> > > > >>> But it's fun to know that " Netflix is not really designed to work > > > >>> with > > > >>> ipv6 connections ". > > > >>> > > > >>> Who did it say on this ML that the best way to solve these issues > > > >>> is Netflix tech support? :) > > > >>> > > > >>> Ciao, > > > >>> Davide Davini > > > >>> > > > >>> > > > >>> > > > > > > > > > From laszlo at heliacal.net Wed Jun 8 19:34:25 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 8 Jun 2016 19:34:25 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Message-ID: On 2016-06-08 18:57, Javier J wrote: > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media subnet > because it's part of my lab. And now that my teenage daughter is > complaining about Netflix not working g on her Chromebook I'm starting to > think consumers should just start complaining to Netflix. Why should I have > to change my damn network to fix Netflix? > > In her eyes it's "daddy fix Netflix" but the heck with that. The man hours > of the consumers who are affected to work around this issue is less than > the man hours it would take for Netflix to redirect you with a 301 to an > ipv4 only endpont. > > If Netflix needs help with this point me in the right direction. I'll be > happy to fix it for them and send them a bill. > They're doing the same thing with IPv4 (banning people based on the apparent IP address). Your IPv4 numbers may not be on their blacklist at the moment, and disabling IPv6 might work for you, but the underlying problem is the practice of GeoIP/VPN blocking, and the HE.net tunnels are just one example of the collateral damage. I don't know why Netflix and other GeoIP users can't just ask customers where they are located, instead of telling them. It is possible that some user might lie, but what about "assume good faith"? It shows how much they value you as a customer if they would rather dump you than trust you to tell them where you are located. -Laszlo From mhuff at ox.com Wed Jun 8 19:44:50 2016 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jun 2016 19:44:50 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Message-ID: The content providers wouldn't care if it was a very small number of people evading their region restrictions, but it isn't a small number. Those avoiding it are already not in good faith. While I don't agree with the content providers business model, it's their content, their rules. If you don't think it's right that Netflix is blocking VPNs and tunnels, then switch to Hulu and/or Amazon, however it's just matter of time before they start blocking VPNs and tunnels themselves. I agree that matching Geolocation with source IP addresses is a bad idea, but until someone comes up with a better idea and gets it implemented ( one that can't be modified by the end user), people with a business model that depends on it will continue to block based on IP. "Good faith" will be laughed at, and rightly so. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Laszlo > Hanyecz > Sent: Wednesday, June 8, 2016 3:34 PM > To: nanog at nanog.org > Subject: Re: Netflix banning HE tunnels > > > > On 2016-06-08 18:57, Javier J wrote: > > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media > subnet > > because it's part of my lab. And now that my teenage daughter is > > complaining about Netflix not working g on her Chromebook I'm > starting to > > think consumers should just start complaining to Netflix. Why should > I have > > to change my damn network to fix Netflix? > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > hours > > of the consumers who are affected to work around this issue is less > than > > the man hours it would take for Netflix to redirect you with a 301 to > an > > ipv4 only endpont. > > > > If Netflix needs help with this point me in the right direction. I'll > be > > happy to fix it for them and send them a bill. > > > > They're doing the same thing with IPv4 (banning people based on the > apparent IP address). Your IPv4 numbers may not be on their blacklist > at the moment, and disabling IPv6 might work for you, but the > underlying > problem is the practice of GeoIP/VPN blocking, and the HE.net tunnels > are just one example of the collateral damage. > > I don't know why Netflix and other GeoIP users can't just ask customers > where they are located, instead of telling them. It is possible that > some user might lie, but what about "assume good faith"? It shows how > much they value you as a customer if they would rather dump you than > trust you to tell them where you are located. > > -Laszlo > From alh-ietf at tndh.net Wed Jun 8 20:00:15 2016 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 8 Jun 2016 13:00:15 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Message-ID: <1e4501d1c1c0$60376620$20a63260$@tndh.net> Matthew, I was not complaining about the business model, or the need to comply with content provider requirements. The issue is the pathetic implementation choice that Netflix made when a trivial alternative was available. I agree that setting up rwhois and trusting the 3rd party tunnel providers to provide valid information is substantially more effort than the ROI on this would justify, but a redirect to IPv4-only requires no additional 3rd party trust for geo-loc than an IPv4 connection to begin with, would still catch the bad actors, yet works correctly for those trying to move the Internet forward. Tony > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew > Huff > Sent: Wednesday, June 08, 2016 12:45 PM > To: Laszlo Hanyecz; nanog at nanog.org > Subject: RE: Netflix banning HE tunnels > > The content providers wouldn't care if it was a very small number of people > evading their region restrictions, but it isn't a small number. Those avoiding > it are already not in good faith. While I don't agree with the content > providers business model, it's their content, their rules. > > If you don't think it's right that Netflix is blocking VPNs and tunnels, then > switch to Hulu and/or Amazon, however it's just matter of time before they > start blocking VPNs and tunnels themselves. > > I agree that matching Geolocation with source IP addresses is a bad idea, but > until someone comes up with a better idea and gets it implemented ( one > that can't be modified by the end user), people with a business model that > depends on it will continue to block based on IP. "Good faith" will be > laughed at, and rightly so. > > > > ---- > Matthew Huff | 1 Manhattanville Rd Director of Operations | > Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Laszlo > > Hanyecz > > Sent: Wednesday, June 8, 2016 3:34 PM > > To: nanog at nanog.org > > Subject: Re: Netflix banning HE tunnels > > > > > > > > On 2016-06-08 18:57, Javier J wrote: > > > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media > > subnet > > > because it's part of my lab. And now that my teenage daughter is > > > complaining about Netflix not working g on her Chromebook I'm > > starting to > > > think consumers should just start complaining to Netflix. Why should > > I have > > > to change my damn network to fix Netflix? > > > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > > hours > > > of the consumers who are affected to work around this issue is less > > than > > > the man hours it would take for Netflix to redirect you with a 301 > > > to > > an > > > ipv4 only endpont. > > > > > > If Netflix needs help with this point me in the right direction. > > > I'll > > be > > > happy to fix it for them and send them a bill. > > > > > > > They're doing the same thing with IPv4 (banning people based on the > > apparent IP address). Your IPv4 numbers may not be on their blacklist > > at the moment, and disabling IPv6 might work for you, but the > > underlying problem is the practice of GeoIP/VPN blocking, and the > > HE.net tunnels are just one example of the collateral damage. > > > > I don't know why Netflix and other GeoIP users can't just ask > > customers where they are located, instead of telling them. It is > > possible that some user might lie, but what about "assume good faith"? > > It shows how much they value you as a customer if they would rather > > dump you than trust you to tell them where you are located. > > > > -Laszlo > > From sryan at arbor.net Wed Jun 8 20:02:03 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 8 Jun 2016 16:02:03 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <1e4501d1c1c0$60376620$20a63260$@tndh.net> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> Message-ID: We don't know, and will never know if the content providers went to Netflix and said "You need to ban based on IP range" speculation at this point isn't useful. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 8, 2016 at 4:00 PM, Tony Hain wrote: > Matthew, > > I was not complaining about the business model, or the need to comply with > content provider requirements. The issue is the pathetic implementation > choice that Netflix made when a trivial alternative was available. I agree > that setting up rwhois and trusting the 3rd party tunnel providers to > provide valid information is substantially more effort than the ROI on this > would justify, but a redirect to IPv4-only requires no additional 3rd party > trust for geo-loc than an IPv4 connection to begin with, would still catch > the bad actors, yet works correctly for those trying to move the Internet > forward. > > Tony > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew > > Huff > > Sent: Wednesday, June 08, 2016 12:45 PM > > To: Laszlo Hanyecz; nanog at nanog.org > > Subject: RE: Netflix banning HE tunnels > > > > The content providers wouldn't care if it was a very small number of > people > > evading their region restrictions, but it isn't a small number. Those > avoiding > > it are already not in good faith. While I don't agree with the content > > providers business model, it's their content, their rules. > > > > If you don't think it's right that Netflix is blocking VPNs and tunnels, > then > > switch to Hulu and/or Amazon, however it's just matter of time before > they > > start blocking VPNs and tunnels themselves. > > > > I agree that matching Geolocation with source IP addresses is a bad > idea, but > > until someone comes up with a better idea and gets it implemented ( one > > that can't be modified by the end user), people with a business model > that > > depends on it will continue to block based on IP. "Good faith" will be > > laughed at, and rightly so. > > > > > > > > ---- > > Matthew Huff | 1 Manhattanville Rd Director of Operations | > > Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-694-5669 > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Laszlo > > > Hanyecz > > > Sent: Wednesday, June 8, 2016 3:34 PM > > > To: nanog at nanog.org > > > Subject: Re: Netflix banning HE tunnels > > > > > > > > > > > > On 2016-06-08 18:57, Javier J wrote: > > > > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media > > > subnet > > > > because it's part of my lab. And now that my teenage daughter is > > > > complaining about Netflix not working g on her Chromebook I'm > > > starting to > > > > think consumers should just start complaining to Netflix. Why should > > > I have > > > > to change my damn network to fix Netflix? > > > > > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > > > hours > > > > of the consumers who are affected to work around this issue is less > > > than > > > > the man hours it would take for Netflix to redirect you with a 301 > > > > to > > > an > > > > ipv4 only endpont. > > > > > > > > If Netflix needs help with this point me in the right direction. > > > > I'll > > > be > > > > happy to fix it for them and send them a bill. > > > > > > > > > > They're doing the same thing with IPv4 (banning people based on the > > > apparent IP address). Your IPv4 numbers may not be on their blacklist > > > at the moment, and disabling IPv6 might work for you, but the > > > underlying problem is the practice of GeoIP/VPN blocking, and the > > > HE.net tunnels are just one example of the collateral damage. > > > > > > I don't know why Netflix and other GeoIP users can't just ask > > > customers where they are located, instead of telling them. It is > > > possible that some user might lie, but what about "assume good faith"? > > > It shows how much they value you as a customer if they would rather > > > dump you than trust you to tell them where you are located. > > > > > > -Laszlo > > > > > > From mhuff at ox.com Wed Jun 8 20:26:29 2016 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jun 2016 20:26:29 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> Message-ID: Yes we do. The is a document dump with the contract information between Netflix and the content providers. A link was sent in this email chain, or you can do a search for it. Neither side has been shy about what they are doing. They publically have stated they are blocking VPN access to NetFlix. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Spencer Ryan [mailto:sryan at arbor.net] Sent: Wednesday, June 8, 2016 4:02 PM To: Tony Hain Cc: Matthew Huff ; Laszlo Hanyecz ; North American Network Operators' Group Subject: Re: Netflix banning HE tunnels We don't know, and will never know if the content providers went to Netflix and said "You need to ban based on IP range" speculation at this point isn't useful. Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 8, 2016 at 4:00 PM, Tony Hain > wrote: Matthew, I was not complaining about the business model, or the need to comply with content provider requirements. The issue is the pathetic implementation choice that Netflix made when a trivial alternative was available. I agree that setting up rwhois and trusting the 3rd party tunnel providers to provide valid information is substantially more effort than the ROI on this would justify, but a redirect to IPv4-only requires no additional 3rd party trust for geo-loc than an IPv4 connection to begin with, would still catch the bad actors, yet works correctly for those trying to move the Internet forward. Tony > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew > Huff > Sent: Wednesday, June 08, 2016 12:45 PM > To: Laszlo Hanyecz; nanog at nanog.org > Subject: RE: Netflix banning HE tunnels > > The content providers wouldn't care if it was a very small number of people > evading their region restrictions, but it isn't a small number. Those avoiding > it are already not in good faith. While I don't agree with the content > providers business model, it's their content, their rules. > > If you don't think it's right that Netflix is blocking VPNs and tunnels, then > switch to Hulu and/or Amazon, however it's just matter of time before they > start blocking VPNs and tunnels themselves. > > I agree that matching Geolocation with source IP addresses is a bad idea, but > until someone comes up with a better idea and gets it implemented ( one > that can't be modified by the end user), people with a business model that > depends on it will continue to block based on IP. "Good faith" will be > laughed at, and rightly so. > > > > ---- > Matthew Huff | 1 Manhattanville Rd Director of Operations | > Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Laszlo > > Hanyecz > > Sent: Wednesday, June 8, 2016 3:34 PM > > To: nanog at nanog.org > > Subject: Re: Netflix banning HE tunnels > > > > > > > > On 2016-06-08 18:57, Javier J wrote: > > > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media > > subnet > > > because it's part of my lab. And now that my teenage daughter is > > > complaining about Netflix not working g on her Chromebook I'm > > starting to > > > think consumers should just start complaining to Netflix. Why should > > I have > > > to change my damn network to fix Netflix? > > > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > > hours > > > of the consumers who are affected to work around this issue is less > > than > > > the man hours it would take for Netflix to redirect you with a 301 > > > to > > an > > > ipv4 only endpont. > > > > > > If Netflix needs help with this point me in the right direction. > > > I'll > > be > > > happy to fix it for them and send them a bill. > > > > > > > They're doing the same thing with IPv4 (banning people based on the > > apparent IP address). Your IPv4 numbers may not be on their blacklist > > at the moment, and disabling IPv6 might work for you, but the > > underlying problem is the practice of GeoIP/VPN blocking, and the > > HE.net tunnels are just one example of the collateral damage. > > > > I don't know why Netflix and other GeoIP users can't just ask > > customers where they are located, instead of telling them. It is > > possible that some user might lie, but what about "assume good faith"? > > It shows how much they value you as a customer if they would rather > > dump you than trust you to tell them where you are located. > > > > -Laszlo > > From savage at savage.za.org Wed Jun 8 20:52:31 2016 From: savage at savage.za.org (Chris Knipe) Date: Wed, 8 Jun 2016 22:52:31 +0200 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> Message-ID: Bwahaha Ok - that's me, never ever will I look at NexFlix again. I have my own /48, registered in my own name, my own company, my own peering links, and my own transit links. Signup, no problems. As soon as I started watching a stream... Wham, blocked. Proxy Detected. It's clear NetFlix has something against IPv6, not tunnels. On Wed, Jun 8, 2016 at 10:26 PM, Matthew Huff wrote: > Yes we do. > > The is a document dump with the contract information between Netflix and > the content providers. A link was sent in this email chain, or you can do a > search for it. Neither side has been shy about what they are doing. They > publically have stated they are blocking VPN access to NetFlix. > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > From: Spencer Ryan [mailto:sryan at arbor.net] > Sent: Wednesday, June 8, 2016 4:02 PM > To: Tony Hain > Cc: Matthew Huff ; Laszlo Hanyecz ; > North American Network Operators' Group > Subject: Re: Netflix banning HE tunnels > > We don't know, and will never know if the content providers went to > Netflix and said "You need to ban based on IP range" speculation at this > point isn't useful. > > > Spencer Ryan | Senior Systems Administrator | sryan at arbor.net sryan at arbor.net> > Arbor Networks > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Wed, Jun 8, 2016 at 4:00 PM, Tony Hain alh-ietf at tndh.net>> wrote: > Matthew, > > I was not complaining about the business model, or the need to comply with > content provider requirements. The issue is the pathetic implementation > choice that Netflix made when a trivial alternative was available. I agree > that setting up rwhois and trusting the 3rd party tunnel providers to > provide valid information is substantially more effort than the ROI on this > would justify, but a redirect to IPv4-only requires no additional 3rd party > trust for geo-loc than an IPv4 connection to begin with, would still catch > the bad actors, yet works correctly for those trying to move the Internet > forward. > > Tony > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org nanog-bounces at nanog.org>] On Behalf Of Matthew > > Huff > > Sent: Wednesday, June 08, 2016 12:45 PM > > To: Laszlo Hanyecz; nanog at nanog.org > > Subject: RE: Netflix banning HE tunnels > > > > The content providers wouldn't care if it was a very small number of > people > > evading their region restrictions, but it isn't a small number. Those > avoiding > > it are already not in good faith. While I don't agree with the content > > providers business model, it's their content, their rules. > > > > If you don't think it's right that Netflix is blocking VPNs and tunnels, > then > > switch to Hulu and/or Amazon, however it's just matter of time before > they > > start blocking VPNs and tunnels themselves. > > > > I agree that matching Geolocation with source IP addresses is a bad > idea, but > > until someone comes up with a better idea and gets it implemented ( one > > that can't be modified by the end user), people with a business model > that > > depends on it will continue to block based on IP. "Good faith" will be > > laughed at, and rightly so. > > > > > > > > ---- > > Matthew Huff | 1 Manhattanville Rd Director of Operations | > > Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 914-460-4039> > > aim: matthewbhuff | Fax: 914-694-5669 > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org nanog-bounces at nanog.org>] On Behalf Of Laszlo > > > Hanyecz > > > Sent: Wednesday, June 8, 2016 3:34 PM > > > To: nanog at nanog.org > > > Subject: Re: Netflix banning HE tunnels > > > > > > > > > > > > On 2016-06-08 18:57, Javier J wrote: > > > > Tony, I agree 100% with you. Unfortunately I need ipv6 on my media > > > subnet > > > > because it's part of my lab. And now that my teenage daughter is > > > > complaining about Netflix not working g on her Chromebook I'm > > > starting to > > > > think consumers should just start complaining to Netflix. Why should > > > I have > > > > to change my damn network to fix Netflix? > > > > > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > > > hours > > > > of the consumers who are affected to work around this issue is less > > > than > > > > the man hours it would take for Netflix to redirect you with a 301 > > > > to > > > an > > > > ipv4 only endpont. > > > > > > > > If Netflix needs help with this point me in the right direction. > > > > I'll > > > be > > > > happy to fix it for them and send them a bill. > > > > > > > > > > They're doing the same thing with IPv4 (banning people based on the > > > apparent IP address). Your IPv4 numbers may not be on their blacklist > > > at the moment, and disabling IPv6 might work for you, but the > > > underlying problem is the practice of GeoIP/VPN blocking, and the > > > HE.net tunnels are just one example of the collateral damage. > > > > > > I don't know why Netflix and other GeoIP users can't just ask > > > customers where they are located, instead of telling them. It is > > > possible that some user might lie, but what about "assume good faith"? > > > It shows how much they value you as a customer if they would rather > > > dump you than trust you to tell them where you are located. > > > > > > -Laszlo > > > > > > -- Regards, Chris Knipe From andy at newslink.com Wed Jun 8 21:06:28 2016 From: andy at newslink.com (Andy Ringsmuth) Date: Wed, 8 Jun 2016 16:06:28 -0500 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> Message-ID: <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> > On Jun 8, 2016, at 3:52 PM, Chris Knipe wrote: > > Bwahaha > > Ok - that's me, never ever will I look at NexFlix again. > > I have my own /48, registered in my own name, my own company, my own > peering links, and my own transit links. Signup, no problems. As soon as > I started watching a stream... > > Wham, blocked. Proxy Detected. > > It's clear NetFlix has something against IPv6, not tunnels. I disagree. I?ve got IPv6 at work, nothing elaborate, just a /48 given to us by our ISP. I ran a test on an IPv6-only connection, no IPv4 addressing whatsoever, and a few random Netflix shows played perfectly fine. ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Travel, Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From savage at savage.za.org Wed Jun 8 21:08:29 2016 From: savage at savage.za.org (Chris Knipe) Date: Wed, 8 Jun 2016 23:08:29 +0200 Subject: Netflix banning HE tunnels In-Reply-To: <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: Exactly. So what precisely are the metrics they use to block? I'm not using a proxy at all, its my own ASN... On Wed, Jun 8, 2016 at 11:06 PM, Andy Ringsmuth wrote: > > > On Jun 8, 2016, at 3:52 PM, Chris Knipe wrote: > > > > Bwahaha > > > > Ok - that's me, never ever will I look at NexFlix again. > > > > I have my own /48, registered in my own name, my own company, my own > > peering links, and my own transit links. Signup, no problems. As soon > as > > I started watching a stream... > > > > Wham, blocked. Proxy Detected. > > > > It's clear NetFlix has something against IPv6, not tunnels. > > I disagree. > > I?ve got IPv6 at work, nothing elaborate, just a /48 given to us by our > ISP. > > I ran a test on an IPv6-only connection, no IPv4 addressing whatsoever, > and a few random Netflix shows played perfectly fine. > > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Travel, Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > -- Regards, Chris Knipe From mhuff at ox.com Wed Jun 8 21:24:48 2016 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jun 2016 21:24:48 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> What does https://www.maxmind.com/en/geoip-demo show for your IPv6 prefix? If it is incorrect, try https://support.maxmind.com/geoip-data-correction-request/ On Jun 8, 2016, at 5:08 PM, Chris Knipe wrote: > > Exactly. > > So what precisely are the metrics they use to block? I'm not using a proxy > at all, its my own ASN... > > On Wed, Jun 8, 2016 at 11:06 PM, Andy Ringsmuth wrote: > >> >>> On Jun 8, 2016, at 3:52 PM, Chris Knipe wrote: >>> >>> Bwahaha >>> >>> Ok - that's me, never ever will I look at NexFlix again. >>> >>> I have my own /48, registered in my own name, my own company, my own >>> peering links, and my own transit links. Signup, no problems. As soon >> as >>> I started watching a stream... >>> >>> Wham, blocked. Proxy Detected. >>> >>> It's clear NetFlix has something against IPv6, not tunnels. >> >> I disagree. >> >> I?ve got IPv6 at work, nothing elaborate, just a /48 given to us by our >> ISP. >> >> I ran a test on an IPv6-only connection, no IPv4 addressing whatsoever, >> and a few random Netflix shows played perfectly fine. >> >> >> ---- >> Andy Ringsmuth >> andy at newslink.com >> News Link ? Manager Travel, Technology & Facilities >> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >> (402) 475-6397 (402) 304-0083 cellular >> >> > > > -- > > Regards, > Chris Knipe https://www.maxmind.com/en/geoip-demo From jfbeam at gmail.com Wed Jun 8 22:09:01 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 08 Jun 2016 18:09:01 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> Message-ID: On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff wrote: > What does https://www.maxmind.com/en/geoip-demo show for your IPv6 > prefix? If it is incorrect, try > https://support.maxmind.com/geoip-data-correction-request/ > HAH. Funny... 39.76,-98.5 for every HE address I enter. And it's not like they haven't been registered for years. (that's the center of the US, btw.) From sryan at arbor.net Wed Jun 8 22:10:11 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 8 Jun 2016 18:10:11 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> Message-ID: The center of the US is maxmind's unknown location. Fill out the form and they'll correct it. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 8, 2016 at 6:09 PM, Ricky Beam wrote: > On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff wrote: > > What does https://www.maxmind.com/en/geoip-demo show for your IPv6 >> prefix? If it is incorrect, try >> https://support.maxmind.com/geoip-data-correction-request/ >> >> > HAH. Funny... 39.76,-98.5 for every HE address I enter. And it's not like > they haven't been registered for years. (that's the center of the US, btw.) > From hvgeekwtrvl at gmail.com Wed Jun 8 22:16:57 2016 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 8 Jun 2016 15:16:57 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> Message-ID: http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ fusion just did a story on how this. On Wed, Jun 8, 2016 at 3:10 PM, Spencer Ryan wrote: > The center of the US is maxmind's unknown location. Fill out the form and > they'll correct it. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Wed, Jun 8, 2016 at 6:09 PM, Ricky Beam wrote: > > > On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff wrote: > > > > What does https://www.maxmind.com/en/geoip-demo show for your IPv6 > >> prefix? If it is incorrect, try > >> https://support.maxmind.com/geoip-data-correction-request/ > >> > >> > > HAH. Funny... 39.76,-98.5 for every HE address I enter. And it's not like > > they haven't been registered for years. (that's the center of the US, > btw.) > > > From eric.kuhnke at gmail.com Wed Jun 8 22:26:36 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 8 Jun 2016 15:26:36 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <174357BE-E744-40E8-91F6-C44B2E88D8E4@ox.com> Message-ID: There is a website where people attempt visiting the precision intersection of latitude and longitude lines and post photos. Why, I'm not quite sure, but there's all sorts of hobbies. I would like to see the clueless federal law enforcement referenced in that article attempt to visit the default coordinates of 0,0 off the coast of West Africa: http://confluence.org/confluence.php?id=13976 "Sir! We've found the hacker! They must be on a ship offshore of Africa, we need to call JSOC!" On Wed, Jun 8, 2016 at 3:16 PM, james machado wrote: > http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > > fusion just did a story on how this. > > > > On Wed, Jun 8, 2016 at 3:10 PM, Spencer Ryan wrote: > > > The center of the US is maxmind's unknown location. Fill out the form and > > they'll correct it. > > > > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > > *Arbor Networks* > > +1.734.794.5033 (d) | +1.734.846.2053 (m) > > www.arbornetworks.com > > > > On Wed, Jun 8, 2016 at 6:09 PM, Ricky Beam wrote: > > > > > On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff wrote: > > > > > > What does https://www.maxmind.com/en/geoip-demo show for your IPv6 > > >> prefix? If it is incorrect, try > > >> https://support.maxmind.com/geoip-data-correction-request/ > > >> > > >> > > > HAH. Funny... 39.76,-98.5 for every HE address I enter. And it's not > like > > > they haven't been registered for years. (that's the center of the US, > > btw.) > > > > > > From eric.kuhnke at gmail.com Thu Jun 9 01:06:10 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 8 Jun 2016 18:06:10 -0700 Subject: Webmail / IMAPS software for end-user clients in 2016 Message-ID: If you had to put up a public facing webmail interface for people to use, and maintain it for the foreseeable future (5-6 years), what would you use? Roundcube? https://roundcube.net/ Rainloop? http://www.rainloop.net/ Something else? Requirements: Needs to be open souce and GPL, BSD or Apache licensed Email storage will be accessed via IMAP/TLS1.2 Runs on a Debian based platform with apache2 or nginx Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" size screens with Chrome and Safari From nanogml at Mail.DDoS-Mitigator.net Thu Jun 9 01:37:10 2016 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 8 Jun 2016 18:37:10 -0700 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: Message-ID: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> hi ya On 06/08/16 at 06:06pm, Eric Kuhnke wrote: > If you had to put up a public facing webmail interface for people to use, > and maintain it for the foreseeable future (5-6 years), what would you use? > > Roundcube? > https://roundcube.net/ - good > Rainloop? > http://www.rainloop.net/ - never used - w/o db support, how you maintain a (real) list of x,000 users and pwd > Something else? http://squirrlemail.org - good http://openwebmail.org/ - least effort to get webmail running ( esp if time is limited ) http://horde.org - possibly confusing install process --------- imaps from doveocot.org ( note differences between dovecot-1.x vs dovecot-2.x ) > Requirements: > Needs to be open souce and GPL, BSD or Apache licensed > > Email storage will be accessed via IMAP/TLS1.2 > > Runs on a Debian based platform with apache2 or nginx > > Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" > size screens with Chrome and Safari - you probably want support for your favorite sql app - you probably want support for your favorite anti-virus app - you probably want support for your favorite anti-spam app http://networknightmare.net/WebMail/ magic pixie dust alvin # DDoS-Mitigator.net # From eric.kuhnke at gmail.com Thu Jun 9 01:43:34 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 8 Jun 2016 18:43:34 -0700 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> References: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> Message-ID: openwebmail hasn't been updated since 2006... squirrelmail is ancient and barely maintained. Antivirus and antispam are handled by the SMTP system which operates on the backend of the webmail, by the time incoming mail gets to dovecot imap storage for the user accounts it has already been processed. Antivirus/antispam handled similarly on other servers for outgoing SMTP traffic. On Wed, Jun 8, 2016 at 6:37 PM, alvin nanog wrote: > > hi ya > > On 06/08/16 at 06:06pm, Eric Kuhnke wrote: > > If you had to put up a public facing webmail interface for people to use, > > and maintain it for the foreseeable future (5-6 years), what would you > use? > > > > Roundcube? > > https://roundcube.net/ > - good > > > Rainloop? > > http://www.rainloop.net/ > - never used > - w/o db support, how you maintain a (real) list of x,000 users and pwd > > > Something else? > > http://squirrlemail.org > - good > > http://openwebmail.org/ > - least effort to get webmail running ( esp if time is limited ) > > http://horde.org > - possibly confusing install process > > --------- > imaps from doveocot.org > ( note differences between dovecot-1.x vs dovecot-2.x ) > > > Requirements: > > Needs to be open souce and GPL, BSD or Apache licensed > > > > Email storage will be accessed via IMAP/TLS1.2 > > > > Runs on a Debian based platform with apache2 or nginx > > > > Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" > > size screens with Chrome and Safari > > - you probably want support for your favorite sql app > - you probably want support for your favorite anti-virus app > - you probably want support for your favorite anti-spam app > > http://networknightmare.net/WebMail/ > > magic pixie dust > alvin > # DDoS-Mitigator.net > # > From nanogml at Mail.DDoS-Mitigator.net Thu Jun 9 02:18:23 2016 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 8 Jun 2016 19:18:23 -0700 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> Message-ID: <20160609021823.GA29759@Mail.DDoS-Mitigator.net> hi yta On 06/08/16 at 06:43pm, Eric Kuhnke wrote: > openwebmail hasn't been updated since 2006... yup.. a minor/major issue > squirrelmail is ancient and barely maintained. last update ( svn ) was Jun 09, 2016 ( today ) http://squirrelmail.org/download.php if you like the "latest/greatest" sw ... debian is not always the best choice, as their *.deb packages are sometimes too old for the binaries it's packaging compared to the author's stable releases ( latest stable packages want in the distro: ( kernel, apache, sendmail, postfix, sql, php, perl, dovecot, etc ----- barely maintained etc is not necessarily bad ... - sometimes, you want stable software that doesn't change every day or every week - presumably, "more stable" sw will not have as many bugs that requires releasing yet another version - sometimes, time-tested (stable) software, used by thousands of users with thousands of different OS/mta/browsers is a a good thing .. - optionally, to use the latest dev released from yesterday/last week is equally good, esp for bug fixes and security patches > Antivirus and antispam are handled by the SMTP system which operates on the > backend of the webmail, by the time incoming mail gets to dovecot imap > storage for the user accounts it has already been processed. okay ... virus and spam can be stopped at many different places or even outsourced .. it's not just the MTA's job to do filter it > Antivirus/antispam handled similarly on other servers for outgoing SMTP > traffic. good if you're stopping outgoing virus/spam... :-) don't forget the incoming virii/wormns too have fun alvin From bill at herrin.us Thu Jun 9 03:55:25 2016 From: bill at herrin.us (William Herrin) Date: Wed, 8 Jun 2016 23:55:25 -0400 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> References: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> Message-ID: On Wed, Jun 8, 2016 at 9:37 PM, alvin nanog wrote: >> Rainloop? >> http://www.rainloop.net/ > - never used > - w/o db support, how you maintain a (real) list of x,000 users and pwd "Direct access to mail server is used (mails are not stored locally on web server)." -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From eric.kuhnke at gmail.com Thu Jun 9 03:59:41 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 8 Jun 2016 20:59:41 -0700 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> Message-ID: Yes... The mail storage running behind the https based webmail server would be IMAPS to dovecot, which has more than ample functionality for many different ways of storing mail and authenticating users. On Wed, Jun 8, 2016 at 8:55 PM, William Herrin wrote: > On Wed, Jun 8, 2016 at 9:37 PM, alvin nanog > wrote: > >> Rainloop? > >> http://www.rainloop.net/ > > - never used > > - w/o db support, how you maintain a (real) list of x,000 users and pwd > > "Direct access to mail server is used (mails are not stored locally on > web server)." > > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From ghenry at suretec.co.uk Thu Jun 9 06:15:16 2016 From: ghenry at suretec.co.uk (Gavin Henry) Date: Thu, 9 Jun 2016 07:15:16 +0100 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: <20160609013709.GA29567@Mail.DDoS-Mitigator.net> Message-ID: > On Wed, Jun 8, 2016 at 8:55 PM, William Herrin wrote: > > > On Wed, Jun 8, 2016 at 9:37 PM, alvin nanog > > wrote: > > >> Rainloop? > > >> http://www.rainloop.net/ > > > - never used > > > - w/o db support, how you maintain a (real) list of x,000 users and pwd > > > > "Direct access to mail server is used (mails are not stored locally on > > web server)." I never see LDAP mentioned much. Dovecot has excellent support for it and many other ways to authenticate a "user". Squirelmail can too. Plus you can use all the nss/pam options instead of native support. Sogo is a nice option https://sogo.nu/ We're loving the dovecot replication too. A long time user. -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider From jam at zoidtechnologies.com Wed Jun 8 22:39:13 2016 From: jam at zoidtechnologies.com (Jeff) Date: Wed, 08 Jun 2016 18:39:13 -0400 Subject: Monitoring system recommendation In-Reply-To: References: Message-ID: <57589E91.4080006@zoidtechnologies.com> On 06/06/2016 10:18 AM, Manuel Mar?n wrote: > Dear Nanog community [...snipped...] > Your input is really appreciated it > > Thank you and have a great day > > Regards > I have not used openNMS in production.. does it work well under heavy load? regards, J From jlightfoot at gmail.com Wed Jun 8 21:39:29 2016 From: jlightfoot at gmail.com (John Lightfoot) Date: Wed, 08 Jun 2016 17:39:29 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: How about: Dear Netflix network engineer who?s on the NANOG list. Could you please get Netflix to fall back to ipv4 if you block your customer?s ipv6 because it?s in an HE tunnel? Lots of people who want to watch Netflix, be able to reach the whole internet, and have Verizon FiOS would really appreciate it. Thanks, John John Lightoot From thomas.king at de-cix.net Wed Jun 8 19:27:32 2016 From: thomas.king at de-cix.net (Thomas King) Date: Wed, 8 Jun 2016 19:27:32 +0000 Subject: Bogon ASN Filter Policy In-Reply-To: References: <20160602194138.GM15096@57.rev.meerval.net> <22353.33101.968191.138056@oz.mt.att.com> <82502792-912e-b6df-6477-27f6ba573222@nipper.de> Message-ID: <1D20978B-DD86-4ACB-AA56-920674BCF894@de-cix.net> Hi all, a quick update from the DE-CIX side: we see in total 25 routes containing bogon ASNs at all the route servers at all DE-CIX IXPs (so far we just filtered the private ASN space). We directly contacted the customers sending the routes to inform them about the upcoming change in filtering. Best regards, Thomas > On 08 Jun 2016, at 15:56, Michael Hare wrote: > > I'm not against the theory of what is being proposed, but I was surprised to see little discussion of this announcement on list. > > Upon examination on my view of the DFZ from AS3128 I see over 400 upstream routes falling into this category, mostly in the 64512 - 65534 range. Based on our flow bandwidth stats we chose to reach out to several origin ASN, two fairly well known, as a courtesy. > > For the *TT's who are planning on implementing shortly, have you went through a similar diagnostic effort and what might you share or report on such endeavors? > > -Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3267 bytes Desc: not available URL: From tony at lavanauts.org Wed Jun 8 08:54:33 2016 From: tony at lavanauts.org (Antonio Querubin) Date: Tue, 7 Jun 2016 22:54:33 -1000 (HST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <20160608052705.15C904B00B9F@rock.dv.isc.org> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> Message-ID: On Wed, 8 Jun 2016, Mark Andrews wrote: > And which set of prefixes is that? How often do they change? etc. Apparently there's only 2620:108:7000::/44 and I doubt it'll change often. An associate actually reported this problem to me today. I ended up just installing a host firewall rule on his Netflix viewer and made the problem go away. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From tony at lavanauts.org Wed Jun 8 15:27:37 2016 From: tony at lavanauts.org (Antonio Querubin) Date: Wed, 8 Jun 2016 05:27:37 -1000 (HST) Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <57583600.3020902@gmail.com> References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> <20160608070525.06fd5995@echo.ms.redpill-linpro.com> <20160608052705.15C904B00B9F@rock.dv.isc.org> <57583600.3020902@gmail.com> Message-ID: On Wed, 8 Jun 2016, Baldur Norddahl wrote: > A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS > lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) and I > am not blocked from accessing Netflix over IPv6 so can't really try it. I am I sent some email earlier that that does work using a host firewall on an affected client. For some reason my email is in hold state - not sure what's up with that. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From coy.hile at coyhile.com Thu Jun 9 01:45:49 2016 From: coy.hile at coyhile.com (Coy Hile) Date: Thu, 09 Jun 2016 01:45:49 +0000 Subject: Webmail / IMAPS software for end-user clients in 2016 Message-ID: <20160609014549.Horde.unvAvINMqSL2j6pB87e3Fw5@webmail-new.coyhile.com> I like horde (with dove cot doing imaps) because it speaks ActiveSync natively.? Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone -------- Original message -------- From: alvin nanog Date: 6/8/2016 21:37 (GMT-05:00) To: eric.kuhnke at gmail.com Cc: nanog at nanog.org Subject: Re: Webmail / IMAPS software for end-user clients in 2016 > > hi ya > > On 06/08/16 at 06:06pm, Eric Kuhnke wrote: >> If you had to put up a public facing webmail interface for people to use, >> and maintain it for the foreseeable future (5-6 years), what would you use? >> >> Roundcube? >> https://roundcube.net/ > - good > >> Rainloop? >> http://www.rainloop.net/ > - never used > - w/o db support, how you maintain a (real) list of x,000 users and pwd > >> Something else? > > http://squirrlemail.org > - good > > http://openwebmail.org/ > - least effort to get webmail running ( esp if time is limited ) > > http://horde.org > - possibly confusing install process > > --------- > imaps from doveocot.org > ( note differences between dovecot-1.x vs dovecot-2.x ) > >> Requirements: >> Needs to be open souce and GPL, BSD or Apache licensed >> >> Email storage will be accessed via IMAP/TLS1.2 >> >> Runs on a Debian based platform with apache2 or nginx >> >> Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" >> size screens with Chrome and Safari > > - you probably want support for your favorite sql app > - you probably want support for your favorite anti-virus app > - you probably want support for your favorite anti-spam app > > http://networknightmare.net/WebMail/ > > magic pixie dust > alvin > # DDoS-Mitigator.net > # > From stillwaxin at gmail.com Thu Jun 9 14:10:19 2016 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 9 Jun 2016 10:10:19 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: I wonder how hard it would be for HE to implement some button on their tunnel portal that when selected will update Maxmind's (or whatever) geolocation for their allocated IPv6 prefixes to match the results returned when querying for their IPv4 tunnel end point address... I would suggest to make it optional since some may not want to have this functionality by default but if you are dying for netflix and are in whatever geolocation netflix deems acceptable this may solve the issue. On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot wrote: > How about: > > Dear Netflix network engineer who?s on the NANOG list. Could you please > get Netflix to fall back to ipv4 if you block your customer?s ipv6 because > it?s in an HE tunnel? Lots of people who want to watch Netflix, be able to > reach the whole internet, and have Verizon FiOS would really appreciate it. > > Thanks, > John > > John Lightoot > > > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From mhuff at ox.com Thu Jun 9 14:19:32 2016 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jun 2016 14:19:32 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: <1001ec558600491da291c2c6d41c352e@pur-vm-exch13n2.ox.com> I think you are missing the point. The problem is not that the GeoIP info is missing, the problem with the HE.tunnel is that the GeoIP is not set by the provider by verifiable means. Letting end-users set their GeoIP information is a non-starter for the content provider and they would still require a ban. A solution would be for HE to automatically set the IPv6 geoip based on the geoip of the IPv4 source address with no user overrides. Since the whole process would be fragile (people change their IPv4 source address frequently when travelling, etc...) and the delay it takes to put the GeoIP into maxmind's database, etc..., I don't know how well it would work, but it would probably be the best bet. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Still > Sent: Thursday, June 9, 2016 10:10 AM > To: John Lightfoot > Cc: North American Network Operators' Group > Subject: Re: Netflix banning HE tunnels > > I wonder how hard it would be for HE to implement some button on their > tunnel portal that when selected will update Maxmind's (or whatever) > geolocation for their allocated IPv6 prefixes to match the results > returned > when querying for their IPv4 tunnel end point address... > > I would suggest to make it optional since some may not want to have > this > functionality by default but if you are dying for netflix and are in > whatever geolocation netflix deems acceptable this may solve the issue. > > > > On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot > wrote: > > > How about: > > > > Dear Netflix network engineer who?s on the NANOG list. Could you > please > > get Netflix to fall back to ipv4 if you block your customer?s ipv6 > because > > it?s in an HE tunnel? Lots of people who want to watch Netflix, be > able to > > reach the whole internet, and have Verizon FiOS would really > appreciate it. > > > > Thanks, > > John > > > > John Lightoot > > > > > > > > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ From stillwaxin at gmail.com Thu Jun 9 14:33:20 2016 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 9 Jun 2016 10:33:20 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <1001ec558600491da291c2c6d41c352e@pur-vm-exch13n2.ox.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <1001ec558600491da291c2c6d41c352e@pur-vm-exch13n2.ox.com> Message-ID: Uhm I think you misunderstood me. What you describe matches what I described. I never suggested the user can override it with it another value, I am suggesting that a user may want to keep it to whatever default value it is as a matter of privacy concerns. Otherwise use the IPv4 tunnel end point IP. As for the point about people moving around frequently I would consider that a pretty far reaching use case and most likely not worth considering any action for. On Thu, Jun 9, 2016 at 10:19 AM, Matthew Huff wrote: > I think you are missing the point. The problem is not that the GeoIP info > is missing, the problem with the HE.tunnel is that the GeoIP is not set by > the provider by verifiable means. Letting end-users set their GeoIP > information is a non-starter for the content provider and they would still > require a ban. > > A solution would be for HE to automatically set the IPv6 geoip based on > the geoip of the IPv4 source address with no user overrides. Since the > whole process would be fragile (people change their IPv4 source address > frequently when travelling, etc...) and the delay it takes to put the GeoIP > into maxmind's database, etc..., I don't know how well it would work, but > it would probably be the best bet. > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Still > > Sent: Thursday, June 9, 2016 10:10 AM > > To: John Lightfoot > > Cc: North American Network Operators' Group > > Subject: Re: Netflix banning HE tunnels > > > > I wonder how hard it would be for HE to implement some button on their > > tunnel portal that when selected will update Maxmind's (or whatever) > > geolocation for their allocated IPv6 prefixes to match the results > > returned > > when querying for their IPv4 tunnel end point address... > > > > I would suggest to make it optional since some may not want to have > > this > > functionality by default but if you are dying for netflix and are in > > whatever geolocation netflix deems acceptable this may solve the issue. > > > > > > > > On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot > > wrote: > > > > > How about: > > > > > > Dear Netflix network engineer who?s on the NANOG list. Could you > > please > > > get Netflix to fall back to ipv4 if you block your customer?s ipv6 > > because > > > it?s in an HE tunnel? Lots of people who want to watch Netflix, be > > able to > > > reach the whole internet, and have Verizon FiOS would really > > appreciate it. > > > > > > Thanks, > > > John > > > > > > John Lightoot > > > > > > > > > > > > > > > -- > > [stillwaxin at gmail.com ~]$ cat .signature > > cat: .signature: No such file or directory > > [stillwaxin at gmail.com ~]$ > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From mhuff at ox.com Thu Jun 9 14:48:01 2016 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jun 2016 14:48:01 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <1001ec558600491da291c2c6d41c352e@pur-vm-exch13n2.ox.com> Message-ID: Your correct. I misread your email. Not enough blood in my caffeine stream yet. I think your idea of a button and/or a daily/weekly update to maxmind based on the source IPv4 address would be a good idea regardless of Netflix. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Michael Still [mailto:stillwaxin at gmail.com] Sent: Thursday, June 9, 2016 10:33 AM To: Matthew Huff Cc: John Lightfoot ; North American Network Operators' Group Subject: Re: Netflix banning HE tunnels Uhm I think you misunderstood me. What you describe matches what I described. I never suggested the user can override it with it another value, I am suggesting that a user may want to keep it to whatever default value it is as a matter of privacy concerns. Otherwise use the IPv4 tunnel end point IP. As for the point about people moving around frequently I would consider that a pretty far reaching use case and most likely not worth considering any action for. On Thu, Jun 9, 2016 at 10:19 AM, Matthew Huff > wrote: I think you are missing the point. The problem is not that the GeoIP info is missing, the problem with the HE.tunnel is that the GeoIP is not set by the provider by verifiable means. Letting end-users set their GeoIP information is a non-starter for the content provider and they would still require a ban. A solution would be for HE to automatically set the IPv6 geoip based on the geoip of the IPv4 source address with no user overrides. Since the whole process would be fragile (people change their IPv4 source address frequently when travelling, etc...) and the delay it takes to put the GeoIP into maxmind's database, etc..., I don't know how well it would work, but it would probably be the best bet. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Still > Sent: Thursday, June 9, 2016 10:10 AM > To: John Lightfoot > > Cc: North American Network Operators' Group > > Subject: Re: Netflix banning HE tunnels > > I wonder how hard it would be for HE to implement some button on their > tunnel portal that when selected will update Maxmind's (or whatever) > geolocation for their allocated IPv6 prefixes to match the results > returned > when querying for their IPv4 tunnel end point address... > > I would suggest to make it optional since some may not want to have > this > functionality by default but if you are dying for netflix and are in > whatever geolocation netflix deems acceptable this may solve the issue. > > > > On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot > > wrote: > > > How about: > > > > Dear Netflix network engineer who?s on the NANOG list. Could you > please > > get Netflix to fall back to ipv4 if you block your customer?s ipv6 > because > > it?s in an HE tunnel? Lots of people who want to watch Netflix, be > able to > > reach the whole internet, and have Verizon FiOS would really > appreciate it. > > > > Thanks, > > John > > > > John Lightoot > > > > > > > > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From sander at steffann.nl Thu Jun 9 15:35:05 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 9 Jun 2016 17:35:05 +0200 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> Message-ID: <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Hi, > Op 8 jun. 2016, om 23:39 heeft John Lightfoot het volgende geschreven: > > How about: > > Dear Netflix network engineer who?s on the NANOG list. Could you please get Netflix to fall back to ipv4 Just for geolocation please, the streaming works fine over IPv6 :) > if you block your customer?s ipv6 because it?s in an HE tunnel? Lots of people who want to watch Netflix, be able to reach the whole internet, and have Verizon FiOS would really appreciate it. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.p.lacey at gmail.com Thu Jun 9 17:30:38 2016 From: daniel.p.lacey at gmail.com (Dan Lacey) Date: Thu, 9 Jun 2016 11:30:38 -0600 Subject: Monitoring system recommendation In-Reply-To: <57589E91.4080006@zoidtechnologies.com> References: <57589E91.4080006@zoidtechnologies.com> Message-ID: <2f314042-3fdf-1ffe-3e0c-d2643c49762b@gmail.com> Yes, but depends on HW. They support some pretty huge environments. You have to have "enough" IOPs to keep up with the polling, DB and RRD data. Then there will never be a "heavy" load... I would contact them and based on your needs ask them what HW you will need for your implementation. You can get real world info from the mailing list: https://sourceforge.net/p/opennms/mailman/ I would suggest the opennms-discuss list. On 6/8/16 4:39 PM, Jeff wrote: > On 06/06/2016 10:18 AM, Manuel Mar?n wrote: >> Dear Nanog community > [...snipped...] >> Your input is really appreciated it >> >> Thank you and have a great day >> >> Regards >> > I have not used openNMS in production.. does it work well under heavy load? > > regards, > J > > From asr at latency.net Thu Jun 9 17:32:24 2016 From: asr at latency.net (Adam Rothschild) Date: Thu, 9 Jun 2016 13:32:24 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Message-ID: I think tunnelbroker.net is an great community service, and a significant factor in global IPv6 adoption. For one, it's allowed me to experiment with v6 from my home ~5 miles from NYC, where there are still no options for native connectivity. Hats off to Mike and the entire HE team for maintaining this excellent resource, without much thanks or compensation. With that said, it's not perfect. Licensing restrictions aside, I can appreciate a content provider prohibiting some tunneled connections, out of basic QoE concern. Even if they're able to manage their path to the tunnel endpoint, they have no visibility into the connection between the broadband eyeball and the endpoint, which could be/commonly is a point of saturation. As best I can tell, there isn't even a direct adjacency between 2906 and 6939, further obfuscating things. While Happy Eyeballs (carefully not abbreviating as "HE" to add to confusion :-) certainly helps, it's not a panacea for dealing with intermittent loss issues, nor is it fully supported on a broad spectrum of client implementations. Rather than debate the relative merits and production-readiness of a free tunneling service, we should ask ourselves why this is still a thing, here in 2016. How can we, as a community, help move the needle on v6 deployment on broadband networks, in cases where competitive forces and market pressure don't exist? $0.02, -a On Thu, Jun 9, 2016 at 11:35 AM, Sander Steffann wrote: > Hi, > >> Op 8 jun. 2016, om 23:39 heeft John Lightfoot het volgende geschreven: >> >> How about: >> >> Dear Netflix network engineer who?s on the NANOG list. Could you please get Netflix to fall back to ipv4 > > Just for geolocation please, the streaming works fine over IPv6 :) > >> if you block your customer?s ipv6 because it?s in an HE tunnel? Lots of people who want to watch Netflix, be able to reach the whole internet, and have Verizon FiOS would really appreciate it. > > Cheers, > Sander > From Steve.Mikulasik at civeo.com Thu Jun 9 18:47:46 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 9 Jun 2016 18:47:46 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Message-ID: https://i.imgur.com/LvVHJZf.png I had to make this, talking about IPv6 or geo-ip in nanog is like throwing blood in the water :) From john at west-canaan.net Thu Jun 9 19:25:10 2016 From: john at west-canaan.net (John Zettlemoyer) Date: Thu, 9 Jun 2016 15:25:10 -0400 Subject: novell.com Message-ID: <42908c42-d77b-418e-9a24-631b2efb222a@west-canaan.net> Could someone from Novell / Attachmate Corporation contact me off list. We are showing high latency getting to www.novell.com and dropped traffic. Currently, we are unable to reach anything at novell.com 15 156 ms 371 ms 229 ms tg9-1.ar10.lsvlnv23.integra.net [209.63.100.146] 16 87 ms 86 ms 86 ms 67.138.209.58 17 468 ms 486 ms * 192.94.118.247 18 * * * Request timed out. 19 100 ms 100 ms 100 ms vibe.novell.com [130.57.66.5] Thank you John Zettlemoyer Sr. Director of I.T. Infrastructure :: WCiT - West-Canaan LLC 856.310.1375 x221 :: john at wcit.net :: www.wcit.net Colocation, Cloud, Dedicated, Email, Backups, Access, Networks, etc. "I keep the lights blinking out of sequence!" From cryptographrix at gmail.com Thu Jun 9 19:55:57 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Thu, 09 Jun 2016 19:55:57 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Message-ID: I suspect we should just accept that IPv6 is never actually happening with all this infighting of its own very vocal proponents. On Thu, Jun 9, 2016 at 2:49 PM Steve Mikulasik wrote: > https://i.imgur.com/LvVHJZf.png > > I had to make this, talking about IPv6 or geo-ip in nanog is like throwing > blood in the water :) > > > > > From kotikalapudi.sriram at nist.gov Thu Jun 9 21:53:38 2016 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Thu, 9 Jun 2016 21:53:38 +0000 Subject: intra-AS messaging for route leak prevention In-Reply-To: <14cdb926-c2fa-a726-46fb-c0554e92ac54@seacom.mu> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net>, <14cdb926-c2fa-a726-46fb-c0554e92ac54@seacom.mu> Message-ID: This is great...the kind of inputs/insights I was hoping for. Thank you :) Sriram ________________________________________ From: Mark Tinka Sent: Wednesday, June 8, 2016 9:24 AM To: nanog-post at rsuc.gweep.net; Sriram, Kotikalapudi (Fed) Cc: Job Snijders; nanog at nanog.org Subject: Re: intra-AS messaging for route leak prevention On 8/Jun/16 14:48, Joe Provo wrote: > > "There are more routing policies in heavan and earth, Sriram > Than are dreamt of in your draft." > > But in my experience, community tagging is by far the widest > deployment due to the broad support and extent of information > which can be carried. It is useful to note that AS_PATH if > often also involved on egress decisions. Agree. We use BGP communities extensively on all eBGP sessions to identify upstreams, peers, customers, special partners, e.t.c., on the inbound routing policy. Outbound routing policies will depend on the type of neighbor, i.e., upstream, peer, customer, special partner, e.t.c. At any rate, we use communities to determine what routes will be announced to what eBGP neighbor. Those communities will need to match the intended source of the route at some other point in the network. The only time we look at prefix lists is to ensure we send (or accept) nothing longer than a /24 (IPv4) or a /48 (IPv6) to (and from) an eBGP neighbor of any kind. That said, further granularity in the outbound routing policy toward upstreams will allow for transmission of longest-match (/32 IPv4 and /128 IPv6) to support RTBH requirements. This is a co-ordinated routing policy, so it is not harmful to us, our upstreams or the wider Internet. We'd also accept these prefix lengths from BGP customers as part of their standard RTBH capability they get when they buy IP Transit from us; again, highly controlled and co-ordinated to never cause any harm to us, the customer or the wider Internet, while still being 100% functional for the customer. Ultimately, once a routing policy is in place on a specific router, we are never touching that router again as the edge moves around, i.e., customers, peers, special partners, e.t.c., come on-board, move around, e.t.c. This creates natural safe guards against cock-ups, although the goal is always to eliminate cock-ups from the get-go (automation of repetitive provisioning tasks makes this goal easier to attain). Coupled with our insistence on creating matching prefix and AS_PATH filters for all customers (after being checked against the relevant RIR WHOIS database to avoid hijack), we've been fortunate to never be in a position where our network is leaking routes, unintentionally or otherwise. Work continues to further harden this so that it never happens. Mark. From jfbeam at gmail.com Thu Jun 9 22:54:02 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jun 2016 18:54:02 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Message-ID: On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild wrote: > How can we, as a community, help move the needle > on v6 deployment on broadband networks, in cases where competitive > forces and market pressure don't exist? You left out "consumer demand". And I would add consumer knowledge as well -- there won't be any demand until one knows to ask (it's cablecards all over again.) There are 7 billion people on Earth. I suspect it's a stretch to say even 100,000 of them understand IPv6. While there are a few ISPs who "have" IPv6, many of them have done so mostly for show -- World IPv6 Day marketing ploy[*]. For now, we'll have to continue the policy of public shaming... Despite TWC's claims ("IPv6 has been enabled on 100% of our cable Internet network.") [http://www.timewarnercable.com/en/support/faqs/faqs-internet/ipv6/why-don_t-i-have-ipv6-yet-.html] there's a very long list of exceptions... like: it's not been enabled on *your* headend, or *your* modem doesn't have it enabled, or we turned if off on that modem due to firmware bugs for which we've had fixes for over a year, or you're a business account that hasn't had it enabled, or you're a "powered by" customer for whom the banner ISP hasn't bothered to assign a prefix (*cough* f'ing Earthlink *cough*) In fact, Earthlink's only IPv6 presence, ever, was the pet project of a single engineer. He was kicked out in 2008. The kludge ("auto-tunnel") continued to function for a few years before the hardware was turn off, recycled, etc. And then the entire research site disappear around 2010. Btw, they're still announcing that prefix [http://bgp.he.net/net/2001:4840::/32#_irr] --Ricky [*] I know my company did. Our "IPv6 Presence" was a VM somewhere running nginx to proxy to the (amazon hosted) IPv4 sites. And it was gone the next day. From marka at isc.org Thu Jun 9 23:17:37 2016 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jun 2016 09:17:37 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Thu, 09 Jun 2016 18:54:02 -0400." References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> Message-ID: <20160609231737.E3C074B129C6@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild > wrote: > > How can we, as a community, help move the needle > > on v6 deployment on broadband networks, in cases where competitive > > forces and market pressure don't exist? > > You left out "consumer demand". And I would add consumer knowledge as well > -- there won't be any demand until one knows to ask (it's cablecards all > over again.) There are 7 billion people on Earth. I suspect it's a stretch > to say even 100,000 of them understand IPv6. While there are a few ISPs > who "have" IPv6, many of them have done so mostly for show -- World IPv6 > Day marketing ploy[*]. The average consumer wants a "internet connection". They don't care if it is IPv4, IPv6 or IPvX. They just want the bits to move. What will happen is that as CGN starts to break things for people like gamers they will start asking for IPv6, like us network geeks ask for IPv6. The average consumer doesn't know what they have been sold does not deliver a real internet connection where every every machine is addressable. That being said, those who know what a internet connection should be delivering should be advocating for the real deal. It is our ethical responsability to do this for our customers. > For now, we'll have to continue the policy of public shaming... > > Despite TWC's claims ("IPv6 has been enabled on 100% of our cable Internet > network.") > [http://www.timewarnercable.com/en/support/faqs/faqs-internet/ipv6/why-don_t- > i-have-ipv6-yet-.html] > there's a very long list of exceptions... like: it's not been enabled on > *your* headend, or *your* modem doesn't have it enabled, or we turned if > off on that modem due to firmware bugs for which we've had fixes for over > a year, or you're a business account that hasn't had it enabled, or you're > a "powered by" customer for whom the banner ISP hasn't bothered to assign > a prefix (*cough* f'ing Earthlink *cough*) > > In fact, Earthlink's only IPv6 presence, ever, was the pet project of a > single engineer. He was kicked out in 2008. The kludge ("auto-tunnel") > continued to function for a few years before the hardware was turn off, > recycled, etc. And then the entire research site disappear around 2010. > Btw, they're still announcing that prefix > [http://bgp.he.net/net/2001:4840::/32#_irr] > > --Ricky > > [*] I know my company did. Our "IPv6 Presence" was a VM somewhere running > nginx to proxy to the (amazon hosted) IPv4 sites. And it was gone the next > day. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baldur.norddahl at gmail.com Fri Jun 10 01:41:05 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 10 Jun 2016 03:41:05 +0200 Subject: Netflix banning HE tunnels In-Reply-To: <20160609231737.E3C074B129C6@rock.dv.isc.org> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: On 10 June 2016 at 01:17, Mark Andrews wrote: > The average consumer wants a "internet connection". They don't > care if it is IPv4, IPv6 or IPvX. They just want the bits to move. > What will happen is that as CGN starts to break things for people > like gamers they will start asking for IPv6, like us network geeks > ask for IPv6. > The use case is a user that got a CGN solution plus IPv6. He wants to view images from his home surveillance camera, so that he can tell that the cat is still doing ok. His friends tells him to do a port forward, but that is not possible due to the CGN. Then he reads on NANOG that since he has IPv6 he can just connect to the camera with that. Except few to none cameras come with IPv6. This is the sad state of things currently :-(. Regards, Baldur From bross at pobox.com Thu Jun 9 18:55:30 2016 From: bross at pobox.com (Brandon Ross) Date: Thu, 9 Jun 2016 14:55:30 -0400 (EDT) Subject: Extra Fairmont Rooms Message-ID: I've ended up with some extra room reservations at the Fairmont Chicago. If you can make use of any of these reservations, send me a direct email with the name you'd like me to put on the room. First come, first served, so if your primary choice(s) aren't available, let me know if you have a second choice. I'll reply with the confirmation number so you can call the hotel and guarantee the room with your credit card. 6/16-17 $242 Fairmont Room with King Bed 6/11-17 $299 Deluxe Room with King Bed 6/15-16 $278 Fairmont PURE Room King NS 6/15-16 $260 Fairmont Double/Double NS -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From anthony at handynetworks.com Thu Jun 9 19:42:29 2016 From: anthony at handynetworks.com (Anthony Francis - Handy Networks LLC) Date: Thu, 9 Jun 2016 19:42:29 +0000 Subject: Telia Message-ID: <19DC6F1F-EF82-4A71-8FAD-726A04910028@handynetworks.com> Hello All, Telia is having a major outage and they have confirmed with us the same. If you are peering with Telia you may wish to shut down your session until the issue is resolved. ? Anthony Francis // Handy Networks LLC Hosting Support Manager Providing Dedicated Server, IaaS and Colocation Hosting Solutions Tel: 303-414-6904 | Fax: 303-414-6912 www.handynetworks.com From anthony at handynetworks.com Thu Jun 9 20:19:13 2016 From: anthony at handynetworks.com (Anthony Francis - Handy Networks LLC) Date: Thu, 9 Jun 2016 20:19:13 +0000 Subject: Telia Message-ID: Hello All, It looks like they resolved the issue: ?Dear Customer, Our core team has resolved an issue on our backbone causing U.S. customers packet loss. The root cause analysis will follow and we expect no further packet loss due to this issue.? ? Anthony Francis // Handy Networks LLC Hosting Support Manager Providing Dedicated Server, IaaS and Colocation Hosting Solutions Tel: 303-414-6904 | Fax: 303-414-6912 www.handynetworks.com From tspprmng at feec.vutbr.cz Thu Jun 9 22:44:34 2016 From: tspprmng at feec.vutbr.cz (TSP 2016) Date: Fri, 10 Jun 2016 00:44:34 +0200 Subject: Participation IEEE R8 | TSP 2016 39th Int. Conf. on Telecommunications and Signal Processing | June 27-29, 2016 Vienna, Austria Message-ID: <5759F152.5050200@feec.vutbr.cz> ************************************************************************************ *** CALL FOR PARTICIPATION *** ************************************************************************************ 2016 39th International Conference on Telecommunications and Signal Processing (TSP) June 27-29, 2016, Hilton Garden Inn Vienna South, Hertha-Firnberg-Strasse 5, 1100 Vienna, Austria http://tsp.vutbr.cz/ Technically co-sponsored by IEEE Region 8 , EEE Austria Section , IEEE Czechoslovakia Section , IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter , and IEEE Croatia Section Communications Chapter . The TSP 2016 Proceedings, containing presented papers at the Conference, will be sent for indexing in the IEEE Xplore? digital library registered under _IEEE Conference Record #38642 _, SCOPUS , Conference Proceedings Citation Index (CPCI) of Thomson Reuters , DBLP , and Google Scholar databases. ************************************************************************************ Dear Colleague, On behalf of the organizing committee of the conference, we would like to invite you to participate in the *2016 39th International Conference on Telecommunications and Signal Processing (TSP - *http://tsp.vutbr.cz/*)*, which will be held on *June 27-29, 2016, in Vienna, Austria*. Continuing the tradition of TSP, the 2016 edition of the conference will be an excellent opportunity for networking with international experts and to experience a rich mix of excellent technical and social programs. The TSP Conference serves as a premier annual international forum to promote the exchange of the latest advances in telecommunication technology and signal processing. The aim of the Conference is to bring together both novice and experienced scientists, developers, and specialists, to meet new colleagues, collect new ideas, and establish new cooperation between research groups from universities, research centers, and private sectors from the whole Europe, America, Asia, Australia, and Africa. *CONFERENCE PROGRAMME: * TSP 2016 programme includes outstanding plenary talks, superb technical sessions, and wonderful networking and social events. */_Conference highlights include: _/* _Invited Keynotes: _ - /Professor Ray-Guang Cheng/ (Department of Electronic and Computer Engineering, National Taiwan University of Science and Technology (NTUST), Taipei, Taiwan) - /Title/: Machine Type Communications: Challenges and Perspectives - /Professor Ram M. Narayanan/ (Department of Electrical Engineering, The Pennsylvania State University, USA) - /Title/: Sensing and Communications Using Ultrawideband Random Noise and Chaotic Waveforms - /Professor Ahmed Elwakil/ (Department of Electrical and Computer Engineering, College of Engineering, University of Sharjah, UAE) - /Title/: Fractional-Order Circuits and Systems: An Emerging Interdisciplinary Research Topic _Technical Program: _ 23 technical sessions consisting of oral lecture and poster sessions _Special Sessions: _* */Special Session 1/: Fractional-Order Systems: Theory, Design and Applications /Special Session 2/: Signal and Image Processing for Biometric Human Recognition: Theory, Methods, Applications and Systems /Special Session 3/: Monitoring and Control Based on Image Processing /Special Session 4/: Photonic Networks and Services: Theory, Design, Modeling, and Applications _Social and Networking Events_: One per each day. *CONFERENCE TOPICS: *Topics of TSP 2016 Conference include: /AREA 1: Telecommunications / 1. Information Systems 2. Network Services 3. Network Technologies 4. Telecommunication Systems 5. Modelling, Simulation and Measurement /AREA 2: Signal Processing / 6. Analog Signal Processing 7. Audio, Speech and Language Processing 8. Biomedical Signal Processing 9. Digital Signal Processing 10. Image and Video Signal Processing *COMMITTEES: * - Karol Moln?r, Honeywell International, s.r.o., Czech Republic, IEEE Member - General Chair - Norbert Herencs?r, Brno University of Technology, Czech Republic, IEEE Senior Member ? IEEE Czechoslovakia Section CAS/COM/SP Joint Chapter Chair - Deputy Chair - Philipp Svoboda, Vienna University of Technology, Austria, IEEE Senior Member - Local Arrangement Chair - Ji?? Ho?ek, Brno University of Technology, Czech Republic, IEEE Member - Industrial & Exhibition Chair - Jaroslav Koton, Brno University of Technology, Czech Republic, IEEE Senior Member - Publication Chair - N?ndor M?trai, Asszisztencia Congress Bureau, Hungary - Finance Chair /Steering Committee: / - Ram M. Narayanan, The Pennsylvania State University, USA - Full Professor, IEEE Fellow - Markus Rupp, Vienna University of Technology, Austria - Dean, IEEE Fellow - Ismail Kaya, Karadeniz Technical University, Turkey, IEEE Member - Sridhar Krishnan, Ryerson University, Canada - Associate Dean, IEEE Senior Member - Mario Ku?ek, University of Zagreb, Croatia, IEEE Member - IEEE Croatia Section Communications Chapter Chair - Shahram Minaei, Dogus University, Turkey - Full Professor, IEEE Senior Member - Kimio Oguchi, Seikei University, Japan - Full Professor, IEEE Member - Jakub P?ksi?ski, West Pomeranian University of Technology, Poland - Hector Perez-Meana, National Polytechnic Institute, Mexico - Full Professor, IEEE Senior Member - Vladimir Poulkov, Technical University of Sofia, Bulgaria - Dean, IEEE Senior Member - Zden?k Sm?kal, Brno University of Technology, Czech Republic - Full Professor, IEEE Senior Member - Attila Vid?cs, Budapest University of Technology and Economics, Hungary - Deputy Head of Department - Miroslav Voz??k, V?B-Technical University of Ostrava, Czech Republic - Department Chair, IEEE Member - Drago ?agar, University of Osijek, Croatia - Dean, IEEE Senior Member *ORGANIZERS: *The TSP 2016 is IEEE technically co-sponsored Conference organized in cooperation with eleven universities: - Department of Telecommunications, Brno University of Technology, Brno, Czech Republic - Department of Telecommunications and Media Informatics, Budapest University of Technology and Economics, Budapest, Hungary - Department of Electrical and Electronics Engineering, Karadeniz Technical University, Trabzon, Turkey - Faculty of Electrical Engineering, West Pomeranian University of Technology, Szczecin, Poland - Department of Telecommunications, VSB - Technical University of Ostrava, Ostrava, Czech Republic - Institute of Telecommunications, Slovak University of Technology, Bratislava, Slovak Republic - Laboratory for Telecommunications, University of Ljubljana, Ljubljana, Slovenia - Department of Telecommunication Engineering, Czech Technical University in Prague, Prague, Czech Republic - Faculty of Electrical Engineering, University of Osijek, Osijek, Croatia - Faculty of Telecommunications, Technical University of Sofia, Sofia, Bulgaria - Information Networking Laboratory, Graduate School and Faculty of Science and Technology, Seikei University, Tokyo, Japan *REGISTRATION DEADLINES: Listeners' Registration and Payment: *June 27, 2016 *CONTACTS: *Formore information please visit the Conference website at http://tsp.vutbr.cz/. We are also ready to answer your questions emailed to tsp at feec.vutbr.cz . Looking forward to meeting you in Vienna, Austria. With best regards, Norbert Herencsar and Karol Molnar TSP 2016 Organizing Committee Members Web: http://tsp.vutbr.cz/ E-mail: tsp at feec.vutbr.cz Follow us on: - Facebook https://www.facebook.com/tspconf - Twitter https://twitter.com/TSPconf =============================================================== Department of Telecommunications Faculty of Electrical Engineering and Communication Brno University of Technology Technicka 3082/12 616 00 Brno Czech Republic From jfbeam at gmail.com Fri Jun 10 02:54:02 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jun 2016 22:54:02 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <20160609231737.E3C074B129C6@rock.dv.isc.org> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews wrote: > The average consumer wants a "internet connection". And sadly, they haven't a clue what that means. They plug the thing into the other thing, and they can click on things in their web browser. They're why we have boxes with color coded connectors and cables. > What will happen is that as CGN starts to break things for people > like gamers they will start asking for IPv6, like us network geeks > ask for IPv6. Correction: after much lamenting and whining to their gaming buddies via various forums until someone boils it all down to one word "IPv6". And then were back to ape mentality... they don't know what it is, but they now know that's what they need. They have, thus, been "educated" -- to a microscopic level only a physicist can measure, but they will now demand "IPv6 (whatever that is.)" > That being said, those who know what a internet connection should > be delivering should be advocating for the real deal. It is our > ethical responsability to do this for our customers. It would be nice to live in a world where that were the case. However, the world we live in is run my bean counters, and the marketing department. IPv6 is a huge project that is seen by them as an unnecessary expense. Everything works right now, right? CGN is easy; it's just one big box. 6RD is just one more box, and then it's the customers problem to use it (etc.) Companies do what makes them money without costing them money. IPv6 is the exact opposite, it costs a lot and generates nothing. I agree, we should've turned this shit on a decade ago (or more.) Of course, the whole mess is exactly what you get out of "designed by committee". With zero interoperability, and no viable migration paths, it's a Forklift Upgrade(tm). People don't do Forklift Upgrades(tm). "So you want me to rip out all the token-ring gear and replace it with ethernet?" That was a hard sell, and there was interoperability and bridging technology. "So you want me to throw away by Novell IPX network and replace it with TCP/IP?" While Novell did work over IP in the later years, people hung on to their "works perfectly for our needs" IPX infrastructure for decades -- IPX WANs, even. (some still exists to this day. In fact, the massive kyocera printer here still supports IPX. And Appletalk! Holy crap, my horse isn't dead; they still don't talk to each other.) From jfbeam at gmail.com Fri Jun 10 02:57:33 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jun 2016 22:57:33 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: On Thu, 09 Jun 2016 21:41:05 -0400, Baldur Norddahl wrote: > Then he reads on NANOG that since he has IPv6 > he can just connect to the camera with that. ... Only to find the built-in stateful firewall blocks unsolicited inbound connections. Now he has to figure out how to manipulate ACLs. Or (more likely) he turns that "pesky firewall" off. (followed by the eventual hacking of every device he owns.) NAT may not be security, yet it's the only thing securing billions of people. From kauer at biplane.com.au Fri Jun 10 03:12:30 2016 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Jun 2016 13:12:30 +1000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: <1465528350.1518.383.camel@biplane.com.au> On Thu, 2016-06-09 at 22:54 -0400, Ricky Beam wrote: > zero interoperability, and no viable migration paths, > it's a Forklift Upgrade(tm). You say that with such confidence! Doesn't make it true. Plenty of people around the world have upgraded, and I bet you couldn't find ONE that did it as a "forklift upgrade" - or at least not for that purpose alone. Of course, the longer you leave it the more likely you will be forced to do it that way. All you have to do is some basic design work, get your engineers on board, make IPv6 part of your normal equipment replacement cycle, and within three to five years you will be IPv6 capable. Oh wait - you didn't start doing that fifteen years ago? Ten years ago? Five years ago? Every year since then? When everyone was telling you you should? Oh dear... FX off: "Charlie! Fire up the forklifts! We're gonna need all you got!" Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 From randy at psg.com Fri Jun 10 03:54:16 2016 From: randy at psg.com (Randy Bush) Date: Thu, 09 Jun 2016 20:54:16 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: >> The average consumer wants a "internet connection". > And sadly, they haven't a clue what that means. no; happily. this is not 1904 where you have to be a mechanic to drive a car. i just want my mtv; shut up and make it work. From randy at psg.com Fri Jun 10 03:57:08 2016 From: randy at psg.com (Randy Bush) Date: Thu, 09 Jun 2016 20:57:08 -0700 Subject: Netflix banning HE tunnels In-Reply-To: <1465528350.1518.383.camel@biplane.com.au> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: >> zero interoperability, and no viable migration paths, it's a Forklift >> Upgrade(tm). > > You say that with such confidence! Doesn't make it true. https://archive.psg.com/120206.nanog-v4-life-extension.pdf randy, who works for the first isp to deploy ipv6 to customers From kauer at biplane.com.au Fri Jun 10 04:20:53 2016 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Jun 2016 14:20:53 +1000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: <1465532453.1518.401.camel@biplane.com.au> On Thu, 2016-06-09 at 20:57 -0700, Randy Bush wrote: > > > zero interoperability, and no viable migration paths, it's a > > > Forklift > > > Upgrade(tm). > > > > You say that with such confidence! Doesn't make it true. > > https://archive.psg.com/120206.nanog-v4-life-extension.pdf Zero interoperability is technically true. However the two protocols can live very happily side by side, NOT interfering with each other. Ricky saying "zero interoperability" is technically true - but not really relevant. As to "no viable upgrade paths" you seem to be a good example of NOT that. Did you replace all your equipment in one great and costly spasm to achieve IPv6 delivery to customers? Getting IPv6 up and running is not a simple thing, but nor is it leaking-blood-from-the ears territory. "It's a forklift upgrade! There are no viable upgrade paths! Zero interoperability!" - this is just Chicken Little stuff. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 From cb.list6 at gmail.com Fri Jun 10 04:26:57 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 9 Jun 2016 21:26:57 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: On Thursday, June 9, 2016, Randy Bush wrote: > >> zero interoperability, and no viable migration paths, it's a Forklift > >> Upgrade(tm). > > > > You say that with such confidence! Doesn't make it true. > > https://archive.psg.com/120206.nanog-v4-life-extension.pdf > > randy, who works for the first isp to deploy ipv6 to customers > The PDF is not good advice IMHO. First is seldom as good as the last. From marka at isc.org Fri Jun 10 04:38:52 2016 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jun 2016 14:38:52 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Thu, 09 Jun 2016 22:54:02 -0400." References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: <20160610043852.63A604B1DAB6@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews wrote: > > The average consumer wants a "internet connection". > > And sadly, they haven't a clue what that means. They plug the thing into > the other thing, and they can click on things in their web browser. > They're why we have boxes with color coded connectors and cables. > > > What will happen is that as CGN starts to break things for people > > like gamers they will start asking for IPv6, like us network geeks > > ask for IPv6. > > Correction: after much lamenting and whining to their gaming buddies via > various forums until someone boils it all down to one word "IPv6". And > then were back to ape mentality... they don't know what it is, but they > now know that's what they need. They have, thus, been "educated" -- to a > microscopic level only a physicist can measure, but they will now demand > "IPv6 (whatever that is.)" > > > That being said, those who know what a internet connection should > > be delivering should be advocating for the real deal. It is our > > ethical responsability to do this for our customers. > > It would be nice to live in a world where that were the case. However, the > world we live in is run my bean counters, and the marketing department. > IPv6 is a huge project that is seen by them as an unnecessary expense. Absolute BS. IPv6 has never needed to be a huge project for a ISP compared to everything else a ISP does. It required some research and ensuring that you bought compatible equipement and things fell due for replacement. If you failed to do the research and therefore needed to do everthing in a rush then it might seem like a huge project. > Everything works right now, right? CGN is easy; it's just one big box. 6RD > is just one more box, and then it's the customers problem to use it (etc.) > Companies do what makes them money without costing them money. IPv6 is the > exact opposite, it costs a lot and generates nothing. 6rd is a joke the way most ISP's deploy it. One /64 per customer? What the hell are they thinking. 6rd also introduces PMTUD issues and rapid address renumbering that is necessary especially when also providing native IPv4. 6rd is nothing but a stopgap solution the same as a HE tunnel is a stopgap solution. But you can ignore that reality if you wish. A ISP that thinks 6rd is the end point when deploying IPv6 is doing their customers a disservice. > I agree, we should've turned this shit on a decade ago (or more.) > > Of course, the whole mess is exactly what you get out of "designed by > committee". With zero interoperability, and no viable migration paths, > it's a Forklift Upgrade(tm). Hey you do better. I've seen lots of people complain but I've yet to see anyone come up with a better solution. Talk is cheap. > People don't do Forklift Upgrades(tm). "So > you want me to rip out all the token-ring gear and replace it with > ethernet?" That was a hard sell, and there was interoperability and > bridging technology. "So you want me to throw away by Novell IPX network > and replace it with TCP/IP?" While Novell did work over IP in the later > years, people hung on to their "works perfectly for our needs" IPX > infrastructure for decades -- IPX WANs, even. (some still exists to this > day. In fact, the massive kyocera printer here still supports IPX. And > Appletalk! Holy crap, my horse isn't dead; they still don't talk to each > other.) No, we wanted you to enable IPv6 in parallel with IPv6 15+ years ago. It's not like it was that hard back then. I've not replaced a single piece of equipement to get IPv6 yet I have running IPv6 on most devices by being selective in my purchasing decisions as things needed replacing. There was no forklift upgrade. Everything was done piecemeal. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From blakjak at blakjak.net Fri Jun 10 04:48:20 2016 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 10 Jun 2016 16:48:20 +1200 Subject: Netflix banning HE tunnels In-Reply-To: <20160610043852.63A604B1DAB6@rock.dv.isc.org> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> Message-ID: <0e36af3e-9781-4f2b-1080-af915fff3755@blakjak.net> On 10/06/2016 4:38 p.m., Mark Andrews wrote: >> It would be nice to live in a world where that were the case. However, the >> world we live in is run my bean counters, and the marketing department. >> IPv6 is a huge project that is seen by them as an unnecessary expense. > Absolute BS. IPv6 has never needed to be a huge project for a ISP > compared to everything else a ISP does. It required some research > and ensuring that you bought compatible equipement and things fell > due for replacement. If you failed to do the research and therefore > needed to do everthing in a rush then it might seem like a huge > project. Router-jockeys and purists often cite this. I've done it myself. But there are a lot more moving parts in most service providers than simply the ones and zeros. Bandwidth Accounting, Billing, Provisioning systems in particular - and the developers/maintainers of these who have little or no knowledge of IPv6 and perhaps not a lot more than that of IPv4, except that it's more easily human-read and digested? This was very much my experience in more than one ISP job over recent years - the network kit is more than capable, it's the bits around the outside that need work. Even if routing and switching kit was subject to lifecycle-replacement every 5 years or so, software components that are in the background, 'just work' and suddenly are very black-boxy because the author has long since left the organisation and noone left behind knows how to make it IPv6ready... sometimes the forklift approach is what is left. Sorry this is tangental to the thread's focus but every time I see this particular argument trotted out I feel like it's overlooking the obvious; lack of sufficient forethought 10 years ago turns into significant piece of work today. A lesson? Yes, but hindsight is 20:20. Mark. From marka at isc.org Fri Jun 10 05:52:35 2016 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jun 2016 15:52:35 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Fri, 10 Jun 2016 16:48:20 +1200." <0e36af3e-9781-4f2b-1080-af915fff3755@blakjak.net> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <0e36af3e-9781 -4f2b-1080-af915fff3755@blakjak.net> Message-ID: <20160610055235.607D74B1E98E@rock.dv.isc.org> In message <0e36af3e-9781-4f2b-1080-af915fff3755 at blakjak.net>, Mark Foster writ es: > > > On 10/06/2016 4:38 p.m., Mark Andrews wrote: > >> It would be nice to live in a world where that were the case. However, the > >> world we live in is run my bean counters, and the marketing department. > >> IPv6 is a huge project that is seen by them as an unnecessary expense. > > Absolute BS. IPv6 has never needed to be a huge project for a ISP > > compared to everything else a ISP does. It required some research > > and ensuring that you bought compatible equipement and things fell > > due for replacement. If you failed to do the research and therefore > > needed to do everthing in a rush then it might seem like a huge > > project. > > Router-jockeys and purists often cite this. I've done it myself. > But there are a lot more moving parts in most service providers than > simply the ones and zeros. > Bandwidth Accounting, Billing, Provisioning systems in particular - and > the developers/maintainers of these who have little or no knowledge of > IPv6 and perhaps not a lot more than that of IPv4, except that it's more > easily human-read and digested? And the same applies to those systems. > This was very much my experience in more than one ISP job over recent > years - the network kit is more than capable, it's the bits around the > outside that need work. > Even if routing and switching kit was subject to lifecycle-replacement > every 5 years or so, software components that are in the background, > 'just work' and suddenly are very black-boxy because the author has long > since left the organisation and noone left behind knows how to make it > IPv6ready... sometimes the forklift approach is what is left. For most things conversion to support IPv6 is trivial. The hardest thing is getting someone to signoff on someone looking under the hood. > Sorry this is tangental to the thread's focus but every time I see this > particular argument trotted out I feel like it's overlooking the > obvious; lack of sufficient forethought 10 years ago turns into > significant piece of work today. A lesson? Yes, but hindsight is 20:20. And people were arguing 10+ years ago to start now so you don't need to do everything in a rush. What we got back then was "IPv6 won't take off". This isn't 20:20 hindsite. It's we told you so. > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tim at pelican.org Fri Jun 10 06:19:22 2016 From: tim at pelican.org (tim at pelican.org) Date: Fri, 10 Jun 2016 07:19:22 +0100 (BST) Subject: Netflix banning HE tunnels In-Reply-To: <0e36af3e-9781-4f2b-1080-af915fff3755@blakjak.net> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <0e36af3e-9781-4f2b-1080-af915fff3755@blakjak.net> Message-ID: <1465539562.450519746@apps.rackspace.com> On Friday, 10 June, 2016 05:48, "Mark Foster" said: > Router-jockeys and purists often cite this. I've done it myself. > But there are a lot more moving parts in most service providers than > simply the ones and zeros. > Bandwidth Accounting, Billing, Provisioning systems in particular - and > the developers/maintainers of these who have little or no knowledge of > IPv6 and perhaps not a lot more than that of IPv4, except that it's more > easily human-read and digested? +1. (Actually, +lots) Making the packet-shifting tin shift v6 packets is not that complex, certainly not in the normal cycle of equipment upgrades, and assuming you started thinking about it years ago. All the business systems that sit around it? Not so much. $DAYJOB has plenty of code, database structures etc that are built around "an IP address is no more than 15 characters long and matches '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you need development time - typically expensive analyst time to work out *what* you need to change, not just code-grinder make-the-field-bigger time. IT departments seem reluctant to provide that resource, unless you've got people at the very top of the business bought into the fact that you *need* to do IPv6. In my experience, the IT part of the business, even within an ISP, tends to be the part that loves their NAT == security and private addressing for everything[0], so just doesn't see what all the fuss is about... Even putting that aside, there are decisions to be made as a business around how you present IPv6 to the customer. Someone in Sales or Finance will want to be charging per /64 (or worse, per address). Support will want good canned answers to the "I have a public address now - where is my NAT?" calls. Tech Pre-Sales will need upskilling to think in networks, not addresses. Probably a whole bunch more. Regards, Tim. [0] In fairness, this is at least in part due to a decade of beatings from checklist-monkey auditors, but that's a different rant. From Valdis.Kletnieks at vt.edu Fri Jun 10 08:32:25 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2016 04:32:25 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <1465539562.450519746@apps.rackspace.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <0e36! af3e-9781-4f2b-1080-af915fff3755@blakjak.net> <1465539562.450519746@apps.rackspace.com> Message-ID: <156713.1465547545@turing-police.cc.vt.edu> On Fri, 10 Jun 2016 07:19:22 +0100, "tim at pelican.org" said: > All the business systems that sit around it? Not so much. $DAYJOB has > plenty of code, database structures etc that are built around "an IP address is > no more than 15 characters long and matches > '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you need > development time - typically expensive analyst time to work out *what* you need > to change, not just code-grinder make-the-field-bigger time. IT departments > seem reluctant to provide that resource, unless you've got people at the very > top of the business bought into the fact that you *need* to do IPv6. Some of us had those very same challenges - but managed to deploy IPv6 last century *anyhow*. Seriously - none of your code has been untouched for the 16 years so far in this century (if it in fact hasn't, you probably have bigger problems). You should have been doing incremental changes for IPv6 as you revisit code, so you didn't have a big pile of stuff left. And quite frankly, those of you who dragged their feet have really missed the boat. 10 years ago, you could have done an incremental deploy of IPv6, knowing that only people clued enough to manually enable it would be using it. So it was safe to put out a "It's sort of there, use at your own risk, let us know what you manage to break" mode. SLAAC only because you don't have the business infrastructure for DHCP6? Back then it was OK. That's long gone. Now every smart phone and laptop - pretty much everything that isn't a smart TV or a game console is going to try to use it, so you need to get it 100% right on the first try or your support center is going to catch fire. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From job at instituut.net Fri Jun 10 08:50:17 2016 From: job at instituut.net (Job Snijders) Date: Fri, 10 Jun 2016 10:50:17 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160608124811.GA75603@gweep.net> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> Message-ID: <20160610085017.GF2524@Vurt.local> Hi All, On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote: > On Wed, Jun 08, 2016 at 11:48:36AM +0000, Sriram, Kotikalapudi (Fed) wrote: > > Thanks for the inputs about the inter-AS messaging and route-leak > > prevention techniques between neighboring ASes. Certainly helpful > > information and also useful for the draft > > (draft-ietf-idr-route-leak-detection-mitigation). > > > > However, my question was focused on "intra-AS" messaging. About > > conveying from ingress to egress router (within your AS), the info > > regarding the type of peer from which the route was received at > > ingress. This info is used at the egress router to avoid leaking a > > route. > > > > Question: Is the "common practice" described in the original message > > http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html (see > > the stuff in quotes) sufficient or are there other ways in common > > use in which network operators convey the said information from > > ingress to egress router? > > But in my experience, community tagging is by far the widest > deployment due to the broad support and extent of information which > can be carried. I second this. One of NTT's design principles is to be very strict in what we accept (e.g. "postel was wrong") at the ingress point. At the ingress point the route announcement is weighted, judged, categorized & tagged. This decides 99% of what happens next: the egress points are merely executing what was "decided" at ingress (but exceptions are possible). > It is useful to note that AS_PATH if often also involved on egress > decisions. You say 'often', but I don't recognise that design pattern from my own experience. A weakness with the egress point (in context of route leak prevention) is that if you are filtering there, its already too late. If you are trying to prevent route leaks on egress, you have already accepted the leaked routes somewhere, and those leaked routes are best path somewhere in your network, which means you've lost. Having said that: as a conscious effort to mitigate (known) fragility in one's 'ingress policy deployment' an egress AS_PATH filter might be a good second layer of defense. It doesn't protect your own network but it helps block further spreading of garbage. Kind regards, Job From nanog at ics-il.net Fri Jun 10 14:00:36 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 10 Jun 2016 09:00:36 -0500 (CDT) Subject: Equinix IX Port Moves In-Reply-To: <55225649.1488.1465566997437.JavaMail.mhammett@ThunderFuck> Message-ID: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> Who has moved an Equinix IX port? We're told that it's a full cancellation, re-order, re IPs, re-peering, etc. Can anyone lend any input either way on that? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From morrowc.lists at gmail.com Fri Jun 10 14:46:17 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jun 2016 10:46:17 -0400 Subject: Equinix IX Port Moves In-Reply-To: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> References: <55225649.1488.1465566997437.JavaMail.mhammett@ThunderFuck> <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Jun 10, 2016 at 10:00 AM, Mike Hammett wrote: > Who has moved an Equinix IX port? We're told that it's a full > cancellation, re-order, re IPs, re-peering, etc. > > Can anyone lend any input either way on that? > > ?there are 2 meanings (at least) to 'move', did you mean: 1) move port from 1G to 10G (or 'change speed') 2) move port from cage/rack1 to cage/rack2 (endpoint move in your space(s) )? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From morrowc.lists at gmail.com Fri Jun 10 14:47:53 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jun 2016 10:47:53 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> Message-ID: On Tue, Jun 7, 2016 at 2:35 AM, Mark Tinka wrote: > One thing we do to reduce opportunistically hazardous vectors is to not > learn customer paths via peers. > ?so I can't be a customer of you and a network you peer with? (I'm sure I got your meaning wrong)? From mohta at necom830.hpcl.titech.ac.jp Fri Jun 10 15:21:52 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 11 Jun 2016 00:21:52 +0900 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: Randy Bush wrote: > https://archive.psg.com/120206.nanog-v4-life-extension.pdf > > randy, who works for the first isp to deploy ipv6 to customers To be a salmon, all we need is fish passages around dams of NAT boxes. As such, static binding on port/IP at NAT boxes is fine, as long as the binding information is statically known to end systems, and the end systems can reverse the binding and applications on the end systems at IP or transport layer, which means applications on the end systems can behave as unmodified applications on hosts directly connected to the Internet. That is, A NAT Box An End System | Applications | +-----------+ +------------------+ | NAT at L4 | | Reverse NAT at L4| +-----------+ +------------------+ | NAT at L3 | | Reverse NAT at L3| +-----------+ +------------------+ | L2 | | L2 | +-----------+ +------------------+ | L1 | | L1 | +-----------+ +------------------+ | | | | +-------+ v To The Internet is a proper solution for >4G people enjoy the end to end connectivity with IPv4. As such, the fish passages can be constructed, if translation behavior of the NAT boxes are known to end systems so that the end systems have sufficient knowledge to reverse the translation. Masataka Ohta From kuenzler at init7.net Fri Jun 10 16:02:46 2016 From: kuenzler at init7.net (Fredy Kuenzler) Date: Fri, 10 Jun 2016 18:02:46 +0200 Subject: Equinix IX Port Moves In-Reply-To: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> References: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> Message-ID: <72b5e5c7-7bb7-167c-2b75-c8142c3fbdb4@init7.net> On 10.06.2016 16:00, Mike Hammett wrote: > Who has moved an Equinix IX port? We're told that it's a full > cancellation, re-order, re IPs, re-peering, etc. > > Can anyone lend any input either way on that? Same issue here. Super complicated. I'm tempted to stop the process after the first step. -- Fredy Kuenzler --------------------- Fiber7. No Limits. https://www.fiber7.ch --------------------- Init7 (Switzerland) Ltd. AS13030 St.-Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ From Rod.Beck at hibernianetworks.com Fri Jun 10 16:04:39 2016 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Fri, 10 Jun 2016 16:04:39 +0000 Subject: Local Loop Provider Message-ID: Hi, I am looking for on-net tail providers between the sites below. Need both 100 and 1000 meg Layer 2 Ethernet point-to-point quotes. Two year terms. A point: 12101 Tukwila International Blvd, Seattle, WA 98168. Z point: 2001 6th Avenue, Westin Bld. A point: 4300 Brighton Blvd, Denver, CO 80216. Z point: 910 15th Street, Denver (Coresite). Regards, Roderick. Roderick Beck Sales Contractor - Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From mark.tinka at seacom.mu Fri Jun 10 17:02:50 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jun 2016 19:02:50 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160610085017.GF2524@Vurt.local> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> <20160610085017.GF2524@Vurt.local> Message-ID: <2e306a31-da1b-a28e-16d7-288fb992ac1a@seacom.mu> On 10/Jun/16 10:50, Job Snijders wrote: > I second this. One of NTT's design principles is to be very strict in > what we accept (e.g. "postel was wrong") at the ingress point. At the > ingress point the route announcement is weighted, judged, categorized & > tagged. This decides 99% of what happens next: the egress points are > merely executing what was "decided" at ingress (but exceptions are > possible). Agree. We do the same. > > You say 'often', but I don't recognise that design pattern from my own > experience. A weakness with the egress point (in context of route leak > prevention) is that if you are filtering there, its already too late. If > you are trying to prevent route leaks on egress, you have already > accepted the leaked routes somewhere, and those leaked routes are best > path somewhere in your network, which means you've lost. Agree. We don't do any AS_PATH filtering on egress. The only AS_PATH-anything we do on border routers is signal customer-initiated prepends via BGP communities. Those prepends are done at the border routers carrying the interested transit network. Otherwise, all egress filtering is based on BGP communities + general "no longer then /24, /48" rule as a fail-safe. Mark. From mark.tinka at seacom.mu Fri Jun 10 17:05:29 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jun 2016 19:05:29 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> Message-ID: <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> On 10/Jun/16 16:47, Christopher Morrow wrote: > > > ?so I can't be a customer of you and a network you peer with? You can, but we won't learn your paths via the peering session we would have with your other ISP. Mark. From morrowc.lists at gmail.com Fri Jun 10 17:08:48 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jun 2016 13:08:48 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> Message-ID: On Fri, Jun 10, 2016 at 1:05 PM, Mark Tinka wrote: > > > On 10/Jun/16 16:47, Christopher Morrow wrote: > > > > ?so I can't be a customer of you and a network you peer with? > > > You can, but we won't learn your paths via the peering session we would > have with your other ISP. > > ?oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?? From asr at latency.net Fri Jun 10 17:17:18 2016 From: asr at latency.net (Adam Rothschild) Date: Fri, 10 Jun 2016 13:17:18 -0400 Subject: Equinix IX Port Moves In-Reply-To: <72b5e5c7-7bb7-167c-2b75-c8142c3fbdb4@init7.net> References: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> <72b5e5c7-7bb7-167c-2b75-c8142c3fbdb4@init7.net> Message-ID: I believe this isn't the actual process, however recent reorganization has brought with it a new tier of "entry level" order/service management that's not fully up to speed on things. You'll want to ask your account team for a dedicated project manager to help with the process. HTH, -a On Fri, Jun 10, 2016 at 12:02 PM, Fredy Kuenzler wrote: > On 10.06.2016 16:00, Mike Hammett wrote: >> Who has moved an Equinix IX port? We're told that it's a full >> cancellation, re-order, re IPs, re-peering, etc. >> >> Can anyone lend any input either way on that? > > Same issue here. Super complicated. I'm tempted to stop the process > after the first step. > > -- > Fredy Kuenzler > > --------------------- > Fiber7. No Limits. > https://www.fiber7.ch > --------------------- > > Init7 (Switzerland) Ltd. > AS13030 > St.-Georgen-Strasse 70 > CH-8400 Winterthur > Skype: flyingpotato > Phone: +41 44 315 4400 > Fax: +41 44 315 4401 > Twitter: @init7 / @kuenzler > http://www.init7.net/ From mark.tinka at seacom.mu Fri Jun 10 17:17:38 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jun 2016 19:17:38 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> Message-ID: On 10/Jun/16 19:08, Christopher Morrow wrote: > > > ?oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?? > With regard to reaching our network, not true. You would still be able to reach our network if your primary service with us failed, but not via a local peer. Mark. From nanog at ics-il.net Fri Jun 10 17:18:47 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 10 Jun 2016 12:18:47 -0500 (CDT) Subject: Equinix IX Port Moves In-Reply-To: References: <55225649.1488.1465566997437.JavaMail.mhammett@ThunderFuck> <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> Message-ID: <2013715251.1814.1465579127061.JavaMail.mhammett@ThunderFuck> The second option. Well, there is the first under process too, but the second is the priority at the moment. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "Mike Hammett" Cc: "NANOG" Sent: Friday, June 10, 2016 9:46:17 AM Subject: Re: Equinix IX Port Moves On Fri, Jun 10, 2016 at 10:00 AM, Mike Hammett < nanog at ics-il.net > wrote: Who has moved an Equinix IX port? We're told that it's a full cancellation, re-order, re IPs, re-peering, etc. Can anyone lend any input either way on that? there are 2 meanings (at least) to 'move', did you mean: 1) move port from 1G to 10G (or 'change speed') 2) move port from cage/rack1 to cage/rack2 (endpoint move in your space(s) )
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com
From hugo at slabnet.com Fri Jun 10 17:19:29 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 10 Jun 2016 10:19:29 -0700 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> Message-ID: <20160610171929.GJ6467@bamboo.slabnet.com> On Fri 2016-Jun-10 13:08:48 -0400, Christopher Morrow wrote: >On Fri, Jun 10, 2016 at 1:05 PM, Mark Tinka wrote: > >> >> >> On 10/Jun/16 16:47, Christopher Morrow wrote: >> >> >> >> so I can't be a customer of you and a network you peer with? >> >> >> You can, but we won't learn your paths via the peering session we would >> have with your other ISP. Wouldn't "learn but depref" be preferred and more common? E.g. customer routes get tagged with "customer route" community and local-pref'd to 150 or something; peer routes get tagged with "peer route" community and local pref'd somewhere below that. Else any of your other customers that are single-homed to you can't reach your dual-homed customer A in cases where customer A's link to you is down, but customer A has other transits with whom you peer? Unless it's mitigated by you accepting customer A's prefixes from any transits you have, which at the least seems sub-optimal (now reaching them via transit rather than peering if customer A's circuit is down) or possibly also up-ended if you also similarly apply "don't accept customer prefixes from transits". No? >> >> >oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From telmnstr at 757.org Fri Jun 10 17:22:49 2016 From: telmnstr at 757.org (Ethan) Date: Fri, 10 Jun 2016 13:22:49 -0400 (EDT) Subject: Equinix IX Port Moves In-Reply-To: <72b5e5c7-7bb7-167c-2b75-c8142c3fbdb4@init7.net> References: <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> <72b5e5c7-7bb7-167c-2b75-c8142c3fbdb4@init7.net> Message-ID: > Same issue here. Super complicated. I'm tempted to stop the process > after the first step. I think most things involving equinix are complicated and frustrating, at least once the contract is signed. From morrowc.lists at gmail.com Fri Jun 10 17:26:51 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jun 2016 13:26:51 -0400 Subject: Equinix IX Port Moves In-Reply-To: <2013715251.1814.1465579127061.JavaMail.mhammett@ThunderFuck> References: <55225649.1488.1465566997437.JavaMail.mhammett@ThunderFuck> <25954948.1506.1465567232141.JavaMail.mhammett@ThunderFuck> <2013715251.1814.1465579127061.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Jun 10, 2016 at 1:18 PM, Mike Hammett wrote: > The second option. > > Well, there is the first under process too, but the second is the priority > at the moment. > > > ?it's a little mystifying that they can't arrange a 'hot cut' of the link then between the 2 locations. They were able to do this for an org I don't work for but help out... for 2 links in a cage->cage move event just a little less than a year ago actually.? > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Friday, June 10, 2016 9:46:17 AM > Subject: Re: Equinix IX Port Moves > > > > > > > > On Fri, Jun 10, 2016 at 10:00 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > Who has moved an Equinix IX port? We're told that it's a full > cancellation, re-order, re IPs, re-peering, etc. > > Can anyone lend any input either way on that? > > > > > > > > there are 2 meanings (at least) to 'move', did you mean: > 1) move port from 1G to 10G (or 'change speed') > 2) move port from cage/rack1 to cage/rack2 (endpoint move in your space(s) > ) > > >
> > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > >
> > > From morrowc.lists at gmail.com Fri Jun 10 17:27:34 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jun 2016 13:27:34 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> Message-ID: On Fri, Jun 10, 2016 at 1:17 PM, Mark Tinka wrote: > > > On 10/Jun/16 19:08, Christopher Morrow wrote: > > > > ?oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?? > > > > With regard to reaching our network, not true. You would still be able to > reach our network if your primary service with us failed, but not via a > local peer. > > ?I'm clearly misunderstanding something. I suppose if it works for your customers it must be ok.? From bicknell at ufp.org Fri Jun 10 17:34:59 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2016 10:34:59 -0700 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160610085017.GF2524@Vurt.local> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> <20160610085017.GF2524@Vurt.local> Message-ID: <20160610173459.GA58206@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2016 at 10:50:17AM +0200, Job Snijders wrote: > You say 'often', but I don't recognise that design pattern from my own > experience. A weakness with the egress point (in context of route leak > prevention) is that if you are filtering there, its already too late. If > you are trying to prevent route leaks on egress, you have already > accepted the leaked routes somewhere, and those leaked routes are best > path somewhere in your network, which means you've lost. It does mean the provider creating the leak has already lost, but that doesn't mean it still isn't vital to protecting the larger internet. A good example of this is fire code. Most fire codes do not do much to prevent you from starting a fire in your own house/condo/apartment, but rather prevent it from spreading to your neighbors. For instance, if you filter Customer A to A's Prefix list on ingress, B to B's, C to C's, it may also be prudent to filter outbound to your peers based on A+B+C's prefix list. When the ingress filter to A fails (typo, bug, bad engineer), your own network is hosed by whatever junk A ingested, but at least you won't pass it on to peers and spoil the rest of the Internet. Basically both ingress and egress filtering have weaknesses, and in some cases doing both can provide some mitigation. It's the old adage "belt and suspenders". -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mark.tinka at seacom.mu Fri Jun 10 18:10:58 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jun 2016 20:10:58 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160610171929.GJ6467@bamboo.slabnet.com> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <97548cbd-2582-7d6d-8c4d-6c39d9d4576d@seacom.mu> <20160610171929.GJ6467@bamboo.slabnet.com> Message-ID: On 10/Jun/16 19:19, Hugo Slabbert wrote: > > > Unless it's mitigated by you accepting customer A's prefixes from any > transits you have, This. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From bzs at theworld.com Fri Jun 10 18:13:11 2016 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 10 Jun 2016 14:13:11 -0400 Subject: Netflix banning HE tunnels [really: IPv6 adoption] In-Reply-To: <1465528350.1518.383.camel@biplane.com.au> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: <22363.823.286067.29823@pcls8.std.com> This is sort of whacky. IPv4 was so successful, let's say post 1990, because it got people from nothing to internet or as some say Internet. IPv6 cannot duplicate that. So continuing to rely on this idea that "hey a coupla billion people went for IPv4, and even that was slow at first, so it's just a matter of time"...is...I'll be kind...unwise. This is no longer engineering. This is marketing. Hand the problem over to a professional marketing organization and go back to what you were trained to do. Give them your phone number and tell them to please call if they think you can help, maybe a product endorsement spot on prime-time TV or to consider some technical improvement. Hi! I'm Barry Shein! I helped invent the internet. But I am about to explain to you a NEW development, IPv6, which is going to improve your internet experience more than you may have thought possible! And stay tuned for a special secret offer we're including for the first 250 million adopters! -- -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 jfbeam at gmail.com Fri Jun 10 18:27:35 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jun 2016 14:27:35 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush wrote: >>> zero interoperability, and no viable migration paths, it's a Forklift >>> Upgrade(tm). >> >> You say that with such confidence! Doesn't make it true. > > https://archive.psg.com/120206.nanog-v4-life-extension.pdf > > randy, who works for the first isp to deploy ipv6 to customers Also, the Randy who closed the ngtrans working group "declar[ing] victory" yet having produced nothing. Dual stack is not a transition plan, and never has been. It's a key factor in why we have such a fractured adoption today. If you've been completely ignoring IPv6 for 20 years, then it is indeed a steep learning curve[*]. If you haven't been upgrading equipment, shame on you! Otherwise, you've ended up with "IPv6 Capable(TM)" completely by accident, but you still have to deploy IPv6. On the scale of a large service provider (or enterprise, for that matter), that's not a trivial process. While *I* could upgrade the tiny island of the multi-national corp I work for [10 people, 1 (linux) router, 36 public facing networks] overnight via a plan drawn on the back of cocktail napkin over a long lunch, doing that over the entire global network is not going to happen overnight; the other offices have much more involved infrastructure. I'd like to hear from the Comcast's, TWC's, and Uverse's just how many man-hours were involved in the planning, testing, training, deployment, and troubleshooting of their IPv6 "transition". (I have a ppt of the Uverse 6rd plan. I cannot imagine that mere document was produced in lass than a day, not counting the data behind all those slides.) [*] As I joked with a business partner recently as he had to learn "all this crap about IPv6" for his CCIE recert, "you're a DoD contractor. They've had an 'IPv6 Mandate' for decades. I still have the memo." That mandate is for "IPv6 Capable"; they don't have any actual v6 anywhere. From Jason_Bertoch at nwrdc.fsu.edu Fri Jun 10 14:27:09 2016 From: Jason_Bertoch at nwrdc.fsu.edu (Jason Bertoch) Date: Fri, 10 Jun 2016 14:27:09 +0000 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: Message-ID: <7b5e303dfe8a4f079152601dafad3727@NWR-EX-01.nwrdc.com> Zimbra Jason Bertoch -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Wednesday, June 8, 2016 9:06 PM To: nanog at nanog.org Subject: Webmail / IMAPS software for end-user clients in 2016 If you had to put up a public facing webmail interface for people to use, and maintain it for the foreseeable future (5-6 years), what would you use? Roundcube? https://roundcube.net/ Rainloop? http://www.rainloop.net/ Something else? Requirements: Needs to be open souce and GPL, BSD or Apache licensed Email storage will be accessed via IMAP/TLS1.2 Runs on a Debian based platform with apache2 or nginx Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" size screens with Chrome and Safari -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4825 bytes Desc: not available URL: From mark.tinka at seacom.mu Fri Jun 10 18:38:22 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jun 2016 20:38:22 +0200 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160610173459.GA58206@ussenterprise.ufp.org> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> <20160610085017.GF2524@Vurt.local> <20160610173459.GA58206@ussenterprise.ufp.org> Message-ID: <8c107cc1-c29d-037b-1873-2c7f9a00fc7d@seacom.mu> On 10/Jun/16 19:34, Leo Bicknell wrote: > It does mean the provider creating the leak has already lost, but > that doesn't mean it still isn't vital to protecting the larger > internet. A good example of this is fire code. Most fire codes > do not do much to prevent you from starting a fire in your own > house/condo/apartment, but rather prevent it from spreading to your > neighbors. I've found communities to be robust at filtering very effectively. I have heard of software issues that may cause filters to stop working, but I have not yet encountered any such issues myself that had nothing to do with a mis-configuration or lack of understanding about how policies are evaluated by the router. > > For instance, if you filter Customer A to A's Prefix list on ingress, > B to B's, C to C's, it may also be prudent to filter outbound to > your peers based on A+B+C's prefix list. When the ingress filter > to A fails (typo, bug, bad engineer), your own network is hosed by > whatever junk A ingested, but at least you won't pass it on to peers > and spoil the rest of the Internet. That does not scale, and was probably one of the primary reasons communities were developed. > > Basically both ingress and egress filtering have weaknesses, and > in some cases doing both can provide some mitigation. It's the old > adage "belt and suspenders". We've been operating purely community-based filtering on border and peering routers for years. I've never ran into an issue with the software that broke that. The folk I know who have suffered this either mis-configured their policies, did not understand BGP and did not get a good handle on how their router OS implements filtering and filter evaluation. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Fri Jun 10 18:54:35 2016 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2016 11:54:35 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: > Also, the Randy who closed the ngtrans working group "declar[ing] victory" > yet having produced nothing. in the ietf, that is a victory indeed! :) from slide 9, "430 transition mechanisms." the problem is they were and are a mess. so the iesg decided to stop the farce. of course, folk kept inventing new wonderful mechanisms, e.g. dual-stack lite, where you not only get NAT in the core but get to fork-lift all your cpe; a real win. but, underlying all this is that v6 and v4 were dead incompatible on the wire. and there was/is no magic. so all 'transition' mechanisms are by nature ugly, have scaling issues, sell a lot of expensive iron, ... and it's not like folk were not screaming in pain as the ietf went down this insanely arrogant and stupid path. > Dual stack is not a transition plan, and never has been. some of us shed a lot of blood trying to explain that to deering, hinden, and other worshipers. not very successfully. > It's a key factor in why we have such a fractured adoption today. this i do not buy. dual stack allowed some backbones to get v6 to the edge. this did not fragment adoption, it was just far from a scalable total solution. then again, nothing else is very pretty either. the tragedy is that there are now more folk using cgns than ipv6. the nat haters have created the worst nats in the world; justice, but not the kind of justice i like. > If you've been completely ignoring IPv6 for 20 years have not, though i suspect our bean counters wish we had. it's been a very expensive road. our first deployment was on a truly dual stack backbone, separate circuits and separate routers (netbsd boxes as v6 traffic was small) as j&c did not support dual stack, heck any stack. randy From josh at kyneticwifi.com Fri Jun 10 18:54:53 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 10 Jun 2016 13:54:53 -0500 Subject: Akamai GeoIP Message-ID: Can somebody from Akamai contact me offlist about a GeoIP location change for a block please? Thank you. From cryptographrix at gmail.com Fri Jun 10 18:58:44 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 10 Jun 2016 18:58:44 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: Just to clarify - there's no transition involved - IPv4 to IPv6 is like going from the VINES protocol to IPv6: IPv6 may as well have been called "PROTOCOL 493" - it bares very little relation to the original protocol that brought us the internet as-it-is-today. The deployment of IPv4 had nothing to do with other protocols and neither does IPv6 - EXCEPT for the fact that the use of the only (largely-available) "transition" method (SixXS and HE.net tunnels) is now coming face to face with media DRM, as media is taking over the internet. Sooo....WTF batman? On Fri, Jun 10, 2016 at 2:28 PM Ricky Beam wrote: > On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush wrote: > > >>> zero interoperability, and no viable migration paths, it's a Forklift > >>> Upgrade(tm). > >> > >> You say that with such confidence! Doesn't make it true. > > > > https://archive.psg.com/120206.nanog-v4-life-extension.pdf > > > > randy, who works for the first isp to deploy ipv6 to customers > > Also, the Randy who closed the ngtrans working group "declar[ing] victory" > yet having produced nothing. Dual stack is not a transition plan, and > never has been. It's a key factor in why we have such a fractured adoption > today. > > If you've been completely ignoring IPv6 for 20 years, then it is indeed a > steep learning curve[*]. If you haven't been upgrading equipment, shame on > you! Otherwise, you've ended up with "IPv6 Capable(TM)" completely by > accident, but you still have to deploy IPv6. On the scale of a large > service provider (or enterprise, for that matter), that's not a trivial > process. While *I* could upgrade the tiny island of the multi-national > corp I work for [10 people, 1 (linux) router, 36 public facing networks] > overnight via a plan drawn on the back of cocktail napkin over a long > lunch, doing that over the entire global network is not going to happen > overnight; the other offices have much more involved infrastructure. > > I'd like to hear from the Comcast's, TWC's, and Uverse's just how many > man-hours were involved in the planning, testing, training, deployment, > and troubleshooting of their IPv6 "transition". (I have a ppt of the > Uverse 6rd plan. I cannot imagine that mere document was produced in lass > than a day, not counting the data behind all those slides.) > > [*] As I joked with a business partner recently as he had to learn "all > this crap about IPv6" for his CCIE recert, "you're a DoD contractor. > They've had an 'IPv6 Mandate' for decades. I still have the memo." That > mandate is for "IPv6 Capable"; they don't have any actual v6 anywhere. > From cryptographrix at gmail.com Fri Jun 10 19:02:05 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Fri, 10 Jun 2016 19:02:05 +0000 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: (alternate solution: rename IPv6 to something media-friendlyish and request ISPs to enable support for it, advertising that most of their hardware "*already supports it*") On Fri, Jun 10, 2016 at 2:58 PM Cryptographrix wrote: > Just to clarify - there's no transition involved - IPv4 to IPv6 is like > going from the VINES protocol to IPv6: IPv6 may as well have been called > "PROTOCOL 493" - it bares very little relation to the original protocol > that brought us the internet as-it-is-today. > > The deployment of IPv4 had nothing to do with other protocols and neither > does IPv6 - EXCEPT for the fact that the use of the only > (largely-available) "transition" method (SixXS and HE.net tunnels) is now > coming face to face with media DRM, as media is taking over the internet. > > Sooo....WTF batman? > > > On Fri, Jun 10, 2016 at 2:28 PM Ricky Beam wrote: > >> On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush wrote: >> >> >>> zero interoperability, and no viable migration paths, it's a Forklift >> >>> Upgrade(tm). >> >> >> >> You say that with such confidence! Doesn't make it true. >> > >> > https://archive.psg.com/120206.nanog-v4-life-extension.pdf >> > >> > randy, who works for the first isp to deploy ipv6 to customers >> >> Also, the Randy who closed the ngtrans working group "declar[ing] victory" >> yet having produced nothing. Dual stack is not a transition plan, and >> never has been. It's a key factor in why we have such a fractured adoption >> today. >> >> If you've been completely ignoring IPv6 for 20 years, then it is indeed a >> steep learning curve[*]. If you haven't been upgrading equipment, shame on >> you! Otherwise, you've ended up with "IPv6 Capable(TM)" completely by >> accident, but you still have to deploy IPv6. On the scale of a large >> service provider (or enterprise, for that matter), that's not a trivial >> process. While *I* could upgrade the tiny island of the multi-national >> corp I work for [10 people, 1 (linux) router, 36 public facing networks] >> overnight via a plan drawn on the back of cocktail napkin over a long >> lunch, doing that over the entire global network is not going to happen >> overnight; the other offices have much more involved infrastructure. >> >> I'd like to hear from the Comcast's, TWC's, and Uverse's just how many >> man-hours were involved in the planning, testing, training, deployment, >> and troubleshooting of their IPv6 "transition". (I have a ppt of the >> Uverse 6rd plan. I cannot imagine that mere document was produced in lass >> than a day, not counting the data behind all those slides.) >> >> [*] As I joked with a business partner recently as he had to learn "all >> this crap about IPv6" for his CCIE recert, "you're a DoD contractor. >> They've had an 'IPv6 Mandate' for decades. I still have the memo." That >> mandate is for "IPv6 Capable"; they don't have any actual v6 anywhere. >> > From jeffm at iglou.com Fri Jun 10 19:14:41 2016 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 10 Jun 2016 15:14:41 -0400 (EDT) Subject: Maybe Telia issues? Message-ID: <33257.64.6.220.221.1465586081.iglou@webmail.iglou.com> Not quite sure whether this should go to outages, or here. I'm not confident that there actually *is* an outage of any sort...having a tough time characterizing it. I have an IPSec tunnel between 64.6.220.219 (upstreams Sprint, AT&T, and LeveL3/legacy TWTelecom) and 64.199.98.162 (upstream Windstream). Egress from 64.6.220.219 was going through Sprint until I turned that session down. traceroute to 64.199.98.162 (64.199.98.162), 30 hops max, 60 byte packets 1 1a-1-vlan11.int.appriss.com (10.10.35.1) 0.995 ms 0.965 ms 0.947 ms 2 lsces03-e-1-13.office.appriss.com (10.9.3.45) 0.283 ms 0.344 ms 0.421 ms 3 lscorpfw01a-ge2-0-0-0.int.appriss.com (64.6.219.41) 0.275 ms 0.299 ms 0.272 ms 4 clinetedge01-ge-0-3-0-0.appriss.net (64.6.221.157) 0.731 ms 0.762 ms 0.752 ms 5 sl-gw10-nsh-0-1-0-0-si204.sprintlink.net (144.228.97.29) 45.753 ms 45.782 ms 45.772 ms 6 144.232.11.73 (144.232.11.73) 44.496 ms 44.321 ms 44.296 ms 7 144.232.5.212 (144.232.5.212) 46.955 ms 45.695 ms 46.958 ms 8 144.232.2.225 (144.232.2.225) 42.132 ms 144.232.15.111 (144.232.15.111) 41.922 ms 144.232.10.218 (144.232.10.218) 41.928 ms 9 atl-bb1-link.telia.net (62.115.49.157) 42.872 ms 42.863 ms 42.955 ms 10 * * * 11 * * * traceroute from the 64.199.98.162 side back towards 64.6.220.219: Type escape sequence to abort. Tracing the route to 64.6.220.219 ?1? 64.199.98.161 0 msec 10 msec 0 msec ?2? 205.147.221.153 0 msec 10 msec 0 msec ?3? 40.128.249.156 10 msec 0 msec 0 msec ?4? 40.136.117.74 0 msec 0 msec 10 msec ?5? 40.128.10.138 10 msec 20 msec ? ? 40.128.248.62 10 msec ?6? 40.128.10.150 10 msec ? ? 40.128.10.146 10 msec ? ? 40.128.10.150 10 msec ?7? 80.239.194.41 20 msec 10 msec 10 msec ?8? 213.248.87.254 10 msec 10 msec 30 msec ?9? 12.122.133.34 20 msec 20 msec 20 msec ?10 12.122.152.137 20 msec 20 msec 20 msec ?11 12.122.152.209 50 msec 20 msec 20 msec ?12 12.118.107.122 40 msec 40 msec 40 msec ?13 170.75.217.4 50 msec 40 msec 50 msec ?14? *? *? *? ?15? *? *? * ? (the 170.75.217.4 is my edge facing AT&T) When I shut down my BGP session to Sprint, my traffic shifted to AT&T and the tunnel came up. Anyone else seeing any issues around this area (I know, pretty vague), seemingly specifically related to interconnections between Sprint, Telia, and Windstream? I know Telia experienced some issues yesterday that were apparently resolved, maybe some lingering issues resulting from that? Shot in the dark, here. -- Jeff From randy at psg.com Fri Jun 10 19:34:55 2016 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2016 12:34:55 -0700 Subject: intra-AS messaging for route leak prevention In-Reply-To: References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> Message-ID: >> One thing we do to reduce opportunistically hazardous vectors is to not >> learn customer paths via peers. > ?so I can't be a customer of you and a network you peer with? > (I'm sure I got your meaning wrong)? sure you can. just don't expect packets from job's cone when your link to him is down. didn't we go through all these lessons a couple of decades ago? From Curtis.Starnes at granburyisd.org Fri Jun 10 19:39:38 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Fri, 10 Jun 2016 19:39:38 +0000 Subject: Enough about Netflix banning HE tunnels [really: IPv6 adoption] Message-ID: NANOG members; First things first - PLEASE NOTE: This is just an opinion from one old IT guy who used to have to use a dial-up connection from a small town in central Texas to connect to my "ISP" (term used loosely for the very early 1990's) in Dallas, Oklahoma City, and sometimes Shreveport, LA with my trusty Slackware box (with its screaming i386 processor/2MB RAM and 900 BAUD modem) just to get my FidoNet/UUCP email fix (just for those of us who remember the old "bang path" email via UUCP!) via UUNet. This passion grew into running multi-node Wildcat! BBS systems in early 1992 to small ISP's in the mid-1990's until which time my Southwestern Bell phone bills and customer churn killed this hobby quick and I had to turn to a full time IT professional to feed the family. As the Internet continues to grow exponentially with the explosion of the IoT movement, let's see how every one's IPv4 boxes connect to an IPv6 only network (or their refrigerator) without the support of the IT community such as NANOG members to mangle the packets and push their packets through some sort of IPv4 to IPv6 transitional technology. This thread is really getting on my nerves and old eyes as it fills my mailbox daily and I am sure I am not the only one. Between the content providers that are complaining about there is not enough IPv6 traffic to justify the migration, vendors pushing products that do not support IPv6, to the carriers that do not support dual stack to the last mile customer, then the end-user that you hear saying "IPvWhaaaat?" on the end of the phone; it is up to us, the network engineers, network administrators, "Packet Pushers", and whatever title is bestowed upon us, to just make it work. That is what I hear day in and day out; "The sales team said it could be done so what is the problem? Get if fixed or we will find someone who can!" and I am in the public education space! I feel for the network engineers, NOC operators, and cable/fiber teams of our great nation. Just as an FYI: I remember when IPv4 was a "Fad" and took patience of Job (the biblical Job, not job) just to get the Win32's loaded on Windows 3.1 so it would handle a 32-bit address. This is not including the mastery of the AT commands that Trumpet Winsock required since each manufacturer put their own spin in their interpretation of what AT command should do what (I still can remember what "squeals and tones" were negotiating at what speed and the occasional nightmare that ATZ & AT&E1 just sit there with a blank terminal and silent modem). Netflix can ban and block all they want. Carriers can complain "Streaming media is using too much bandwidth", never mind that each and every one pays for transit bandwidth, even public schools! We must remember our technology history; - Ma Bell said that they were too big to be broken up - IBM would always be king - Unix such as System V/BSD/Open Systems/AIX/SCO/HP-UX/Sun Solaris would each rule the world. - and my personal favorite - "No one would want to own a personal PC!" Bottom line, whether we keep pushing onward with what we have, IPv4 and IPv6 or we adopt another protocol to replace the archaic IPv4. The Layer 1-7 technologies which we all work with daily, were never designed with security as the primary concern when RFC 675 was created in 1974 by the Network Working Group with Vince Cerf and others. I do not think Vince Cerf and the other members of the Network Working Group had Cryptolocker, Ransomware, on his mind when TCP/IP was "born" from this RFC. We must keep pressing onward and pushing the envelope of our segment of the modern and some not so modern Internet. Where would we be without the Vince Cerf's, Steve Job's, Bill Gates', Paul Allen's, DARPA, US Military, the fiber tech's that run, fuse, and terminate miles of fiber while others sleep, the network techs, net admins, programmers, and too many others to mention. Where would and would there be IPv4, IPv6, or an Internet at all. Whether we are doing this as our jobs or as a hobby, driven out of passion for technology. We owe the next generation(s) the benefit of our best work so that they have to opportunity to do their best as well. Thank you NANOG community for the platform for me to express this rant/reflections; and the freedoms our country provides so I can do so freely. Curtis Starnes Senior Network Administrator Granbury Independent School District Granbury, Texas IEEE Member since 2012 (Just for the record, these are my opinions and ramblings/rants, not my employers) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of bzs at theworld.com Sent: Friday, June 10, 2016 1:13 PM To: Karl Auer Cc: nanog at nanog.org Subject: Re: Netflix banning HE tunnels [really: IPv6 adoption] This is sort of whacky. IPv4 was so successful, let's say post 1990, because it got people from nothing to internet or as some say Internet. IPv6 cannot duplicate that. So continuing to rely on this idea that "hey a coupla billion people went for IPv4, and even that was slow at first, so it's just a matter of time"...is...I'll be kind...unwise. This is no longer engineering. This is marketing. Hand the problem over to a professional marketing organization and go back to what you were trained to do. Give them your phone number and tell them to please call if they think you can help, maybe a product endorsement spot on prime-time TV or to consider some technical improvement. Hi! I'm Barry Shein! I helped invent the internet. But I am about to explain to you a NEW development, IPv6, which is going to improve your internet experience more than you may have thought possible! And stay tuned for a special secret offer we're including for the first 250 million adopters! -- -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 Valdis.Kletnieks at vt.edu Fri Jun 10 19:55:28 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2016 15:55:28 -0400 Subject: Enough about Netflix banning HE tunnels [really: IPv6 adoption] In-Reply-To: References: Message-ID: <208362.1465588528@turing-police.cc.vt.edu> On Fri, 10 Jun 2016 19:39:38 -0000, "STARNES, CURTIS" said: > - Unix such as System V/BSD/Open Systems/AIX/SCO/HP-UX/Sun Solaris would each > rule the world. Compare the number of Android devices (basically every single smartphone on the planet that doesn't say iPhone) to the number of laptops and PCs. Factor in the explosion of Chromebooks... And they're all Linux under the hood. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Curtis.Starnes at granburyisd.org Fri Jun 10 20:12:43 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Fri, 10 Jun 2016 20:12:43 +0000 Subject: Enough about Netflix banning HE tunnels [really: IPv6 adoption] In-Reply-To: <208362.1465588528@turing-police.cc.vt.edu> References: <208362.1465588528@turing-police.cc.vt.edu> Message-ID: Just as an example in the K-12 education space; we have added 5000 Chromebooks in the last 12 months. This was an end point add, not a replacement for desktops or other devices. And each Chromebook has to be filtered for Internet content to meet CIPA requirements (and the Chromebook content filtering is not IPv6 compatible either, chalk 5000 more devices to the dynamic NAT pool). -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, June 10, 2016 2:55 PM To: STARNES, CURTIS Cc: nanog at nanog.org; bzs at TheWorld.com Subject: Re: Enough about Netflix banning HE tunnels [really: IPv6 adoption] On Fri, 10 Jun 2016 19:39:38 -0000, "STARNES, CURTIS" said: > - Unix such as System V/BSD/Open Systems/AIX/SCO/HP-UX/Sun Solaris > would each rule the world. Compare the number of Android devices (basically every single smartphone on the planet that doesn't say iPhone) to the number of laptops and PCs. Factor in the explosion of Chromebooks... And they're all Linux under the hood. From Valdis.Kletnieks at vt.edu Fri Jun 10 20:21:43 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2016 16:21:43 -0400 Subject: Enough about Netflix banning HE tunnels [really: IPv6 adoption] In-Reply-To: References: <208362.1465588528@turing-police.cc.vt.edu> Message-ID: <210561.1465590103@turing-police.cc.vt.edu> On Fri, 10 Jun 2016 20:12:43 -0000, "STARNES, CURTIS" said: > and the Chromebook content filtering is not IPv6 compatible either So what are you using for content filtering? A quick google search indicates that there do exist filtering solutions that are IPv6 capable? And what *non* Chromebook solution are you using that's IPv6 capable on the *other* boxes? (Which still doesn't change the fact that you just purchased 5K units of something that runs Linux under the hood). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Jun 10 20:22:21 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2016 16:22:21 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: <210614.1465590141@turing-police.cc.vt.edu> On Sat, 11 Jun 2016 00:21:52 +0900, Masataka Ohta said: > As such, the fish passages can be constructed, if translation > behavior of the NAT boxes are known to end systems so that > the end systems have sufficient knowledge to reverse the > translation. This requires each end system to restrict its use of ephemeral ports to a specified *different* subrange per system, because the number of end systems times their ephemeral port range can't exceed the number of front-end systems times their ephemeral port range. You just lost the only thing that makes CGNAT work - time multiplexing a given external IP/port pair across several sequential users. Also, there's no existing mechanism for "if translation behavior of the NAT boxes are known to end systems". So you're looking at end systems having to change software *anyhow*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From hannigan at gmail.com Fri Jun 10 20:52:13 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 10 Jun 2016 16:52:13 -0400 Subject: Akamai GeoIP In-Reply-To: References: Message-ID: On Fri, Jun 10, 2016 at 2:54 PM, Josh Reynolds wrote: > Can somebody from Akamai contact me offlist about a GeoIP location > change for a block please? > > Thank you. You can always mail nocc at akamai.com or peering at akamai.com for this type of request and we'll help get it to the right place. I'll go ahead and reach out to you from my work address to get it started. Best Regards, -M< / AS 20940 / AS 32787 From mpetach at netflight.com Fri Jun 10 21:53:04 2016 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 10 Jun 2016 14:53:04 -0700 Subject: Fwd: Sunday night social? In-Reply-To: References: Message-ID: > I just finished registering for NANOG 67, and answered Yes to "Will you be attending the sunday evening social" and booked my flight accordingly...but now i can't seem to find any details on what time it starts on the website. Does anyone know what time it starts? > > Thanks! > > Matt > > From surfer at mauigateway.com Fri Jun 10 21:54:45 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 10 Jun 2016 14:54:45 -0700 Subject: Netflix banning HE tunnels Message-ID: <20160610145445.381FD9DF@m0087794.ppops.net> --- chuckchurch at gmail.com wrote: From: "Chuck Church" The true jerks who used HE to bypass geo-lockout probably changed to something else the next day. But we suffer still. The FCC or some other federal entity probably needs to step in. ------------------------------------------ Yeah, because the US federal government does such a great job fixing problems like this... scott From vwittkop at nanog.org Fri Jun 10 22:14:16 2016 From: vwittkop at nanog.org (Valerie Wittkop) Date: Fri, 10 Jun 2016 18:14:16 -0400 Subject: Sunday night social? In-Reply-To: References: Message-ID: Hi Matt - The registration questions built into Cvent are a standard set which is created prior to confirmation of sponsored events. The questions are there as a means to allow potential sponsors to plan accordingly. There is not a Sunday Social taking place in Chicago. Apologies if the standard questions in the registration process caused confusion. You can always check the true schedule of events by visiting the event agenda. Cheers, Valerie On Fri, Jun 10, 2016 at 5:53 PM, Matthew Petach wrote: > > I just finished registering for NANOG 67, and answered Yes to "Will you > be attending the sunday evening social" and booked my flight > accordingly...but now i can't seem to find any details on what time it > starts on the website. Does anyone know what time it starts? > > > > Thanks! > > > > Matt > > > > > -- Valerie Wittkop NANOG Program Director +1.866.902.1336, Ext. 103 From mohta at necom830.hpcl.titech.ac.jp Sat Jun 11 00:33:40 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 11 Jun 2016 09:33:40 +0900 Subject: Netflix banning HE tunnels In-Reply-To: <210614.1465590141@turing-police.cc.vt.edu> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> <210614.1465590141@turing-police.cc.vt.edu> Message-ID: Valdis.Kletnieks at vt.edu wrote: > This requires each end system to restrict its use of ephemeral ports > to a specified *different* subrange per system, because the number of > end systems times their ephemeral port range can't exceed the number of > front-end systems times their ephemeral port range. Yes, and the resulting 48 bit address space should be large enough. Moreover, reverse NAT with dynamic port allocation is possible. Though, like dynamic address allocation, it is not very useful for servers, clients are fine. > You just lost the > only thing that makes CGNAT work - time multiplexing a given external > IP/port pair across several sequential users. That is an argument against static NAT with 32 bit address space without port translation/sharing. > Also, there's no existing mechanism for "if translation behavior of > the NAT boxes are known to end systems". UPnP offers such mechanisms though that of v1 is not very efficient. > So you're looking at > end systems having to change software *anyhow*. Or live with conventional NAT, which is the current reality. The point is that migration can be done smoothly only by upgrading one end and that, after the upgrade, unupdated systems can continue to live with conventional NAT. Masataka Ohta From marka at isc.org Sat Jun 11 00:46:36 2016 From: marka at isc.org (Mark Andrews) Date: Sat, 11 Jun 2016 10:46:36 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Fri, 10 Jun 2016 11:54:35 -0700." References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: <20160611004636.D46DC4B222C0@rock.dv.isc.org> In message , Randy Bush writes: > > Also, the Randy who closed the ngtrans working group "declar[ing] victory" > > > yet having produced nothing. > > in the ietf, that is a victory indeed! :) from slide 9, "430 transition > mechanisms." the problem is they were and are a mess. so the iesg > decided to stop the farce. of course, folk kept inventing new wonderful > mechanisms, e.g. dual-stack lite, where you not only get NAT in the core > but get to fork-lift all your cpe; a real win. Dual-stack lite never required a forklift upgrade. Deployment on replacement was all that was ever needed for that. It is a end stage transition technology. If you want to rush the transition and go to IPv6 only then you need to push it out fast but a choice you make as a ISP. > but, underlying all this is that v6 and v4 were dead incompatible on the > wire. and there was/is no magic. so all 'transition' mechanisms are by > nature ugly, have scaling issues, sell a lot of expensive iron, ... > > and it's not like folk were not screaming in pain as the ietf went down > this insanely arrogant and stupid path. > > > Dual stack is not a transition plan, and never has been. > > some of us shed a lot of blood trying to explain that to deering, > hinden, and other worshipers. not very successfully. But it actually worked when people let it work. Lots of vendors delivered their piece of the strategy back in the late 1999s and early 2000s. Think Windows XP. Yes, by delivering XP with IPv6 support (yes you had to enable it) allowed every product that ran on a Windows box to talk over IPv6 when it was upgraded. We started delivering IPv6 capable products in the late 1990s. Today most equipement is IPv6 capable and the equipement will use IPv6 if there is a IPv6 path. How many of use actually are using 20 year old hardware with IPv4 only stacks on it. How many of you are using IPv4 only applications. Software and hardware get replaced on a pretty regular basis. I know almost all of the applications I use support IPv6. There is very little that is IPv4 only except in computer museums. When you turn on IPv6 to a household +60% of the traffic is IPv6. It would be close to a 100% if more content providers would turn on IPv6. It's not like the webservers they use are incapable of delivering content over IPv6. What you should be doing is complaining to the people still selling obsolete IPv4 only garbage. Could it have been done better, sure. We could have lobbied for governments to ban the selling of new IPv4 only equipement (except with special dispensation). That strategy worked for the imperial to metric transition in Australia. You could not buy new imperial only equipement down to rulers at the local newsagencies. > > It's a key factor in why we have such a fractured adoption today. > > this i do not buy. dual stack allowed some backbones to get v6 to the > edge. this did not fragment adoption, it was just far from a scalable > total solution. then again, nothing else is very pretty either. the > tragedy is that there are now more folk using cgns than ipv6. the nat > haters have created the worst nats in the world; justice, but not the > kind of justice i like. > > > If you've been completely ignoring IPv6 for 20 years > > have not, though i suspect our bean counters wish we had. it's been a > very expensive road. our first deployment was on a truly dual stack > backbone, separate circuits and separate routers (netbsd boxes as v6 > traffic was small) as j&c did not support dual stack, heck any stack. > > randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chuckchurch at gmail.com Sat Jun 11 01:25:36 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Fri, 10 Jun 2016 21:25:36 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <20160610145445.381FD9DF@m0087794.ppops.net> References: <20160610145445.381FD9DF@m0087794.ppops.net> Message-ID: <021b01d1c380$29d218c0$7d764a40$@gmail.com> Well, they have to power to push out net neutrality. This intentional blocking of tunneling customers because their crap method of geo-location can't be used and thus hinders advancement of the internet (IPv6) is something that should disallowed. Or a good candidate for class action suit. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Friday, June 10, 2016 5:55 PM To: nanog at nanog.org Subject: RE: Netflix banning HE tunnels --- chuckchurch at gmail.com wrote: From: "Chuck Church" The true jerks who used HE to bypass geo-lockout probably changed to something else the next day. But we suffer still. The FCC or some other federal entity probably needs to step in. ------------------------------------------ Yeah, because the US federal government does such a great job fixing problems like this... scott From randy at psg.com Sat Jun 11 01:48:42 2016 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2016 18:48:42 -0700 Subject: Netflix banning HE tunnels In-Reply-To: <021b01d1c380$29d218c0$7d764a40$@gmail.com> References: <20160610145445.381FD9DF@m0087794.ppops.net> <021b01d1c380$29d218c0$7d764a40$@gmail.com> Message-ID: > Well, they have to power to push out net neutrality. This intentional > blocking of tunneling customers because their crap method of > geo-location can't be used and thus hinders advancement of the > internet (IPv6) is something that should disallowed. you omitted the "in my opinion." the facts are that o netflix is under serious pressure from media, from whom they have i lot of legal pain, to restrict distribution geographically. you may want to take this up with the media folk. o tunnels, including HE's, prevent neflix from geolocating the user. o the HE v6 tunnels are a hack which, while it helps many folk get almost-ipv6, is still a hack and has many undiserable consequences. this is only one. for many folk, the benefits are worth the consequences. this does not make the sow's ear into a silk purse. o screaming at netflix may be cathartic, but it ain't gonna get you or anyone else anywhere. but i guess nanog needs the message traffic. randy From feld at feld.me Sat Jun 11 15:04:04 2016 From: feld at feld.me (Mark Felder) Date: Sat, 11 Jun 2016 10:04:04 -0500 Subject: Netflix banning HE tunnels In-Reply-To: References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> Message-ID: <98969E18-B4DD-4931-9801-89A38A0BD2AA@feld.me> > On Jun 8, 2016, at 10:37, Spencer Ryan wrote: > > It identifys where you told it you are. It doesn't tell Netflix that your > v4 endpoint is in New Zeland and you are watching a bunch of content you > are not supposed to have access to. > > Is this really that hard to understand? > But I can buy my own address space and lie about where it's located at ... ? -- Mark Felder feld at feld.me From suba.h17 at gmail.com Sat Jun 11 05:22:31 2016 From: suba.h17 at gmail.com (subashini hariharan) Date: Fri, 10 Jun 2016 22:22:31 -0700 Subject: Detecting Attacks Message-ID: Hello, I am Subashini, a graduate student. I am interested in doing my project in Network Security. I have a doubt related to it. The aim is to detect DoS/DDoS attacks using the application. I am going to use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log Analytics). My doubt is regarding how do we generate logs for detecting this attack? As I am new to this process, I am not sure about it. Also, if it is possible to do any other attacks similar to this, you can please give a hint about it. Could anyone please help with this, it would be a great help!! -- Thank You. With Regards, H.Subashini From suba.h17 at gmail.com Sat Jun 11 05:39:08 2016 From: suba.h17 at gmail.com (subashini hariharan) Date: Fri, 10 Jun 2016 22:39:08 -0700 Subject: Detecting Attacks Message-ID: Hello, I am Subashini, a graduate student. I am interested in doing my project in Network Security. I have a doubt related to it. The aim is to detect DoS/DDoS attacks using the application. I am going to use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log Analytics). My doubt is regarding how do we generate logs for detecting this attack? As I am new to this process, I am not sure about it. Also, if it is possible to do any other attacks similar to this, you can please give a hint about it. Could anyone please help with this, it would be a great help!! -- Thank You. With Regards, H.Subashini From ops.lists at gmail.com Sat Jun 11 17:42:29 2016 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 11 Jun 2016 23:12:29 +0530 Subject: Detecting Attacks In-Reply-To: References: Message-ID: Is your aim to generate attack traffic? Or rather a mix of normal and attack traffic. That's one part. Googling ddos simulator will get you lots of results you can evaluate Logging it appropriately and capturing the logs, storing them in a db is the next. --srs > On 11-Jun-2016, at 10:52 AM, subashini hariharan wrote: > > Hello, > > I am Subashini, a graduate student. I am interested in doing my project in > Network Security. I have a doubt related to it. > > The aim is to detect DoS/DDoS attacks using the application. I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). > > My doubt is regarding how do we generate logs for detecting this attack? As > I am new to this process, I am not sure about it. > > Also, if it is possible to do any other attacks similar to this, you can > please give a hint about it. > > Could anyone please help with this, it would be a great help!! > > > -- > Thank You. > > With Regards, > H.Subashini From nanogml at Mail.DDoS-Mitigator.net Sat Jun 11 18:40:26 2016 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Sat, 11 Jun 2016 11:40:26 -0700 Subject: Detecting Attacks Message-ID: <20160611184026.GA16161@Mail.DDoS-Mitigator.net> hi su.. On 06/10/16 at 10:39pm, subashini hariharan wrote: > I am Subashini, a graduate student. I am interested in doing my project in > Network Security. I have a doubt related to it. duh... too broad of a subject ... you'd need to be more specific about which of the hundred's of sub categories ... > The aim is to detect DoS/DDoS attacks using the application. good ... sorta specific but not ... > I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). hummm, why that app and not the couple dozen other ways people are using to detect incoming and/or outgoing DDoS attacks if the "professor" says "use ELK" ... you have no ther choice ... if not, there's much better options to detect DDoS attacks ... ( tcpdump -nnvv ) ... if you cannot explain each line, you've got a DDoS problem > My doubt is regarding how do we generate logs for detecting this attack? As > I am new to this process, I am not sure about it. what's the doubt ?? if there is a doubt ... conduct and experiment and see if it confirms your expected result or explain why its different and do more experiments until "its all explained" and no more doubts > Also, if it is possible to do any other attacks similar to this, you can > please give a hint about it. several dozens other types of attacks similar to DDoS, which takes over a server or network offline including no-technical-skill required attacks > Could anyone please help with this, it would be a great help!! google/yahoo/bing is your assistant ready to give you ALL the answer's you need and ant ----------- side notes ... a) if you log all incoming packets ( attacks ), you have increased the effectiveness of ddos attacks since you have now gave them the power to fill up your disk, use your cpu, use your memory, use your time to review the logs, etc, etc all of that is bad bad stuff to have the DDoS attackers do to you b) for logs, etc, there are dozens of other apps that try to detect attacks ( splunk, snort, hundred other apps, including eyeballs ) why are some methodologies better than others ? c) detecting DDoS attacks is nice but, what's the point ?? you're still under attack ... and haven't resolved the issue kinda like cooking dinner but not eating it ... you're still starving d) every computer connected to the internet is under constant 24x7x365 attacks ... a good "ddos detector" will tell you how much traffic is legitimate and how much bandwidth is wasted by the attacks and which server and which ports they are attacking, etc etc script kiddies are already attacking your network ( the one you're using bnow ) .. it's a free and harmless DDoS attacks and you should be able to see what they are doing to you "now" if you cannot "see what" they are attacking, you've got a major problem e) if you want to generate some specific DDoS attacks .. use ping, nping, hping, nmap, etc to start .... that should keep you busy for the next year or few years do NOT ever send packets outside to computers you do not own, or some ominous looking folks might come looking for you f) if you want to detect DDoS attacks .... post process tcpdump's output magic pixie dust alvin # # DDoS-Simulator.net # DDoS-Mitigator.net # From omonnig at gmail.com Sat Jun 11 22:01:35 2016 From: omonnig at gmail.com (Otto Monnig) Date: Sat, 11 Jun 2016 17:01:35 -0500 Subject: Detecting Attacks In-Reply-To: References: Message-ID: <04E1D9D3-D73A-4A1C-943D-1E744F0FE49D@gmail.com> Security Onion is a FOSS Linux distribution with several great security tools integrated into an installer. https://security-onion-solutions.github.io/security-onion/ Snort & Suricata are signature based detection tools. Bro is a domain specific language for packet analysis and processing. https://isc.sans.edu/forums/diary/Why+I+think+you+should+try+Bro/15259/ -- Otto Monnig > On Jun 11, 2016, at 12:22 AM, subashini hariharan wrote: > > Hello, > > I am Subashini, a graduate student. I am interested in doing my project in > Network Security. I have a doubt related to it. > > The aim is to detect DoS/DDoS attacks using the application. I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). > > My doubt is regarding how do we generate logs for detecting this attack? As > I am new to this process, I am not sure about it. > > Also, if it is possible to do any other attacks similar to this, you can > please give a hint about it. > > Could anyone please help with this, it would be a great help!! > > > -- > Thank You. > > With Regards, > H.Subashini From baldur.norddahl at gmail.com Sat Jun 11 22:42:05 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 12 Jun 2016 00:42:05 +0200 Subject: Netflix banning HE tunnels In-Reply-To: <98969E18-B4DD-4931-9801-89A38A0BD2AA@feld.me> References: <26BC93E7-75F9-49F3-8A22-408CEF5867A2@delong.com> <20160608153031.GA2257@cmadams.net> <20160608113344.388ef965@jpeach-desktop.anbg.mssm.edu> <98969E18-B4DD-4931-9801-89A38A0BD2AA@feld.me> Message-ID: On 11 June 2016 at 17:04, Mark Felder wrote: > But I can buy my own address space and lie about where it's located at ... > ? > > They have that one covered. They are not going to believe what you enter there either... In fact getting the Geo IP people to accept that address space moved takes a year and even then you will have two more years before everyone updated their copy of the database. All the while your users are calling your hotline complaining about websites in the wrong language and blocked content. Regards, Baldur From nanog-post at rsuc.gweep.net Sun Jun 12 05:45:51 2016 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 12 Jun 2016 01:45:51 -0400 Subject: intra-AS messaging for route leak prevention In-Reply-To: <20160610085017.GF2524@Vurt.local> References: <20160606155418.GD35417@22.rev.meerval.net> <4cd6ac15-add6-b1cf-e538-bf65202f6937@seacom.mu> <20160608124811.GA75603@gweep.net> <20160610085017.GF2524@Vurt.local> Message-ID: <20160612054551.GA27191@gweep.net> On Fri, Jun 10, 2016 at 10:50:17AM +0200, Job Snijders wrote: > Hi All, > > On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote: [snip] > > It is useful to note that AS_PATH if often also involved on egress > > decisions. > > You say 'often', but I don't recognise that design pattern from my own > experience. A weakness with the egress point (in context of route leak > prevention) [snip] I wrote 'egress decisions'. While Leo pointed out some additional value, simple things like preventing private ASNs leaking (you mustn't trust the vendor knob) fall in this bucket. The list of potential things can be longer, but that's either microphone or bar conversation this coming week. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From Valdis.Kletnieks at vt.edu Sun Jun 12 16:04:12 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 12 Jun 2016 12:04:12 -0400 Subject: Detecting Attacks In-Reply-To: References: Message-ID: <129609.1465747452@turing-police.cc.vt.edu> On Fri, 10 Jun 2016 22:22:31 -0700, subashini hariharan said: > The aim is to detect DoS/DDoS attacks using the application. I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). Bad approach. At that point, not only is the application being DDoS'ed, but now your logging system may be overwhelmed as well. And a favorite attack method is to throw a DDoS at one application (your http server, for instance), and while you're drowning in logfiles, slip in an exploit for something else (you *did* patch that tftpd server, right?) Also, the vast majority of DDoS attempts are just fill-the-pipe attacks, which often don't even bother attacking an application, just an IP address. This leverages the fact that there's a lot of routers that can switch average sized packets at line speed, but not minimum sized packets. So the link falls over faster if it's getting pounded with ICMP Echo Request packets or TCP SYN packets than if it's getting 800-byte http requests. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Colin_Weir at cable.comcast.com Sun Jun 12 17:21:52 2016 From: Colin_Weir at cable.comcast.com (Weir, Colin) Date: Sun, 12 Jun 2016 17:21:52 +0000 Subject: Sunday night social? In-Reply-To: References: , Message-ID: Is Wednesday night the only social? -- Colin Weir Engineer, Quality of Experience, Comcast Cable Desk: 215-286-5406 Cell: 215-279-1733 ________________________________________ From: NANOG on behalf of Valerie Wittkop Sent: Friday, June 10, 2016 6:14:16 PM To: Matthew Petach Cc: nanog at nanog.org Subject: Re: Sunday night social? Hi Matt - The registration questions built into Cvent are a standard set which is created prior to confirmation of sponsored events. The questions are there as a means to allow potential sponsors to plan accordingly. There is not a Sunday Social taking place in Chicago. Apologies if the standard questions in the registration process caused confusion. You can always check the true schedule of events by visiting the event agenda. Cheers, Valerie On Fri, Jun 10, 2016 at 5:53 PM, Matthew Petach wrote: > > I just finished registering for NANOG 67, and answered Yes to "Will you > be attending the sunday evening social" and booked my flight > accordingly...but now i can't seem to find any details on what time it > starts on the website. Does anyone know what time it starts? > > > > Thanks! > > > > Matt > > > > > -- Valerie Wittkop NANOG Program Director +1.866.902.1336, Ext. 103 From dave at temk.in Sun Jun 12 17:47:09 2016 From: dave at temk.in (Dave Temkin) Date: Sun, 12 Jun 2016 17:47:09 +0000 (UTC) Subject: Sunday night social? In-Reply-To: References: , Message-ID: Yes. Best Regards, -Dave On Sun, Jun 12, 2016 at 1:24 PM -0400, "Weir, Colin" wrote: Is Wednesday night the only social? -- Colin Weir Engineer, Quality of Experience, Comcast Cable Desk: 215-286-5406 Cell: 215-279-1733 ________________________________________ From: NANOG on behalf of Valerie Wittkop Sent: Friday, June 10, 2016 6:14:16 PM To: Matthew Petach Cc: nanog at nanog.org Subject: Re: Sunday night social? Hi Matt - The registration questions built into Cvent are a standard set which is created prior to confirmation of sponsored events. The questions are there as a means to allow potential sponsors to plan accordingly. There is not a Sunday Social taking place in Chicago. Apologies if the standard questions in the registration process caused confusion. You can always check the true schedule of events by visiting the event agenda. Cheers, Valerie On Fri, Jun 10, 2016 at 5:53 PM, Matthew Petach wrote: > > I just finished registering for NANOG 67, and answered Yes to "Will you > be attending the sunday evening social" and booked my flight > accordingly...but now i can't seem to find any details on what time it > starts on the website. Does anyone know what time it starts? > > > > Thanks! > > > > Matt > > > > > -- Valerie Wittkop NANOG Program Director +1.866.902.1336, Ext. 103 From joelja at bogus.com Sun Jun 12 18:00:28 2016 From: joelja at bogus.com (joel jaeggli) Date: Sun, 12 Jun 2016 11:00:28 -0700 Subject: Detecting Attacks In-Reply-To: References: Message-ID: <7e028977-043c-1f40-c3d2-4fd7dfcaa02d@bogus.com> On 6/10/16 10:39 PM, subashini hariharan wrote: > Hello, > > I am Subashini, a graduate student. I am interested in doing my project in > Network Security. I have a doubt related to it. > > The aim is to detect DoS/DDoS attacks using the application. I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). > > My doubt is regarding how do we generate logs for detecting this attack? As > I am new to this process, I am not sure about it. lots of dos simply isn't targeting the application layer or even the host especially. So, that stuff will rarely bubble up via syslog for example until machines start to run into trouble. rather it will be exposed via flow data or the frequent collection of interface counters. > Also, if it is possible to do any other attacks similar to this, you can > please give a hint about it. > > Could anyone please help with this, it would be a great help!! > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Sun Jun 12 18:31:49 2016 From: randy at psg.com (Randy Bush) Date: Sun, 12 Jun 2016 11:31:49 -0700 Subject: Sunday night social? In-Reply-To: References: Message-ID: >> Is Wednesday night the only social? > Yes. damn! if i had known there was a chance of folk acting more like sober adults than the usual frat boys i might have scheduled chicago. randy From pavel.odintsov at gmail.com Sun Jun 12 18:41:43 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 12 Jun 2016 21:41:43 +0300 Subject: Detecting Attacks In-Reply-To: References: Message-ID: Hello! You could try my open source project: https://github.com/pavel-odintsov/fastnetmon It's pretty popular and used by a very big number of really big networks. We have option for capturing "pcap" dump for each attack for detailed investigation. On Sat, Jun 11, 2016 at 8:22 AM, subashini hariharan wrote: > Hello, > > I am Subashini, a graduate student. I am interested in doing my project in > Network Security. I have a doubt related to it. > > The aim is to detect DoS/DDoS attacks using the application. I am going to > use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log > Analytics). > > My doubt is regarding how do we generate logs for detecting this attack? As > I am new to this process, I am not sure about it. > > Also, if it is possible to do any other attacks similar to this, you can > please give a hint about it. > > Could anyone please help with this, it would be a great help!! > > > -- > Thank You. > > With Regards, > H.Subashini -- Sincerely yours, Pavel Odintsov From dave at temk.in Sun Jun 12 19:53:52 2016 From: dave at temk.in (Dave Temkin) Date: Sun, 12 Jun 2016 19:53:52 +0000 (UTC) Subject: Sunday night social? In-Reply-To: References: , Message-ID: Just to clarify based on offline messages: There are still the usual after-Plenary programs such as Peering Personals, Beer & Gear, etc.. There are just no off-site socials aside from Wednesday evening. The agenda is up to date. -Dave On Sun, Jun 12, 2016 at 1:47 PM -0400, "Dave Temkin" wrote: Yes. Best Regards, -Dave On Sun, Jun 12, 2016 at 1:24 PM -0400, "Weir, Colin" wrote: Is Wednesday night the only social? -- Colin Weir Engineer, Quality of Experience, Comcast Cable Desk: 215-286-5406 Cell: 215-279-1733 ________________________________________ From: NANOG on behalf of Valerie Wittkop Sent: Friday, June 10, 2016 6:14:16 PM To: Matthew Petach Cc: nanog at nanog.org Subject: Re: Sunday night social? Hi Matt - The registration questions built into Cvent are a standard set which is created prior to confirmation of sponsored events. The questions are there as a means to allow potential sponsors to plan accordingly. There is not a Sunday Social taking place in Chicago. Apologies if the standard questions in the registration process caused confusion. You can always check the true schedule of events by visiting the event agenda. Cheers, Valerie On Fri, Jun 10, 2016 at 5:53 PM, Matthew Petach wrote: > > I just finished registering for NANOG 67, and answered Yes to "Will you > be attending the sunday evening social" and booked my flight > accordingly...but now i can't seem to find any details on what time it > starts on the website. Does anyone know what time it starts? > > > > Thanks! > > > > Matt > > > > > -- Valerie Wittkop NANOG Program Director +1.866.902.1336, Ext. 103 From jay at west.net Sun Jun 12 19:53:56 2016 From: jay at west.net (Jay Hennigan) Date: Sun, 12 Jun 2016 12:53:56 -0700 Subject: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed) In-Reply-To: <543225C0-18BC-4F42-A49C-4F28501D4803@arbor.net> References: <751afe59-d016-5338-0753-c4b9a9a62257@mykolab.com> <543225C0-18BC-4F42-A49C-4F28501D4803@arbor.net> Message-ID: On 6/1/16 9:23 PM, Roland Dobbins wrote: > On 2 Jun 2016, at 10:47, Paul Ferguson wrote: > >> There is an epic lesson here. I'm just not sure what it is. :-) > > That Netflix offering free streaming to everyone over IPv6 (after fixing > their VPN detection) would be the most effective way to convince > end-users to demand IPv6 service from their ISPs? Something (somewhat) similar was tried in 2007. TTBOMK it never got fully implemented. "The Great IPv6 Experiment" https://www.nanog.org/mailinglist/mailarchives/old_archive/2007-09/msg00008.html -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From lists at cmsws.com Sun Jun 12 17:53:56 2016 From: lists at cmsws.com (Jim Lucas) Date: Sun, 12 Jun 2016 17:53:56 +0000 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: Message-ID: <4cf4a1790eda2263bb3bc288cefcffdc@mail.cmsws.com> June 8 2016 6:08 PM, "Eric Kuhnke" wrote: > If you had to put up a public facing webmail interface for people to use, > and maintain it for the foreseeable future (5-6 years), what would you use? > > Roundcube? > https://roundcube.net > > Rainloop? > http://www.rainloop.net > > Something else? > > Requirements: > Needs to be open souce and GPL, BSD or Apache licensed > > Email storage will be accessed via IMAP/TLS1.2 > > Runs on a Debian based platform with apache2 or nginx > > Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" > size screens with Chrome and Safari I work for an ISP, and recently we were faced with the same dilemma. We knew that our RoundCube was rather old and needed a facelift. We started looking at new clients what I came across RainLoop. IMO RoundCube still doesn't have a decent working mobile theme. I went ahead and installed RainLoop on my personal server. Configuration was a breeze. The interface is very nice. And the mobile layout is very slick. I did come across a problem with displaying emails and when I emailed their support email, they were very quick to respond. And within 24 hors they were able to write a fix for my specific issue and build a new release for me to download and test. I think that says something for their support team. Even if my office doesn't adopt RainLoop, I will continue using it on my personal server for the forsee able future. -- Jim Lucas C - 5414085189 H - 5413234219 http://cmsws.com From julien.t43+nanog at gmail.com Sun Jun 12 20:10:06 2016 From: julien.t43+nanog at gmail.com (Julien T) Date: Sun, 12 Jun 2016 16:10:06 -0400 Subject: phish platform ? Message-ID: Hello, I'm reviewing the process how to manage phish report at a customer and am looking for tools ideally opensource. Recently, OVH released https://github.com/ovh/cerberus-ux and maybe AbuseHelper can do http://abusehelper.be/ I also checked APWG but didn't find reference to such a tool. Quick constraints: multiple types of input+garbage, metrics, API, SIEM integration Any advices of a public tool? or mostly in-house dev? Thanks a lot. Cheers, Jul From toddunder at gmail.com Sun Jun 12 22:08:09 2016 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 12 Jun 2016 18:08:09 -0400 Subject: Sunday night social? In-Reply-To: References: Message-ID: surely this is not the same randy bush that loves to point out that humans are social animals! t On Sun, Jun 12, 2016 at 2:31 PM, Randy Bush wrote: >>> Is Wednesday night the only social? >> Yes. > > damn! if i had known there was a chance of folk acting more like sober > adults than the usual frat boys i might have scheduled chicago. > > randy From randy at psg.com Sun Jun 12 22:18:15 2016 From: randy at psg.com (Randy Bush) Date: Sun, 12 Jun 2016 15:18:15 -0700 Subject: Sunday night social? In-Reply-To: References: Message-ID: <07BB12BA-0DC9-41A2-BFA2-10DE68DB5FEE@psg.com> This may surprise some, but social != frat boys. randy, on a phone > On Jun 12, 2016, at 15:08, Todd Underwood wrote: > > surely this is not the same randy bush that loves to point out that > humans are social animals! > > t > > On Sun, Jun 12, 2016 at 2:31 PM, Randy Bush wrote: >>>> Is Wednesday night the only social? >>> Yes. >> >> damn! if i had known there was a chance of folk acting more like sober >> adults than the usual frat boys i might have scheduled chicago. >> >> randy From toddunder at gmail.com Sun Jun 12 22:19:13 2016 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 12 Jun 2016 18:19:13 -0400 Subject: Sunday night social? In-Reply-To: <07BB12BA-0DC9-41A2-BFA2-10DE68DB5FEE@psg.com> References: <07BB12BA-0DC9-41A2-BFA2-10DE68DB5FEE@psg.com> Message-ID: huh. today we learn that social is subject to particular people's view of social. please author an RFC to explain the scope that counts as social. thanks! t On Sun, Jun 12, 2016 at 6:18 PM, Randy Bush wrote: > This may surprise some, but social != frat boys. > > randy, on a phone > >> On Jun 12, 2016, at 15:08, Todd Underwood wrote: >> >> surely this is not the same randy bush that loves to point out that >> humans are social animals! >> >> t >> >> On Sun, Jun 12, 2016 at 2:31 PM, Randy Bush wrote: >>>>> Is Wednesday night the only social? >>>> Yes. >>> >>> damn! if i had known there was a chance of folk acting more like sober >>> adults than the usual frat boys i might have scheduled chicago. >>> >>> randy From owen at delong.com Sun Jun 12 23:47:18 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 12 Jun 2016 16:47:18 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> Message-ID: <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> > On Jun 9, 2016, at 19:57 , Ricky Beam wrote: > > On Thu, 09 Jun 2016 21:41:05 -0400, Baldur Norddahl wrote: > >> Then he reads on NANOG that since he has IPv6 >> he can just connect to the camera with that. > ... > > Only to find the built-in stateful firewall blocks unsolicited inbound connections. Now he has to figure out how to manipulate ACLs. Or (more likely) he turns that "pesky firewall" off. (followed by the eventual hacking of every device he owns.) > > NAT may not be security, yet it's the only thing securing billions of people. Nope? NAT Can?t be done without stateful inspection. You can stop mangling the packet headers and leave the stateful inspection in place and still have the same exact protection. I realize most people have a hard time separating NAT from stateful inspection because most people got them both in the same package at the same time. Further, most boxes implement NAT and stateful inspection in the same chunk of code making it look even more like a single transaction. However, conceptually they are two different things. Stateful inspection is what actually protects you. NAT is simply the part where you mutilate the packet header in unnatural ways. Owen From owen at delong.com Mon Jun 13 00:05:17 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 12 Jun 2016 17:05:17 -0700 Subject: Netflix banning HE tunnels In-Reply-To: <156713.1465547545@turing-police.cc.vt.edu> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <0e36! ! af3e-9781-4f2b-1080-af915fff3755@blakjak.net> <1465539562.450519746@apps.rackspace.com> <156713.1465547545@turing-police.cc.vt.edu> Message-ID: > On Jun 10, 2016, at 01:32 , Valdis.Kletnieks at vt.edu wrote: > > On Fri, 10 Jun 2016 07:19:22 +0100, "tim at pelican.org" said: > >> All the business systems that sit around it? Not so much. $DAYJOB has >> plenty of code, database structures etc that are built around "an IP address is >> no more than 15 characters long and matches >> '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you need >> development time - typically expensive analyst time to work out *what* you need >> to change, not just code-grinder make-the-field-bigger time. IT departments >> seem reluctant to provide that resource, unless you've got people at the very >> top of the business bought into the fact that you *need* to do IPv6. That was a pretty dumb way to store IPv4 addresses, frankly. First, 593.812.904.601 matches your regular expression, and isn?t an IP address. If you were smart (IMHO), you stored IPv4 addresses as 32-bit integers. First, update the software in question to understand IPv4 mapped addresses for parsing/displaying (IPv4->::ffff:i.p.v.4 for parsing and reverse the process for display) and then modify the database schema. With most databases and other software, converting a 32-bit integer field into a 128 bit integer field isn?t particularly hard. Once you?ve done that, make a quick single pass through the database adding 281,470.681.743.360 to all integers < 4,294,967,296. (That should replace the equivalent of 0:0:0:0:0:0:ip:v4 with the equivalent of 0:0:0:0:0:ffff:ip:v4) There are a number of reasons for converting all IP addresses to integers prior to processing in software. 1. Easier and more consistent sorting. 2. Consistent and easier comparisons for equality or ranges In iPv4, this was useful. In IPv6, it?s essential. e.g. IPv4: 90.90 == 90.0.0.90 IPv4: 33280.33288 == 130.0.130.8 IPv6: All of the following are equal 2001:db8::3 2001:0db8::0003 2001:0db8:0:0:0:0:0:3 2001:db8:0::3 etc. Also: 2620::930:0:0:0:200:2 2620:0:930::200:2 etc. 3. Easier to deal with future changes (such as expanding from 32-bit IPv4 numbers to 128-bit IPv6 numbers) 4. Representation can be left to the user interface where it belongs instead of embedded throughout the application. The network stack only deals with integers, why not keep them as integers everywhere else as well. The other expressions are just for human readability. Treat them like any other Locale based UI issue. Yes, you need to get the people at the top bought into the idea that IPv6 must be deployed, but these days, that really shouldn?t be all that hard to do with competent management and a reasonable networking department. Owen From owen at delong.com Mon Jun 13 00:13:47 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 12 Jun 2016 17:13:47 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <1465528350.1518.383.camel@biplane.com.au> Message-ID: <0F772349-45EE-4A61-9000-3A9A2DE89E6A@delong.com> > On Jun 10, 2016, at 11:58 , Cryptographrix wrote: > > Just to clarify - there's no transition involved - IPv4 to IPv6 is like > going from the VINES protocol to IPv6: IPv6 may as well have been called > "PROTOCOL 493" - it bares very little relation to the original protocol > that brought us the internet as-it-is-today. Yes and no. VINES didn?t have TCP/UDP/ICMP. While there are subtle differences, the reality is that 99% of code for IPv4 can be converted to IPv6 compatibility with very little effort. Especially if the IPv4 code was written in the last 20 years with any thought of a possible IPv6 future (i.e. uses the superior getaddrinfo() call instead of gethostbyname(), etc.). Modifying even the simplest of programs from VINES to IPv6 would require replacing ALL of the networking calls with calls that have radically different semantics. For IPv4->IPv6, there are a few things that change, but most of it is pretty close to what you?re used to and many calls can be unchanged. socket() gets some different arguments. setsockopt() likewise bind() is essentially unchanged. send(), recv(), sendto(), recvfrom(), open(), close() all remain the same. This is obviously not an exhaustive list, but I?ve converted several applications in multiple languages and it really isn?t all that difficult. Certainly less difficult than when we went from IPX to IPv4. Owen From baldur.norddahl at gmail.com Mon Jun 13 01:27:41 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jun 2016 03:27:41 +0200 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1465539562.450519746@apps.rackspace.com> <156713.1465547545@turing-police.cc.vt.edu> Message-ID: On 13 June 2016 at 02:05, Owen DeLong wrote: > 2. Consistent and easier comparisons for equality or ranges > In iPv4, this was useful. In IPv6, it?s essential. > You could also normalize your IPv6 text representation. There is even RFC 5952 for that. Abbreviated the rule is: 1) lower case 2) as short as possible, except do not shorten just one :0: into ::. 3) if there is more than one possible :: block that results in the same shortest length, choose the first block as ::. I am not quite sure why they put in the exception not to shorten one zero, but otherwise this is what most people would naturally come up with. Also, technically there is more than one IPv4 representation too. I have in the past poked security holes through this as most people forget (or don't know): Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 PING 100000000 (5.245.225.0): 56 data bytes Regards, Baldur From marka at isc.org Mon Jun 13 01:46:45 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 13 Jun 2016 11:46:45 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Mon, 13 Jun 2016 03:27:41 +0200." References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1465539562.45 0519746@apps.rackspace.com> <156713.1465547545@turing-police.cc.vt.edu> Message-ID: <20160613014645.DA5954B2E6B4@rock.dv.isc.org> In message , Baldur Norddahl writes: > On 13 June 2016 at 02:05, Owen DeLong wrote: > > > 2. Consistent and easier comparisons for equality or ranges > > In iPv4, this was useful. In IPv6, it=E2=80=99s essential= > . > > > > > You could also normalize your IPv6 text representation. There is even RFC > 5952 for that. Abbreviated the rule is: > > 1) lower case > 2) as short as possible, except do not shorten just one :0: into ::. > 3) if there is more than one possible :: block that results in the same > shortest length, choose the first block as ::. > > I am not quite sure why they put in the exception not to shorten one zero, > but otherwise this is what most people would naturally come up with. Those rules are good for equality but not much more. > Also, technically there is more than one IPv4 representation too. I have in > the past poked security holes through this as most people forget (or don't > know): As Owen mentioned. > Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 > PING 100000000 (5.245.225.0): 56 data bytes > > Regards, > > Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Mon Jun 13 03:10:59 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 12 Jun 2016 20:10:59 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: Message-ID: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> On 6/7/16 4:23 AM, Davide Davini wrote: > Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I > can't use it if I don't disable the HE tunnel, which is the only way for > me to have IPv6 at the moment. This is a rights management issue not a technical one. Netflix is not to blame, HE is not to blame. Hate on geolcaotion all you want, but that's what the content owners insist upon and Netflix has no choice but to disable access from sources that they can't geolocate well enough to make the content owners happy. ~Seth From Valdis.Kletnieks at vt.edu Mon Jun 13 03:35:34 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 12 Jun 2016 23:35:34 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1465! 539562.450519746@apps.rackspace.com> <156713.1465547545@turing-police.cc.vt.edu> Message-ID: <178733.1465788934@turing-police.cc.vt.edu> On Mon, 13 Jun 2016 03:27:41 +0200, Baldur Norddahl said: > On 13 June 2016 at 02:05, Owen DeLong wrote: > > 1) lower case > 2) as short as possible, except do not shorten just one :0: into ::. > 3) if there is more than one possible :: block that results in the same > shortest length, choose the first block as ::. > > I am not quite sure why they put in the exception not to shorten one zero, > but otherwise this is what most people would naturally come up with. So that 2001:365:0:1213:0:0:0:5 gets shortened to 2001:365:0:1213::5 rather than 2001:365:)1213:0:0:0:5. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From karim.adel at gmail.com Mon Jun 13 01:52:20 2016 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 12 Jun 2016 18:52:20 -0700 Subject: Thinking Methodically about building a PoC Message-ID: hi, I am asked to build a large lab/test it. I'm provided crazy scale numbers for lots of technologies (L*VPN, IPv*, IGP*, All Tunnels flavors...etc). It took me a lot of time to build this lab, because when I got the request/test plan handed over to me, I did not verify that these scaled numbers are even possible, not to mention the combination. I assumed some thought/research were done before. I'm trying to put together a list of the lessons learned, and the right way to do this for future reference, specially that this project was time critical and I got beaten hard because I did not deliver on time. So my question is, in your extensive experience, what is the right method/approach to this kind of task: 1) Get started immediately (MVP), things will break, tune it along the way. 2) Do some planning and research first. I'd appreciate any references to 'software engineering' or other industries/ Thanks From rdobbins at arbor.net Mon Jun 13 04:49:53 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 13 Jun 2016 11:49:53 +0700 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: On 13 Jun 2016, at 8:52, Kasper Adel wrote: > 2) Do some planning and research first. This. ----------------------------------- Roland Dobbins From tknchris at gmail.com Mon Jun 13 05:34:00 2016 From: tknchris at gmail.com (chris) Date: Mon, 13 Jun 2016 01:34:00 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> References: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> Message-ID: Sure they are free to do this but it doesn't mean people can't voice their opinions. This is almost identical logic that was used in the days of DVD. Users wanted their content in a different medium, companies failed to invest in developing a way the new method could be profitable and chose to invest huge resources chasing down their customers and calling them criminals. Judging by all the services out there that were profiting on providing foreign users various methods to access US content, this shows there is a huge demand for this and people are even willing to pay up every month to a 3rd party on top of their netflix subscription. So rather than just blocking these people why not just offer them another price tier with zero or lesser geo restrictions which gives them what they want? chris On Sun, Jun 12, 2016 at 11:10 PM, Seth Mattinen wrote: > On 6/7/16 4:23 AM, Davide Davini wrote: > >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I >> can't use it if I don't disable the HE tunnel, which is the only way for >> me to have IPv6 at the moment. >> > > > This is a rights management issue not a technical one. Netflix is not to > blame, HE is not to blame. Hate on geolcaotion all you want, but that's > what the content owners insist upon and Netflix has no choice but to > disable access from sources that they can't geolocate well enough to make > the content owners happy. > > ~Seth > From sethm at rollernet.us Mon Jun 13 05:37:43 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 12 Jun 2016 22:37:43 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> Message-ID: <39056f34-e345-52f6-17cd-152bcc1ddbd0@rollernet.us> On 6/12/16 10:34 PM, chris wrote: > > So rather than just blocking these people why not just offer them > another price tier with zero or lesser geo restrictions which gives them > what they want? That's not up to Netflix. ~Seth From mpetach at netflight.com Mon Jun 13 06:20:12 2016 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 12 Jun 2016 23:20:12 -0700 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: On Sun, Jun 12, 2016 at 9:49 PM, Roland Dobbins wrote: > > On 13 Jun 2016, at 8:52, Kasper Adel wrote: > >> 2) Do some planning and research first. > > This. > > ----------------------------------- > Roland Dobbins > We never design in a vacuum. There's always some target we're designing towards. Testing is no different. Think about what it is you'll need to support. Look at historical numbers related to those features/capabilities. Yes, as the stork market keeps reminding us, past performance is no guarantee of future results...but at the same time, those who don't learn from the past are doomed to re-implement it...poorly. So, when we test, we look at protocols we've already been running for years, and then we look at the growth curves we've seen in those protocols over the past X years, where X is approximately the estimated lifespan of the hardware in question. So, if the current router platform you're looking to replace has been in place in your network for 8 years, and you're testing the next generation for BGP route scaling, look at what the global BGP table size was 8 years ago, and look at where it is today; work out the percentage growth curve for it; then take the current BGP table size, apply the same compound growth percentage to it for the next 8 years, and you'll come up with a reasonable idea of the scale you'll need the box to handle over its lifetime. Test that; then, to give yourself a margin of error, double the number, and test again. That way you have a realistic idea of whether it can support your current growth rate, and whether it can support your growth if the growth rate is 1.4x what you expect. Do those calculations for each of the protocols under test, and you'll be able to come up with a reasonable testing profile that's supportable based on historical information, rather than flights of fancy. Hope that helps! Matt From owen at delong.com Mon Jun 13 08:56:27 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2016 01:56:27 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1465! 539562.450519746@apps.rackspace.com> <156713.1465547545@turing-police.cc.vt.edu> Message-ID: <84A7F59F-2FED-4F34-9B90-A26EE3C67824@delong.com> > On Jun 12, 2016, at 18:27 , Baldur Norddahl wrote: > > On 13 June 2016 at 02:05, Owen DeLong wrote: > >> 2. Consistent and easier comparisons for equality or ranges >> In iPv4, this was useful. In IPv6, it?s essential. >> > > > You could also normalize your IPv6 text representation. There is even RFC > 5952 for that. Abbreviated the rule is: > > 1) lower case > 2) as short as possible, except do not shorten just one :0: into ::. > 3) if there is more than one possible :: block that results in the same > shortest length, choose the first block as ::. > > I am not quite sure why they put in the exception not to shorten one zero, > but otherwise this is what most people would naturally come up with. Actually, it isn?t. Consider the case of 2001:0:0::/48 and the resultant subnet 2001:0:0:406::/64. Now consider the static address of a host within that subnet 2001:0:0:406:0:0:0:302. Most people would naturally tend to write this as 2001:0:0:406::302. However, your ruleset would write it as 2001::406:0:0:0:302. Yes, you can use a standardized text representation, but the easiest way to produce this in most cases is to first convert to an integer then convert back to a representation of the integer. If you?re going to go to all the trouble to convert to an integer to begin with, isn?t it easier to just shovel things around as a 128-bit integer which has the advantage of also being fixed-length and more compact in memory? > Also, technically there is more than one IPv4 representation too. I have in > the past poked security holes through this as most people forget (or don't > know): > > Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 > PING 100000000 (5.245.225.0): 56 data bytes Yes, I believe I made examples of those and stated that it made more sense to store IPv4 addresses as integers as well. Owen From baldur.norddahl at gmail.com Mon Jun 13 09:16:58 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jun 2016 11:16:58 +0200 Subject: Netflix banning HE tunnels In-Reply-To: <84A7F59F-2FED-4F34-9B90-A26EE3C67824@delong.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <156713.1465547545@turing-police.cc.vt.edu> <84A7F59F-2FED-4F34-9B90-A26EE3C67824@delong.com> Message-ID: On 13 June 2016 at 10:56, Owen DeLong wrote: > Actually, it isn?t. > > Consider the case of 2001:0:0::/48 and the resultant subnet > 2001:0:0:406::/64. > > Now consider the static address of a host within that subnet > 2001:0:0:406:0:0:0:302. > > Most people would naturally tend to write this as 2001:0:0:406::302. > > However, your ruleset would write it as 2001::406:0:0:0:302. > > No. That fails for the rule "as short as possible". It is a common misconception to shorten the first possible :: run, but that is not the rule. The same comment goes to the other person that came with a similar example. The rule not to shorten a single zero means that 2001:db8:0:1:1:1:1:1 can not be shorten to 2001:db8::1:1:1:1:1 even though that is actually one character shorter. The full set of rules from the RFC: 4.1 . Handling Leading Zeros in a 16-Bit Field Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16- bit 0000 field MUST be represented as 0. 4.2 . "::" Usage 4.2.1 . Shorten as Much as Possible The use of the symbol "::" MUST be used to its maximum capability. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1. 4.2.2 . Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. 4.2.3 . Choice in Placement of "::" When there is an alternative choice in the placement of a "::", the longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., the sequence with three consecutive zero fields is shortened in 2001: 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct representation. 4.3 . Lowercase The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase. > Yes, you can use a standardized text representation, but the easiest way > to produce > this in most cases is to first convert to an integer then convert back to > a representation > of the integer. If you?re going to go to all the trouble to convert to an > integer to begin > with, isn?t it easier to just shovel things around as a 128-bit integer > which has the > advantage of also being fixed-length and more compact in memory? > It is hard to read binary integers dumped to a log file. Hence the need for a normalized format, so you can find what you need in the log file using simple unix tools. > > > Also, technically there is more than one IPv4 representation too. I have > in > > the past poked security holes through this as most people forget (or > don't > > know): > > > > Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 > > PING 100000000 (5.245.225.0): 56 data bytes > > Yes, I believe I made examples of those and stated that it made more sense > to store > IPv4 addresses as integers as well. > It is also hard to read binary IPv4 addresses in a log file. Other common places to find IPv4/IPv6 addresses is in configuration files, program code, emails etc. If you are going to apply a netmask or do any other computations, you will of course need to convert to binary regardless of protocol version. And then you will probably convert it back again to text before outputting the result, and in this step you should use the rules from RFC 5952. Regards, Baldur From owen at delong.com Mon Jun 13 09:22:21 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2016 02:22:21 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1567! 13.1465547545@turing-police.cc.vt.edu> <84A7F59F-2FED-4F34-9B90-A26EE3C67824@delong.com> Message-ID: > On Jun 13, 2016, at 02:16 , Baldur Norddahl wrote: > > On 13 June 2016 at 10:56, Owen DeLong wrote: > >> Actually, it isn?t. >> >> Consider the case of 2001:0:0::/48 and the resultant subnet >> 2001:0:0:406::/64. >> >> Now consider the static address of a host within that subnet >> 2001:0:0:406:0:0:0:302. >> >> Most people would naturally tend to write this as 2001:0:0:406::302. >> >> However, your ruleset would write it as 2001::406:0:0:0:302. >> >> > No. That fails for the rule "as short as possible". It is a common > misconception to shorten the first possible :: run, but that is not the > rule. > > The same comment goes to the other person that came with a similar example. > The rule not to shorten a single zero means that 2001:db8:0:1:1:1:1:1 can > not be shorten to 2001:db8::1:1:1:1:1 even though that is actually one > character shorter. > Fine? Consider 2001:0:0:406:0:0:5:302. Owen > The full set of rules from the RFC: > > > 4.1 . Handling > Leading Zeros in a 16-Bit Field > > Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is > not acceptable and must be represented as 2001:db8::1. A single 16- > bit 0000 field MUST be represented as 0. > 4.2 . "::" Usage > 4.2.1 . Shorten as > Much as Possible > > The use of the symbol "::" MUST be used to its maximum capability. > For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. > Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" > could have been used to produce a shorter representation 2001:db8::1. > 4.2.2 . Handling > One 16-Bit 0 Field > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. > 4.2.3 . Choice in > Placement of "::" > > When there is an alternative choice in the placement of a "::", the > longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., > the sequence with three consecutive zero fields is shortened in 2001: > 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields > are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero > bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct > representation. > 4.3 . Lowercase > > The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address > MUST be represented in lowercase. > > > > >> Yes, you can use a standardized text representation, but the easiest way >> to produce >> this in most cases is to first convert to an integer then convert back to >> a representation >> of the integer. If you?re going to go to all the trouble to convert to an >> integer to begin >> with, isn?t it easier to just shovel things around as a 128-bit integer >> which has the >> advantage of also being fixed-length and more compact in memory? >> > > It is hard to read binary integers dumped to a log file. Hence the need for > a normalized format, so you can find what you need in the log file using > simple unix tools. > > >> >>> Also, technically there is more than one IPv4 representation too. I have >> in >>> the past poked security holes through this as most people forget (or >> don't >>> know): >>> >>> Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 >>> PING 100000000 (5.245.225.0): 56 data bytes >> >> Yes, I believe I made examples of those and stated that it made more sense >> to store >> IPv4 addresses as integers as well. >> > > It is also hard to read binary IPv4 addresses in a log file. > > Other common places to find IPv4/IPv6 addresses is in configuration files, > program code, emails etc. > > If you are going to apply a netmask or do any other computations, you will > of course need to convert to binary regardless of protocol version. And > then you will probably convert it back again to text before outputting the > result, and in this step you should use the rules from RFC 5952. > > Regards, > > Baldur From baldur.norddahl at gmail.com Mon Jun 13 12:43:08 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jun 2016 14:43:08 +0200 Subject: Netflix banning HE tunnels In-Reply-To: References: <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <20160610043852.63A604B1DAB6@rock.dv.isc.org> <1567! 13.1465547545@turing-police.cc.vt.edu> <84A7F59F-2FED-4F34-9B90-A26EE3C67824@delong.com> Message-ID: <575EAA5C.50701@gmail.com> On 2016-06-13 11:22, Owen DeLong wrote: > Fine? Consider 2001:0:0:406:0:0:5:302. Owen That is a Teredo reserved address. Neither option makes any sense because it is an invalid Teredo address. You can find examples with two equal possible :: blocks but they are actually rare. Try to find one that has non zeros in the first 32 bits, as that is usually the case for any actually assigned prefix. I hold that for any actually assigned prefix, it will almost always be the first possible :: block that makes sense - prove me wrong. Consider: 2001:db8:1:2:3:4:5:6 Provided that the first two 16 bit blocks are non zero, there can only be multiple equal runs of zeros if the run length is 2. This follows from the rule that disallows shorting out a single :0:. Now this leaves the following: 2001:db8:0:0:1:1:0:0 => 2001:db8::1:1:0:0 is most sane because this would usually be host 1:1:0:0 in prefix 2001:db8::/64. 2001:db8:0:0:1:0:0:1 => 2001:db8::1:0:0:1 for the same reason. 2001:db8:1:0:0:1:0:0 => 2001:db8:1::1:0:0 because this is host 1:0:0 in the prefix 2001:db8:1::/64 And that was all possible ways you can have multiple :: blocks in an actually assigned prefix. Regards, Baldur From davidbass570 at gmail.com Mon Jun 13 12:59:25 2016 From: davidbass570 at gmail.com (David Bass) Date: Mon, 13 Jun 2016 08:59:25 -0400 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: <7407E8E3-0D71-405C-9AF2-7AD4703B6A7A@gmail.com> > On Jun 13, 2016, at 12:49 AM, Roland Dobbins wrote: > > >> On 13 Jun 2016, at 8:52, Kasper Adel wrote: >> >> 2) Do some planning and research first. > > This. > > ----------------------------------- > Roland Dobbins I'll second that! How can you do it any other way and get any sort of reliable data...especially a POC. Seems like you would waste a lot of time just plodding forward without doing the research. From ryanczak at gmail.com Mon Jun 13 13:32:49 2016 From: ryanczak at gmail.com (Matt Ryanczak) Date: Mon, 13 Jun 2016 06:32:49 -0700 Subject: Sunday night social? In-Reply-To: References: <07BB12BA-0DC9-41A2-BFA2-10DE68DB5FEE@psg.com> Message-ID: Remember that social != sociable! ~Matt On Jun 12, 2016 15:22, "Todd Underwood" wrote: huh. today we learn that social is subject to particular people's view of social. please author an RFC to explain the scope that counts as social. thanks! t On Sun, Jun 12, 2016 at 6:18 PM, Randy Bush wrote: > This may surprise some, but social != frat boys. > > randy, on a phone > >> On Jun 12, 2016, at 15:08, Todd Underwood wrote: >> >> surely this is not the same randy bush that loves to point out that >> humans are social animals! >> >> t >> >> On Sun, Jun 12, 2016 at 2:31 PM, Randy Bush wrote: >>>>> Is Wednesday night the only social? >>>> Yes. >>> >>> damn! if i had known there was a chance of folk acting more like sober >>> adults than the usual frat boys i might have scheduled chicago. >>> >>> randy From rafael at e2wsolutions.com Mon Jun 13 13:52:41 2016 From: rafael at e2wsolutions.com (Possamai Rafael) Date: Mon, 13 Jun 2016 08:52:41 -0500 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: This may not be an answer very specific to your problem/question, but if you take a look at the following image, you will find a summary of what they called the engineering design methodology: http://www.cdn.sciencebuddies.org/Files/5083/9/2013-updated_engineering-method-steps_v6b.png You can adapt it to your circumstances, for example: instead of defining a problem in step 1, you can define a product, and after knowing what is expected from that product, you can then move to background research, etc. Hope that helps. Rafael On Sun, Jun 12, 2016 at 8:52 PM, Kasper Adel wrote: > hi, > > I am asked to build a large lab/test it. I'm provided crazy scale numbers > for lots of technologies (L*VPN, IPv*, IGP*, All Tunnels flavors...etc). > > It took me a lot of time to build this lab, because when I got the > request/test plan handed over to me, I did not verify that these scaled > numbers are even possible, not to mention the combination. I assumed some > thought/research were done before. > > I'm trying to put together a list of the lessons learned, and the right way > to do this for future reference, specially that this project was time > critical and I got beaten hard because I did not deliver on time. > > So my question is, in your extensive experience, what is the right > method/approach to this kind of task: > > 1) Get started immediately (MVP), things will break, tune it along the way. > 2) Do some planning and research first. > > I'd appreciate any references to 'software engineering' or other > industries/ > > Thanks > From hugo at slabnet.com Mon Jun 13 15:29:51 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 13 Jun 2016 08:29:51 -0700 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: <20160613152951.GA8504@bamboo.slabnet.com> On Mon 2016-Jun-13 08:52:41 -0500, Possamai Rafael via NANOG wrote: >This may not be an answer very specific to your problem/question, but if >you take a look at the following image, you will find a summary of what >they called the engineering design methodology: > >http://www.cdn.sciencebuddies.org/Files/5083/9/2013-updated_engineering-method-steps_v6b.png Seriously thought initially that you were going to link to: http://i2.wp.com/tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png >You can adapt it to your circumstances, for example: instead of defining a >problem in step 1, you can define a product, and after knowing what is >expected from that product, you can then move to background research, etc. > >Hope that helps. > > >Rafael > -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal > > >On Sun, Jun 12, 2016 at 8:52 PM, Kasper Adel wrote: > >> hi, >> >> I am asked to build a large lab/test it. I'm provided crazy scale numbers >> for lots of technologies (L*VPN, IPv*, IGP*, All Tunnels flavors...etc). >> >> It took me a lot of time to build this lab, because when I got the >> request/test plan handed over to me, I did not verify that these scaled >> numbers are even possible, not to mention the combination. I assumed some >> thought/research were done before. >> >> I'm trying to put together a list of the lessons learned, and the right way >> to do this for future reference, specially that this project was time >> critical and I got beaten hard because I did not deliver on time. >> >> So my question is, in your extensive experience, what is the right >> method/approach to this kind of task: >> >> 1) Get started immediately (MVP), things will break, tune it along the way. >> 2) Do some planning and research first. >> >> I'd appreciate any references to 'software engineering' or other >> industries/ >> >> Thanks >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sethm at rollernet.us Mon Jun 13 15:30:43 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 13 Jun 2016 08:30:43 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> Message-ID: On 6/8/16 11:57 AM, Javier J wrote: > If Netflix needs help with this point me in the right direction. I'll be > happy to fix it for them and send them a bill. You'll negotiate with the content rights holders? ~Seth From briansupport at hotmail.com Mon Jun 13 15:40:25 2016 From: briansupport at hotmail.com (Brian R) Date: Mon, 13 Jun 2016 15:40:25 +0000 Subject: Thinking Methodically about building a PoC In-Reply-To: References: , Message-ID: Agreed, the margin of growth never seems to stay consistent or be what you predict. Instead of asking "What do you want?" (or taking their specs). I have lots of ideas of what I want but maybe not what I need. Ask these questions, they've gotten me better answers and have allowed me to do the hardware/software framework not the end user/client. "What are you trying to sell?" "What are you trying to do?" Brian ________________________________ From: NANOG on behalf of Matthew Petach Sent: Sunday, June 12, 2016 11:20 PM To: Roland Dobbins Cc: NANOG list Subject: Re: Thinking Methodically about building a PoC On Sun, Jun 12, 2016 at 9:49 PM, Roland Dobbins wrote: > > On 13 Jun 2016, at 8:52, Kasper Adel wrote: > >> 2) Do some planning and research first. > > This. > > ----------------------------------- > Roland Dobbins > We never design in a vacuum. There's always some target we're designing towards. Testing is no different. Think about what it is you'll need to support. Look at historical numbers related to those features/capabilities. Yes, as the stork market keeps reminding us, past performance is no guarantee of future results...but at the same time, those who don't learn from the past are doomed to re-implement it...poorly. So, when we test, we look at protocols we've already been running for years, and then we look at the growth curves we've seen in those protocols over the past X years, where X is approximately the estimated lifespan of the hardware in question. So, if the current router platform you're looking to replace has been in place in your network for 8 years, and you're testing the next generation for BGP route scaling, look at what the global BGP table size was 8 years ago, and look at where it is today; work out the percentage growth curve for it; then take the current BGP table size, apply the same compound growth percentage to it for the next 8 years, and you'll come up with a reasonable idea of the scale you'll need the box to handle over its lifetime. Test that; then, to give yourself a margin of error, double the number, and test again. That way you have a realistic idea of whether it can support your current growth rate, and whether it can support your growth if the growth rate is 1.4x what you expect. Do those calculations for each of the protocols under test, and you'll be able to come up with a reasonable testing profile that's supportable based on historical information, rather than flights of fancy. Hope that helps! Matt From bill at herrin.us Mon Jun 13 18:57:31 2016 From: bill at herrin.us (William Herrin) Date: Mon, 13 Jun 2016 14:57:31 -0400 Subject: Thinking Methodically about building a PoC In-Reply-To: References: Message-ID: On Sun, Jun 12, 2016 at 9:52 PM, Kasper Adel wrote: > 1) Get started immediately (MVP), things will break, tune it along the way. Howdy, The history of the Panama Canal (both the French failure and the deadly first two years of the U.S. effort) should offer insight (and appropriate anecdotes) as to why this is just about always the worst answer. The same history also shows how planning moves from the French effort (an impossible sea-level canal through a river valley that suffers seasonal floods) to the entirely different engineering which produced a gigantic man-made lake with flood control dams plus a gravity-driven lock system to move vessels from sea level to the lake level and back. They did it very wrong. Then they redid it very right salvaging only a little of the original effort. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From maxtul at netassist.ua Mon Jun 13 19:11:47 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 13 Jun 2016 22:11:47 +0300 Subject: Measuring the quality of Internet access Message-ID: <575F0573.1050406@netassist.ua> Hi All, I know there are many people from many countries. Do you know something about mandatory measurements of Internet access quality from country telecom regulators? If yes, could you please share that information with me? I found ETSI EG 202 057-4 standard (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), but in fact it is about measurements inside operator's network, not Internet access itself. Is it possible in general to measure the quality of Internet access? And if yes - how? From EDugas at zerofail.com Mon Jun 13 20:04:16 2016 From: EDugas at zerofail.com (Eric Dugas) Date: Mon, 13 Jun 2016 20:04:16 +0000 Subject: Measuring the quality of Internet access In-Reply-To: <575F0573.1050406@netassist.ua> References: <575F0573.1050406@netassist.ua> Message-ID: <37bc1454faef47faab89c2e787b6fe31@zerofail.com> CIRA (.CA) started a project one or two years ago: https://cira.ca/build-better-internet/cira-internet-performance-test CRTC (Canadian equivalent of the FCC) also conducted tests by sending test boxes to volunteers: http://www.crtc.gc.ca/eng/internet/performance.htm and https://www.measuringbroadbandcanada.com Eric -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev Sent: June 13, 2016 3:12 PM To: NANOG list Subject: Measuring the quality of Internet access Hi All, I know there are many people from many countries. Do you know something about mandatory measurements of Internet access quality from country telecom regulators? If yes, could you please share that information with me? I found ETSI EG 202 057-4 standard (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), but in fact it is about measurements inside operator's network, not Internet access itself. Is it possible in general to measure the quality of Internet access? And if yes - how? From maxtul at netassist.ua Mon Jun 13 20:18:57 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 13 Jun 2016 23:18:57 +0300 Subject: Measuring the quality of Internet access In-Reply-To: <37bc1454faef47faab89c2e787b6fe31@zerofail.com> References: <575F0573.1050406@netassist.ua> <37bc1454faef47faab89c2e787b6fe31@zerofail.com> Message-ID: <575F1531.8080501@netassist.ua> Thank you! I got one more reply off-list - and again it is connected to SamKnows. But I can't figure out what SamKnows uses as the destination for tests? On 13.06.16 23:04, Eric Dugas wrote: > CIRA (.CA) started a project one or two years ago: https://cira.ca/build-better-internet/cira-internet-performance-test > > CRTC (Canadian equivalent of the FCC) also conducted tests by sending test boxes to volunteers: http://www.crtc.gc.ca/eng/internet/performance.htm and https://www.measuringbroadbandcanada.com > > Eric > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev > Sent: June 13, 2016 3:12 PM > To: NANOG list > Subject: Measuring the quality of Internet access > > Hi All, > > I know there are many people from many countries. > > Do you know something about mandatory measurements of Internet access quality from country telecom regulators? If yes, could you please share that information with me? > > I found ETSI EG 202 057-4 standard > (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), > but in fact it is about measurements inside operator's network, not Internet access itself. > > Is it possible in general to measure the quality of Internet access? And if yes - how? > From arturo.servin at gmail.com Mon Jun 13 20:26:46 2016 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 13 Jun 2016 20:26:46 +0000 Subject: Measuring the quality of Internet access In-Reply-To: <575F1531.8080501@netassist.ua> References: <575F0573.1050406@netassist.ua> <37bc1454faef47faab89c2e787b6fe31@zerofail.com> <575F1531.8080501@netassist.ua> Message-ID: Would be M-lab (https://www.measurementlab.net/about/) what you are looking for? .as On Mon, 13 Jun 2016 at 13:20 Max Tulyev wrote: > Thank you! > > I got one more reply off-list - and again it is connected to SamKnows. > > But I can't figure out what SamKnows uses as the destination for tests? > > On 13.06.16 23:04, Eric Dugas wrote: > > CIRA (.CA) started a project one or two years ago: > https://cira.ca/build-better-internet/cira-internet-performance-test > > > > CRTC (Canadian equivalent of the FCC) also conducted tests by sending > test boxes to volunteers: > http://www.crtc.gc.ca/eng/internet/performance.htm and > https://www.measuringbroadbandcanada.com > > > > Eric > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev > > Sent: June 13, 2016 3:12 PM > > To: NANOG list > > Subject: Measuring the quality of Internet access > > > > Hi All, > > > > I know there are many people from many countries. > > > > Do you know something about mandatory measurements of Internet access > quality from country telecom regulators? If yes, could you please share > that information with me? > > > > I found ETSI EG 202 057-4 standard > > ( > http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf > ), > > but in fact it is about measurements inside operator's network, not > Internet access itself. > > > > Is it possible in general to measure the quality of Internet access? And > if yes - how? > > > > From Valdis.Kletnieks at vt.edu Mon Jun 13 20:38:52 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 13 Jun 2016 16:38:52 -0400 Subject: Measuring the quality of Internet access In-Reply-To: <575F0573.1050406@netassist.ua> References: <575F0573.1050406@netassist.ua> Message-ID: <96821.1465850332@turing-police.cc.vt.edu> On Mon, 13 Jun 2016 22:11:47 +0300, Max Tulyev said: > Is it possible in general to measure the quality of Internet access? And > if yes - how? First, *define* "quality". Raw bandwidth to a test server? Raw bandwidth to a weighted average of the Alexa Top 100? Does RTT/bufferbloat count? What about RTT jitter? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From collin at averysmallbird.com Mon Jun 13 20:58:22 2016 From: collin at averysmallbird.com (Collin Anderson) Date: Mon, 13 Jun 2016 16:58:22 -0400 Subject: Measuring the quality of Internet access In-Reply-To: <575F1531.8080501@netassist.ua> References: <575F0573.1050406@netassist.ua> <37bc1454faef47faab89c2e787b6fe31@zerofail.com> <575F1531.8080501@netassist.ua> Message-ID: On Mon, Jun 13, 2016 at 4:18 PM, Max Tulyev wrote: > But I can't figure out what SamKnows uses as the destination for tests? > As I understand the destination differs per measurement partnership, but in at least the United States a substantial portion of the infrastructure is provided by Measurement Lab, as a virtualized host within the broader set of tools that the platform supports. M-Lab also provides resources to a number of other quality of service and experience measurement tools, such as NDT, BISmark and Neubot. CIRA's initiative, noted earlier, also uses M-Lab and NDT, as do a few regulators in Europe and elsewhere. Please always feel free to reach out, we are always eager to collaborate with network operators to use our tools and extend our platform ? everything is open source and open access. Cordially, Collin -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From admin at marcoteixeira.com Mon Jun 13 20:51:09 2016 From: admin at marcoteixeira.com (Marco Teixeira) Date: Mon, 13 Jun 2016 21:51:09 +0100 Subject: Measuring the quality of Internet access In-Reply-To: <575F0573.1050406@netassist.ua> References: <575F0573.1050406@netassist.ua> Message-ID: <52DD453F-DD66-4E26-AAE2-D2CF25C1E513@marcoteixeira.com> Are you aware of https://atlas.ripe.net/ ? --- Enviado do um dispositivo com teclado reduzido. Sent from a device with a diminished keyboard. No dia 13/06/2016, ?s 20:11, Max Tulyev escreveu: > Hi All, > > I know there are many people from many countries. > > Do you know something about mandatory measurements of Internet access > quality from country telecom regulators? If yes, could you please share > that information with me? > > I found ETSI EG 202 057-4 standard > (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), > but in fact it is about measurements inside operator's network, not > Internet access itself. > > Is it possible in general to measure the quality of Internet access? And > if yes - how? From maxtul at netassist.ua Mon Jun 13 21:10:56 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 14 Jun 2016 00:10:56 +0300 Subject: Measuring the quality of Internet access In-Reply-To: <52DD453F-DD66-4E26-AAE2-D2CF25C1E513@marcoteixeira.com> References: <575F0573.1050406@netassist.ua> <52DD453F-DD66-4E26-AAE2-D2CF25C1E513@marcoteixeira.com> Message-ID: <575F2160.6000103@netassist.ua> Sure, even host some ;) But my question about govermental initiatives/regulations about it, if any. On 13.06.16 23:51, Marco Teixeira wrote: > Are you aware of https://atlas.ripe.net/ ? > > --- > Enviado do um dispositivo com teclado reduzido. > Sent from a device with a diminished keyboard. > > No dia 13/06/2016, ?s 20:11, Max Tulyev > escreveu: > >> Hi All, >> >> I know there are many people from many countries. >> >> Do you know something about mandatory measurements of Internet access >> quality from country telecom regulators? If yes, could you please share >> that information with me? >> >> I found ETSI EG 202 057-4 standard >> (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), >> but in fact it is about measurements inside operator's network, not >> Internet access itself. >> >> Is it possible in general to measure the quality of Internet access? And >> if yes - how? From nanog-post at rsuc.gweep.net Mon Jun 13 21:23:08 2016 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 13 Jun 2016 17:23:08 -0400 Subject: Measuring the quality of Internet access In-Reply-To: <96821.1465850332@turing-police.cc.vt.edu> References: <575F0573.1050406@netassist.ua> <96821.1465850332@turing-police.cc.vt.edu> Message-ID: <20160613212308.GA32247@gweep.net> On Mon, Jun 13, 2016 at 04:38:52PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 13 Jun 2016 22:11:47 +0300, Max Tulyev said: > > Is it possible in general to measure the quality of Internet access? And > > if yes - how? > > First, *define* "quality". Raw bandwidth to a test server? Raw bandwidth > to a weighted average of the Alexa Top 100? Does RTT/bufferbloat count? > What about RTT jitter? ...not to mention the definition of "Internet". Aside from well-known filters, see also https://ripe72.ripe.net/presentations/6-2016-05-23-connectivity.pdf and https://ripe72.ripe.net/archives/video/241/ Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From maxtul at netassist.ua Mon Jun 13 21:38:30 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 14 Jun 2016 00:38:30 +0300 Subject: Measuring the quality of Internet access In-Reply-To: <96821.1465850332@turing-police.cc.vt.edu> References: <575F0573.1050406@netassist.ua> <96821.1465850332@turing-police.cc.vt.edu> Message-ID: <575F27D6.1050202@netassist.ua> Well, that was MY question! =) What who where (goverment/regulators) define as the quality? On 13.06.16 23:38, Valdis.Kletnieks at vt.edu wrote: > On Mon, 13 Jun 2016 22:11:47 +0300, Max Tulyev said: >> Is it possible in general to measure the quality of Internet access? And >> if yes - how? > > First, *define* "quality". Raw bandwidth to a test server? Raw bandwidth > to a weighted average of the Alexa Top 100? Does RTT/bufferbloat count? > What about RTT jitter? > From maxtul at netassist.ua Mon Jun 13 21:41:22 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 14 Jun 2016 00:41:22 +0300 Subject: Measuring the quality of Internet access In-Reply-To: References: <575F0573.1050406@netassist.ua> <37bc1454faef47faab89c2e787b6fe31@zerofail.com> <575F1531.8080501@netassist.ua> Message-ID: <575F2882.9080208@netassist.ua> All results will be very depend of target choise, as we can understand. So that's the main point. On 13.06.16 23:58, Collin Anderson wrote: > > On Mon, Jun 13, 2016 at 4:18 PM, Max Tulyev > wrote: > > But I can't figure out what SamKnows uses as the destination for tests? > > > As I understand the destination differs per measurement partnership, but > in at least the United States a substantial portion of the > infrastructure is provided by Measurement Lab, as a virtualized host > within the broader set of tools that the platform supports. > > M-Lab also provides resources to a number of other quality of service > and experience measurement tools, such as NDT, BISmark and Neubot. > CIRA's initiative, noted earlier, also uses M-Lab and NDT, as do a few > regulators in Europe and elsewhere. > > Please always feel free to reach out, we are always eager to collaborate > with network operators to use our tools and extend our platform ? > everything is open source and open access. > > Cordially, > Collin > -- > *Collin David Anderson* > averysmallbird.com | @cda | Washington, D.C. From rafael at e2wsolutions.com Mon Jun 13 22:03:41 2016 From: rafael at e2wsolutions.com (Possamai Rafael) Date: Mon, 13 Jun 2016 17:03:41 -0500 Subject: Thinking Methodically about building a PoC In-Reply-To: <20160613152951.GA8504@bamboo.slabnet.com> References: <20160613152951.GA8504@bamboo.slabnet.com> Message-ID: hahaha, that's a good one, remember seeing it a long time ago, i saved it now. On Mon, Jun 13, 2016 at 10:29 AM, Hugo Slabbert wrote: > > On Mon 2016-Jun-13 08:52:41 -0500, Possamai Rafael via NANOG < > nanog at nanog.org> wrote: > > This may not be an answer very specific to your problem/question, but if >> you take a look at the following image, you will find a summary of what >> they called the engineering design methodology: >> >> >> http://www.cdn.sciencebuddies.org/Files/5083/9/2013-updated_engineering-method-steps_v6b.png >> > > Seriously thought initially that you were going to link to: > > > http://i2.wp.com/tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png > > You can adapt it to your circumstances, for example: instead of defining a >> problem in step 1, you can define a product, and after knowing what is >> expected from that product, you can then move to background research, etc. >> >> Hope that helps. >> >> >> Rafael >> >> > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > > >> >> On Sun, Jun 12, 2016 at 8:52 PM, Kasper Adel >> wrote: >> >> hi, >>> >>> I am asked to build a large lab/test it. I'm provided crazy scale numbers >>> for lots of technologies (L*VPN, IPv*, IGP*, All Tunnels flavors...etc). >>> >>> It took me a lot of time to build this lab, because when I got the >>> request/test plan handed over to me, I did not verify that these scaled >>> numbers are even possible, not to mention the combination. I assumed some >>> thought/research were done before. >>> >>> I'm trying to put together a list of the lessons learned, and the right >>> way >>> to do this for future reference, specially that this project was time >>> critical and I got beaten hard because I did not deliver on time. >>> >>> So my question is, in your extensive experience, what is the right >>> method/approach to this kind of task: >>> >>> 1) Get started immediately (MVP), things will break, tune it along the >>> way. >>> 2) Do some planning and research first. >>> >>> I'd appreciate any references to 'software engineering' or other >>> industries/ >>> >>> Thanks >>> >>> From theodore at ciscodude.net Mon Jun 13 22:32:52 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Mon, 13 Jun 2016 17:32:52 -0500 Subject: RPKI and offline routes Message-ID: <18D189BA-2EC6-4DE2-8ADB-DFFB8C3528EE@ciscodude.net> Can RPKI be used with routes that are not being advertised at the moment? As in to sign a route that *could* be there, but is not there presently. There's been several BGP hijacks that I've followed closely that involved hijacking IP space as well as the ASN that would normally originate it. I'm wondering if having valid ROAs/RPKI would have helped in this case or not. Theodore Baschak - AS395089 - Hextet Systems From m.waehlisch at fu-berlin.de Mon Jun 13 22:53:45 2016 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Mon, 13 Jun 2016 17:53:45 -0500 (Central Sommerzeit) Subject: RPKI and offline routes In-Reply-To: <18D189BA-2EC6-4DE2-8ADB-DFFB8C3528EE@ciscodude.net> References: <18D189BA-2EC6-4DE2-8ADB-DFFB8C3528EE@ciscodude.net> Message-ID: Hi, the creation of a ROA does not require the announcement of the prefix. Creation of a ROA, prefix announcement, and validation of the prefix are decoupled. If you are the legitimate resource holder you can create a ROA for this prefix (even if you don't advertise the prefix). As soon as the prefix is advertised, third parties can validate based on the created ROA. However, in case the hijacker is able to use the legitimate origin ASN, the validation outcome would be valid. You would need to assign the prefix to an ASN that cannot be hijacked or is dropped for other reasons. (Or do BGPsec. ;) Cheers matthias On Mon, 13 Jun 2016, Theodore Baschak wrote: > Can RPKI be used with routes that are not being advertised at the moment? > As in to sign a route that *could* be there, but is not there presently. > > There's been several BGP hijacks that I've followed closely that > involved hijacking IP space as well as the ASN that would normally > originate it. I'm wondering if having valid ROAs/RPKI would have > helped in this case or not. > > > Theodore Baschak - AS395089 - Hextet Systems > From morrowc.lists at gmail.com Tue Jun 14 02:41:56 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Jun 2016 22:41:56 -0400 Subject: Enough about Netflix banning HE tunnels [really: IPv6 adoption] In-Reply-To: <210561.1465590103@turing-police.cc.vt.edu> References: <208362.1465588528@turing-police.cc.vt.edu> <210561.1465590103@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 10, 2016 at 4:21 PM, wrote: > On Fri, 10 Jun 2016 20:12:43 -0000, "STARNES, CURTIS" said: > > and the Chromebook content filtering is not IPv6 compatible either > > So what are you using for content filtering? A quick google search > indicates that there do exist filtering solutions that are IPv6 > capable? > > ?aren't squid and 'url filtering software du-jour' ip agnostic?? ?or you know rpz zone content...? From diotonante at gmail.com Tue Jun 14 11:20:30 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 14 Jun 2016 13:20:30 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: <62285ddd-b85f-0723-8cc6-d0f6820864e3@heliacal.net> References: <20160605233527.7A8574AD2CFC@rock.dv.isc.org> <20160606234114.7A7904AE812D@rock.dv.isc.org> <32FC6E7F-12E8-4B11-8416-C31FFEE340DA@feld.me> <0A15922F-B537-43E4-A266-D1C2BF3D6E8F@delong.com> <62285ddd-b85f-0723-8cc6-d0f6820864e3@heliacal.net> Message-ID: <700314d6-b77d-ea9e-aa8d-beffbe60c4a0@gmail.com> On 08/06/2016 18:23, Laszlo Hanyecz wrote: > Well there is one good thing that might come out of this if you're a > tunnel user.. the tunnels can have even more bandwidth now, with all the > Netflix traffic moving off them. I have no special visibility into how > (over)loaded they are, just speculating. I used HE tunnels since 2009, I don't recall having any bandwidth problem that wasn't related to my local link. I never used super fast physical links either though. 10 Mbit/s, 20Mbit/s, 50/Mbit/s. I hardly had any issue to be perfectly honest with you, of any kind. Ciao, Davide Davini. From greg at gregsowell.com Mon Jun 13 19:24:24 2016 From: greg at gregsowell.com (Greg Sowell) Date: Mon, 13 Jun 2016 14:24:24 -0500 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: <4cf4a1790eda2263bb3bc288cefcffdc@mail.cmsws.com> References: <4cf4a1790eda2263bb3bc288cefcffdc@mail.cmsws.com> Message-ID: +1 for Zimbra On Sun, Jun 12, 2016 at 12:53 PM, Jim Lucas wrote: > June 8 2016 6:08 PM, "Eric Kuhnke" wrote: > > If you had to put up a public facing webmail interface for people to use, > > and maintain it for the foreseeable future (5-6 years), what would you > use? > > > > Roundcube? > > https://roundcube.net > > > > Rainloop? > > http://www.rainloop.net > > > > Something else? > > > > Requirements: > > Needs to be open souce and GPL, BSD or Apache licensed > > > > Email storage will be accessed via IMAP/TLS1.2 > > > > Runs on a Debian based platform with apache2 or nginx > > > > Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" > > size screens with Chrome and Safari > > I work for an ISP, and recently we were faced with the same dilemma. We > knew that our RoundCube was rather old and needed a facelift. We started > looking at new clients what I came across RainLoop. > > IMO RoundCube still doesn't have a decent working mobile theme. > > I went ahead and installed RainLoop on my personal server. Configuration > was a breeze. The interface is very nice. And the mobile layout is very > slick. > > I did come across a problem with displaying emails and when I emailed > their support email, they were very quick to respond. And within 24 hors > they were able to write a fix for my specific issue and build a new release > for me to download and test. > > I think that says something for their support team. > > Even if my office doesn't adopt RainLoop, I will continue using it on my > personal server for the forsee able future. > > -- > Jim Lucas > C - 5414085189 > H - 5413234219 > http://cmsws.com > -- GregSowell.com TheBrothersWISP.com From diotonante at gmail.com Tue Jun 14 15:28:02 2016 From: diotonante at gmail.com (Davide Davini) Date: Tue, 14 Jun 2016 17:28:02 +0200 Subject: Netflix VPN detection - actual engineer needed In-Reply-To: References: <92EF1B88-BD88-42A4-BF3A-3B3CE8E10718@delong.com> Message-ID: On 08/06/2016 18:17, Owen DeLong wrote: >>> Get your own /48 and advertise to HE Tunnel via BGP. Problem solved. >> >> Even though that sounds like an awesome idea it does not seem trivial to >> me to obtain your own /48. > > It?s trivial in the ARIN region. Other regions are YMMV. I thought you might have been thinking of ARIN. :) >> I mean: "You can only request IPv6 assignments and Autonomous System >> Numbers through a Sponsoring LIR (a RIPE NCC member)" >> https://www.ripe.net/manage-ips-and-asns/resource-management/number-resources/independent-resources > I would suggest trying to work through the RIPE PDWG to get that policy changed if you feel it is a hinderance to your deployment. > I do know that RIPE has this (rather silly IMHO) process for keeping PI end users at arms length, but as I understand it, it?s also not very hard to find an LIR that will charge you a fee to acquire the addresses and pass them along to you. I tend to agree, it is silly. >> But you know, my knowledge on the matter is half an hour old, I might be >> dead wrong. > > I think you?re right, but my understanding is that it is fairly trivial to comply with that requirement. I?ll be surprised if some LIRs don?t contact you as a result of this email. It didn't happen yet, but I might try to "poke" someone when I have some time to spare. Ciao, Davide Davini From matt at peterson.org Tue Jun 14 15:12:10 2016 From: matt at peterson.org (Matt Peterson) Date: Tue, 14 Jun 2016 10:12:10 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? Message-ID: This week at NANOG67, a presentation was given early on that did not reflect well for our community at large. Regardless of the content or accuracy of the data presented (not the intention of this thread), specific members of the community (some of which are sponsors) were clearly targeted in a hurtful manner. The delivery of the content did not seem within the spirit of NANOG, but instead a personal opinion piece. While no specific rules of the speaking guidelines were likely broken, this does bring up a point of where the acceptable threshold exists (if at all). To be abundantly clear - I have nothing against the content itself, the presenter, the PC's choice of allowing this talk, etc. - I only wish to clarify if our guidelines need modernization. As a community, how do we provide constructive criticism to industry suppliers (that may also be fellow competitors, members, and/or suppliers)? For example, router vendors are routinely compared without specific names mentioned (say in the case of a unpublished vulnerability) - how is a service provider any different? --Matt From hugo at slabnet.com Tue Jun 14 15:50:24 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 14 Jun 2016 08:50:24 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: Message-ID: <20160614155024.GB8504@bamboo.slabnet.com> On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson wrote: >This week at NANOG67, a presentation was given early on that did not >reflect well for our community at large. Regardless of the content or >accuracy of the data presented (not the intention of this thread), specific >members of the community (some of which are sponsors) were clearly targeted >in a hurtful manner. The delivery of the content did not seem within the >spirit of NANOG, but instead a personal opinion piece. While no specific >rules of the speaking guidelines > were likely >broken, this does bring up a point of where the acceptable threshold exists >(if at all). To be abundantly clear - I have nothing against the content >itself, the presenter, the PC's choice of allowing this talk, etc. - I only >wish to clarify if our guidelines need modernization. > >As a community, how do we provide constructive criticism to industry >suppliers (that may also be fellow competitors, members, and/or suppliers)? >For example, router vendors are routinely compared without specific names >mentioned (say in the case of a unpublished vulnerability) - how is a >service provider any different? I understand the discretion involved in your question, but could we clarify exactly what presentation is being discussed so those of us who were not present at NANOG67 can also participate in an informed way? >--Matt -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From patrick at ianai.net Tue Jun 14 15:53:52 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jun 2016 11:53:52 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160614155024.GB8504@bamboo.slabnet.com> References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Jun 14, 2016, at 11:50 AM, Hugo Slabbert wrote: > On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson wrote: > >> This week at NANOG67, a presentation was given early on that did not >> reflect well for our community at large. Regardless of the content or >> accuracy of the data presented (not the intention of this thread), specific >> members of the community (some of which are sponsors) were clearly targeted >> in a hurtful manner. The delivery of the content did not seem within the >> spirit of NANOG, but instead a personal opinion piece. While no specific >> rules of the speaking guidelines >> were likely >> broken, this does bring up a point of where the acceptable threshold exists >> (if at all). To be abundantly clear - I have nothing against the content >> itself, the presenter, the PC's choice of allowing this talk, etc. - I only >> wish to clarify if our guidelines need modernization. >> >> As a community, how do we provide constructive criticism to industry >> suppliers (that may also be fellow competitors, members, and/or suppliers)? >> For example, router vendors are routinely compared without specific names >> mentioned (say in the case of a unpublished vulnerability) - how is a >> service provider any different? > > I understand the discretion involved in your question, but could we clarify exactly what presentation is being discussed so those of us who were not present at NANOG67 can also participate in an informed way? I personally think the meta-question Matt asked is more important than opinions on a specific presentation. Plus I worry about devolving into a ?that was a good preso? / ?no it wasn?t!!? flamefest. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 872 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hugo at slabnet.com Tue Jun 14 15:57:45 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 14 Jun 2016 08:57:45 -0700 Subject: RPKI and offline routes In-Reply-To: References: <18D189BA-2EC6-4DE2-8ADB-DFFB8C3528EE@ciscodude.net> Message-ID: <20160614155745.GA8389@bamboo.slabnet.com> On Mon 2016-Jun-13 17:53:45 -0500, Matthias Waehlisch wrote: >Hi, > > the creation of a ROA does not require the announcement of the prefix. >Creation of a ROA, prefix announcement, and validation of the prefix are >decoupled. If you are the legitimate resource holder you can create a >ROA for this prefix (even if you don't advertise the prefix). As soon as >the prefix is advertised, third parties can validate based on the >created ROA. > > However, in case the hijacker is able to use the legitimate origin >ASN, the validation outcome would be valid. You would need to assign the >prefix to an ASN that cannot be hijacked or is dropped for other >reasons. (Or do BGPsec. ;) Would this not be a valid use case for creating an ROA with origin AS 0? RFC7607[1] Autonomous System 0 was listed in the IANA Autonomous System Number Registry as "Reserved - May be use [sic] to identify non-routed networks" ([IANA.AS_Numbers][2]). [RFC6491] specifies that AS 0 in a Route Origin Attestation (ROA) is used to mark a prefix and all its more specific prefixes as not to be used in a routing context. This allows a resource holder to signal that a prefix (and the more specifics) should not be routed by publishing a ROA listing AS 0 as the only origin. To respond to this signal requires that BGP implementations not accept or propagate routes containing AS 0. RFC6491[3] AS 0 ROA: A ROA containing a value of 0 in the ASID field. "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. With the most detail in RFC6483[4]. Yes/no? > > >Cheers > matthias -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal > >On Mon, 13 Jun 2016, Theodore Baschak wrote: > >> Can RPKI be used with routes that are not being advertised at the moment? >> As in to sign a route that *could* be there, but is not there presently. >> >> There's been several BGP hijacks that I've followed closely that >> involved hijacking IP space as well as the ASN that would normally >> originate it. I'm wondering if having valid ROAs/RPKI would have >> helped in this case or not. >> >> >> Theodore Baschak - AS395089 - Hextet Systems >> [1]https://tools.ietf.org/html/rfc7607#section-1 [2]https://tools.ietf.org/html/rfc7607#ref-IANA.AS_Numbers [3]https://tools.ietf.org/html/rfc6491#section-4 [4]https://tools.ietf.org/html/rfc6483#section-4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cb.list6 at gmail.com Tue Jun 14 16:08:58 2016 From: cb.list6 at gmail.com (Ca By) Date: Tue, 14 Jun 2016 09:08:58 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tuesday, June 14, 2016, Patrick W. Gilmore wrote: > On Jun 14, 2016, at 11:50 AM, Hugo Slabbert > wrote: > > On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson > wrote: > > > >> This week at NANOG67, a presentation was given early on that did not > >> reflect well for our community at large. Regardless of the content or > >> accuracy of the data presented (not the intention of this thread), > specific > >> members of the community (some of which are sponsors) were clearly > targeted > >> in a hurtful manner. The delivery of the content did not seem within the > >> spirit of NANOG, but instead a personal opinion piece. While no specific > >> rules of the speaking guidelines > >> were likely > >> broken, this does bring up a point of where the acceptable threshold > exists > >> (if at all). To be abundantly clear - I have nothing against the content > >> itself, the presenter, the PC's choice of allowing this talk, etc. - I > only > >> wish to clarify if our guidelines need modernization. > >> > >> As a community, how do we provide constructive criticism to industry > >> suppliers (that may also be fellow competitors, members, and/or > suppliers)? > >> For example, router vendors are routinely compared without specific > names > >> mentioned (say in the case of a unpublished vulnerability) - how is a > >> service provider any different? > > > > I understand the discretion involved in your question, but could we > clarify exactly what presentation is being discussed so those of us who > were not present at NANOG67 can also participate in an informed way? > > I personally think the meta-question Matt asked is more important than > opinions on a specific presentation. Plus I worry about devolving into a > ?that was a good preso? / ?no it wasn?t!!? flamefest. > > Harassment policy is a good idea https://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html Walking on eggshells because sponsors don't appreciate the message and find posting pictures of their dance parties while discussing non-profit financials is ... Or is that a different subtweet? We are talking about dnssec? To that end, let a million flowers bloom. It was a good relevant talk. Regards, C&J -- > TTFN, > patrick > > > From jcurran at arin.net Tue Jun 14 16:10:05 2016 From: jcurran at arin.net (John Curran) Date: Tue, 14 Jun 2016 16:10:05 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Jun 14, 2016, at 11:08 AM, Ca By > wrote: Harassment policy is a good idea https://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html Similar approach would be an explicit statement of expectations of participants - /John From dgolding at gmail.com Tue Jun 14 16:18:55 2016 From: dgolding at gmail.com (Daniel Golding) Date: Tue, 14 Jun 2016 16:18:55 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: I'd suggest that this is not an operation discussion and should be moved to the NANOG Membership list. I don't see any violation of the presentation guidelines. Also, the day we decide to censor ourselves to avoid offending vendors is the end of my involvement in NANOG - and I suspect that is the case for many others. Matt is being coy, for some reason. He didn't like Dave Temkin's talk about IXP costs. I listened very carefully and did not hear any specific members or people targeted - only organizations and companies. NANOG is not and has never been a "safe space" for sponsors or organizations that exist in the network space. It never should be. If LINX or AMSIX or anyone else didn't like what was said, they should have rocked the mic (which they did!) and they should come to the next NANOG and present a counterpoint. Daniel Golding (speaking in my personal capacity) On Tue, Jun 14, 2016 at 11:10 AM Ca By wrote: > On Tuesday, June 14, 2016, Patrick W. Gilmore wrote: > > > On Jun 14, 2016, at 11:50 AM, Hugo Slabbert > > wrote: > > > On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson > > wrote: > > > > > >> This week at NANOG67, a presentation was given early on that did not > > >> reflect well for our community at large. Regardless of the content or > > >> accuracy of the data presented (not the intention of this thread), > > specific > > >> members of the community (some of which are sponsors) were clearly > > targeted > > >> in a hurtful manner. The delivery of the content did not seem within > the > > >> spirit of NANOG, but instead a personal opinion piece. While no > specific > > >> rules of the speaking guidelines > > >> were likely > > >> broken, this does bring up a point of where the acceptable threshold > > exists > > >> (if at all). To be abundantly clear - I have nothing against the > content > > >> itself, the presenter, the PC's choice of allowing this talk, etc. - I > > only > > >> wish to clarify if our guidelines need modernization. > > >> > > >> As a community, how do we provide constructive criticism to industry > > >> suppliers (that may also be fellow competitors, members, and/or > > suppliers)? > > >> For example, router vendors are routinely compared without specific > > names > > >> mentioned (say in the case of a unpublished vulnerability) - how is a > > >> service provider any different? > > > > > > I understand the discretion involved in your question, but could we > > clarify exactly what presentation is being discussed so those of us who > > were not present at NANOG67 can also participate in an informed way? > > > > I personally think the meta-question Matt asked is more important than > > opinions on a specific presentation. Plus I worry about devolving into a > > ?that was a good preso? / ?no it wasn?t!!? flamefest. > > > > > Harassment policy is a good idea > > https://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html > > Walking on eggshells because sponsors don't appreciate the message and find > posting pictures of their dance parties while discussing > non-profit financials is ... Or is that a different subtweet? > > We are talking about dnssec? > > To that end, let a million flowers bloom. > > It was a good relevant talk. > > Regards, > C&J > > > -- > > TTFN, > > patrick > > > > > > > From dgolding at gmail.com Tue Jun 14 16:20:33 2016 From: dgolding at gmail.com (Daniel Golding) Date: Tue, 14 Jun 2016 16:20:33 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: John, We've had this for years. https://www.nanog.org/governance/attendance If you notice similarities - they are intentional. If you notice differences - NANOG has always had a higher threshold for a frank exchange of views between participants. We have no desire to stifle that. Dan On Tue, Jun 14, 2016 at 11:18 AM Daniel Golding wrote: > I'd suggest that this is not an operation discussion and should be moved > to the NANOG Membership list. > > I don't see any violation of the presentation guidelines. Also, the day we > decide to censor ourselves to avoid offending vendors is the end of my > involvement in NANOG - and I suspect that is the case for many others. > > Matt is being coy, for some reason. He didn't like Dave Temkin's talk > about IXP costs. I listened very carefully and did not hear any specific > members or people targeted - only organizations and companies. > > NANOG is not and has never been a "safe space" for sponsors or > organizations that exist in the network space. It never should be. If LINX > or AMSIX or anyone else didn't like what was said, they should have rocked > the mic (which they did!) and they should come to the next NANOG and > present a counterpoint. > > Daniel Golding > (speaking in my personal capacity) > > > > > On Tue, Jun 14, 2016 at 11:10 AM Ca By wrote: > >> On Tuesday, June 14, 2016, Patrick W. Gilmore wrote: >> >> > On Jun 14, 2016, at 11:50 AM, Hugo Slabbert > > > wrote: >> > > On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson > > > wrote: >> > > >> > >> This week at NANOG67, a presentation was given early on that did not >> > >> reflect well for our community at large. Regardless of the content or >> > >> accuracy of the data presented (not the intention of this thread), >> > specific >> > >> members of the community (some of which are sponsors) were clearly >> > targeted >> > >> in a hurtful manner. The delivery of the content did not seem within >> the >> > >> spirit of NANOG, but instead a personal opinion piece. While no >> specific >> > >> rules of the speaking guidelines >> > >> were likely >> > >> broken, this does bring up a point of where the acceptable threshold >> > exists >> > >> (if at all). To be abundantly clear - I have nothing against the >> content >> > >> itself, the presenter, the PC's choice of allowing this talk, etc. - >> I >> > only >> > >> wish to clarify if our guidelines need modernization. >> > >> >> > >> As a community, how do we provide constructive criticism to industry >> > >> suppliers (that may also be fellow competitors, members, and/or >> > suppliers)? >> > >> For example, router vendors are routinely compared without specific >> > names >> > >> mentioned (say in the case of a unpublished vulnerability) - how is a >> > >> service provider any different? >> > > >> > > I understand the discretion involved in your question, but could we >> > clarify exactly what presentation is being discussed so those of us who >> > were not present at NANOG67 can also participate in an informed way? >> > >> > I personally think the meta-question Matt asked is more important than >> > opinions on a specific presentation. Plus I worry about devolving into a >> > ?that was a good preso? / ?no it wasn?t!!? flamefest. >> > >> > >> Harassment policy is a good idea >> >> https://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html >> >> Walking on eggshells because sponsors don't appreciate the message and >> find >> posting pictures of their dance parties while discussing >> non-profit financials is ... Or is that a different subtweet? >> >> We are talking about dnssec? >> >> To that end, let a million flowers bloom. >> >> It was a good relevant talk. >> >> Regards, >> C&J >> >> >> -- >> > TTFN, >> > patrick >> > >> > >> > >> > From bill at herrin.us Tue Jun 14 16:25:28 2016 From: bill at herrin.us (William Herrin) Date: Tue, 14 Jun 2016 12:25:28 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tue, Jun 14, 2016 at 11:53 AM, Patrick W. Gilmore wrote: > On Jun 14, 2016, at 11:50 AM, Hugo Slabbert wrote: >> On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson wrote: >>> As a community, how do we provide constructive criticism to industry >>> suppliers (that may also be fellow competitors, members, and/or suppliers)? >>> For example, router vendors are routinely compared without specific names >>> mentioned (say in the case of a unpublished vulnerability) - how is a >>> service provider any different? >> >> I understand the discretion involved in your question, but could we clarify exactly what presentation is being discussed so those of us who were not present at NANOG67 can also participate in an informed way? > > I personally think the meta-question Matt asked is more important than opinions on a specific presentation. Plus I worry about devolving into a ?that was a good preso? / ?no it wasn?t!!? flamefest. Hello, A vague question can only yield a vague response. I have no clue what presentation you're talking about nor any idea why anyone should be upset about it. IMO, their are four tiers of meritorious criticism: 1. Privately, directly with the vendor 2. On the mailing list naming no names 3. On the mailing list, name and shame 4. A call to carpet at a meeting #1 is not always practical -- vendors make it increasingly hard to contact them as customers, let alone as non-customers. Tried to reach Google about a problem? Like, ever? #2 should happen before #3. If #2 hasn't happened yet, #3 is rude. #3 should happen before #4. If #3 hasn't happened yet, I think the program committee should encourage a presenter to open a discussion on the list first. If #2 and #3 have happened, I think it's entirely appropriate to publicly present the vendor's misbehavior and encourage the audience to speak at the mic about how the vendor's error is harming them. It's information the vendor needs to know to stay in business, it's information the rest of us need to know when evaluating the vendor, and in some cases its information the regulatory authorities need to know when considering consumer protection. That having been said, I see no reason why presentations naming a vendor should be allowed to surprise the vendor. If a presentation will name a particular vendor, that vendor should receive an advance draft so that their reps are prepared to speak at the mic about their intentions. Also, occurrences of #4 should be exactly as rare as persistent vendor misbehavior. Anyway, not a fan of dancing on eggshells. If something deserves to be said, it should be said. If we can't take a little honesty, we're in the wrong line of work. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From dgolding at gmail.com Tue Jun 14 16:30:11 2016 From: dgolding at gmail.com (Daniel Golding) Date: Tue, 14 Jun 2016 16:30:11 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: "If a presentation will name a particular vendor, that vendor should receive an advance draft so that their reps are prepared to speak at the mic about their intentions. " One of the least savory aspects of the technical press and industry analyst worlds is something called pre-pub review. That's where big vendors pay you to see stuff before its printed, so they can attempt to censor it. It happens all the time, and you never know about it. Sharing people's decks with vendors before they are presented might be a nice thing for the presenter to do, but its not appropriate for the NANOG organization. Dan On Tue, Jun 14, 2016 at 11:27 AM William Herrin wrote: > On Tue, Jun 14, 2016 at 11:53 AM, Patrick W. Gilmore > wrote: > > On Jun 14, 2016, at 11:50 AM, Hugo Slabbert wrote: > >> On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson > wrote: > >>> As a community, how do we provide constructive criticism to industry > >>> suppliers (that may also be fellow competitors, members, and/or > suppliers)? > >>> For example, router vendors are routinely compared without specific > names > >>> mentioned (say in the case of a unpublished vulnerability) - how is a > >>> service provider any different? > >> > >> I understand the discretion involved in your question, but could we > clarify exactly what presentation is being discussed so those of us who > were not present at NANOG67 can also participate in an informed way? > > > > I personally think the meta-question Matt asked is more important than > opinions on a specific presentation. Plus I worry about devolving into a > ?that was a good preso? / ?no it wasn?t!!? flamefest. > > Hello, > > A vague question can only yield a vague response. I have no clue what > presentation you're talking about nor any idea why anyone should be > upset about it. > > > IMO, their are four tiers of meritorious criticism: > > 1. Privately, directly with the vendor > 2. On the mailing list naming no names > 3. On the mailing list, name and shame > 4. A call to carpet at a meeting > > #1 is not always practical -- vendors make it increasingly hard to > contact them as customers, let alone as non-customers. Tried to reach > Google about a problem? Like, ever? > > #2 should happen before #3. If #2 hasn't happened yet, #3 is rude. > > #3 should happen before #4. If #3 hasn't happened yet, I think the > program committee should encourage a presenter to open a discussion on > the list first. > > If #2 and #3 have happened, I think it's entirely appropriate to > publicly present the vendor's misbehavior and encourage the audience > to speak at the mic about how the vendor's error is harming them. It's > information the vendor needs to know to stay in business, it's > information the rest of us need to know when evaluating the vendor, > and in some cases its information the regulatory authorities need to > know when considering consumer protection. > > That having been said, I see no reason why presentations naming a > vendor should be allowed to surprise the vendor. If a presentation > will name a particular vendor, that vendor should receive an advance > draft so that their reps are prepared to speak at the mic about their > intentions. Also, occurrences of #4 should be exactly as rare as > persistent vendor misbehavior. > > Anyway, not a fan of dancing on eggshells. If something deserves to be > said, it should be said. If we can't take a little honesty, we're in > the wrong line of work. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From rafael at e2wsolutions.com Tue Jun 14 16:32:07 2016 From: rafael at e2wsolutions.com (Possamai Rafael) Date: Tue, 14 Jun 2016 11:32:07 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: Message-ID: Were they truly targeted in a hurtful manner, or just reprimanded for doing something stupid? On Tue, Jun 14, 2016 at 10:12 AM, Matt Peterson wrote: > This week at NANOG67, a presentation was given early on that did not > reflect well for our community at large. Regardless of the content or > accuracy of the data presented (not the intention of this thread), specific > members of the community (some of which are sponsors) were clearly targeted > in a hurtful manner. The delivery of the content did not seem within the > spirit of NANOG, but instead a personal opinion piece. While no specific > rules of the speaking guidelines > were likely > broken, this does bring up a point of where the acceptable threshold exists > (if at all). To be abundantly clear - I have nothing against the content > itself, the presenter, the PC's choice of allowing this talk, etc. - I only > wish to clarify if our guidelines need modernization. > > As a community, how do we provide constructive criticism to industry > suppliers (that may also be fellow competitors, members, and/or suppliers)? > For example, router vendors are routinely compared without specific names > mentioned (say in the case of a unpublished vulnerability) - how is a > service provider any different? > > --Matt > From jcurran at istaff.org Tue Jun 14 16:33:12 2016 From: jcurran at istaff.org (John Curran) Date: Tue, 14 Jun 2016 11:33:12 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Jun 14, 2016, at 11:20 AM, Daniel Golding wrote: > > John, > > We've had this for years. https://www.nanog.org/governance/attendance > > If you notice similarities - they are intentional. > If you notice differences - NANOG has always had a higher threshold for a > frank exchange of views between participants. We have no desire to stifle > that. Makes perfect sense to me - thanks for the pointer! So, you?ve set expectations, and those include a clear reporting and enforcement process, so is discussion of the session in question (I actually have no idea which one it is ) on a mailing list really the right approach? Alternatively should folks who feel there was an issue just follow the reporting process? (rhetorical question) /John Disclaimer: my views alone. From patrick at ianai.net Tue Jun 14 16:43:10 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jun 2016 12:43:10 -0400 Subject: Appeals court upholds Network Neutrality rules Message-ID: <27001C33-A798-4CCA-9B03-466ADA8B5FBD@ianai.net> Presented without comment: https://www.washingtonpost.com/news/the-switch/wp/2016/06/14/the-fcc-just-won-a-sweeping-victory-on-net-neutrality-in-federal-court/ Seems topical to NANOG audience. -- TTFN, patrick From Bryan at bryanfields.net Tue Jun 14 16:56:02 2016 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 14 Jun 2016 12:56:02 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: <57603722.4000609@bryanfields.net> On 6/14/16 12:18 PM, Daniel Golding wrote: > I don't see any violation of the presentation guidelines. Also, the day we > decide to censor ourselves to avoid offending vendors is the end of my > involvement in NANOG - and I suspect that is the case for many others. > > Matt is being coy, for some reason. He didn't like Dave Temkin's talk about > IXP costs. I listened very carefully and did not hear any specific members > or people targeted - only organizations and companies. +1 I found some very good points in Dave's talk. I've seen these governance issues in other organizations I've been involved with. It's no different then when Marge got up and implored the Springfield City Council to use their money to pave Main St. and everyone else screamed Monorail! (doh!) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From matt at peterson.org Tue Jun 14 17:30:39 2016 From: matt at peterson.org (Matt Peterson) Date: Tue, 14 Jun 2016 12:30:39 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tue, Jun 14, 2016 at 11:18 AM, Daniel Golding wrote: > > > I don't see any violation of the presentation guidelines. Also, the day we > decide to censor ourselves to avoid offending vendors is the end of my > involvement in NANOG - and I suspect that is the case for many others. > Censorship is a strong word and one I would also not be in favor of too (in the generic sense). What is concerning is when bashing is framed as personal attack. A possible PC revision could have been 1) add more flavor of dominate US IXP's (of all organization structures) - as that geographical focus makes more sense for NANOG 2) don't list specific organizations by name, but instead just list their organization structure and a random identifier. > Matt is being coy, for some reason. He didn't like Dave Temkin's talk about > IXP costs. I listened very carefully and did not hear any specific members > or people targeted - only organizations and companies. > As noted earlier in the thread, the specific presentation isn't my interest here - I actually enjoyed the talk and agree with many of the points stated. What made me uncomfortable was peer IXP's feeling uncomfortable and even a college immersion participant asking "is NANOG always such a threatening environment?". Organizations and companies are members of our greater community, even if they don't technically have a membership role. At this morning's membership meeting - it was restated that NANOG is highly dependent on sponsorships (rarely do we see such financial contributions from individuals that would be enough to support NANOG). It would be a shame to loose that income source when only minor content guidelines could be made. > NANOG is not and has never been a "safe space" for sponsors or > organizations that exist in the network space. It never should be. If LINX > or AMSIX or anyone else didn't like what was said, they should have rocked > the mic (which they did!) and they should come to the next NANOG and > present a counterpoint. I'm sorry Dan, but this sort of "old boys network" attitude has gone on for way too long in NANOG. I've already received 13 off list responses "well said", "nicely done", "finally a reality check", etc. I'm not at all suggesting bashing should go away, as you note - that is a paramount feature of NANOG. Instead the question is when is it appropriate to shame members of the industry and how do we frame that in an professional manner (I realize you may have challenges in such a demonstration) . Clearly a disconnect exists between some members and some board / PC members. As a board member, it would be nice to see a commitment to improving this situation. Thank you. From randy at psg.com Tue Jun 14 17:36:01 2016 From: randy at psg.com (Randy Bush) Date: Wed, 15 Jun 2016 02:36:01 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: > I don't see any violation of the presentation guidelines. Also, the > day we decide to censor ourselves to avoid offending vendors is the > end of my involvement in NANOG - and I suspect that is the case for > many others. thanks for speaking up with a clear voice randy, who generally does not like to meee tooo From beckman at angryox.com Tue Jun 14 17:40:20 2016 From: beckman at angryox.com (Peter Beckman) Date: Tue, 14 Jun 2016 13:40:20 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tue, 14 Jun 2016, William Herrin wrote: > Anyway, not a fan of dancing on eggshells. If something deserves to be > said, it should be said. If we can't take a little honesty, we're in > the wrong line of work. Yes! Though the "Hey that was negative! Don't say negative things about me!" mentality is not specific to our industry, but the American culture. As I parent, I see this every day with children -- parents dealing with everything that could be considered unpleasant on behalf of their child, and blaming others (teachers, other kids, other parents, solar flares) rather than taking on personal ownership of sometimes negative and complicated issues. Negative feedback, respectfully and objectively delivered, should be embraced as opportunities to improve ourselves, our products and our services, not shunned and silenced because it points out a flaw. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From dgolding at gmail.com Tue Jun 14 17:40:18 2016 From: dgolding at gmail.com (Daniel Golding) Date: Tue, 14 Jun 2016 17:40:18 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: Matt, I find it ironic that someone with such an objection to personal attacks would throw out one like this: *"I'm sorry Dan, but this sort of "old boys network" attitude has gone on for way too long in NANOG. As a board member, it would be nice to see a commitment to improving this situation. Thank you."* Luckily, I'm ok without a safe space. ;) Clearly this is a decision for the PC - the Board doesn't decide this stuff, as I think you know. But in my personal capacity, I'm against censoring presentation to please vendors or sponsors: No special pleadings because you give money to NANOG. Yeah, censoring is a strong word. That's because its a bad thing. Dan On Tue, Jun 14, 2016 at 12:30 PM Matt Peterson wrote: > On Tue, Jun 14, 2016 at 11:18 AM, Daniel Golding > wrote: >> >> >> I don't see any violation of the presentation guidelines. Also, the day we >> decide to censor ourselves to avoid offending vendors is the end of my >> involvement in NANOG - and I suspect that is the case for many others. >> > > Censorship is a strong word and one I would also not be in favor of too > (in the generic sense). What is concerning is when bashing is framed as > personal attack. A possible PC revision could have been 1) add more flavor > of dominate US IXP's (of all organization structures) - as that > geographical focus makes more sense for NANOG 2) don't list specific > organizations by name, but instead just list their organization structure > and a random identifier. > > >> Matt is being coy, for some reason. He didn't like Dave Temkin's talk >> about >> IXP costs. I listened very carefully and did not hear any specific members >> or people targeted - only organizations and companies. >> > > As noted earlier in the thread, the specific presentation isn't my > interest here - I actually enjoyed the talk and agree with many of the > points stated. What made me uncomfortable was peer IXP's feeling > uncomfortable and even a college immersion participant asking "is NANOG > always such a threatening environment?". > > Organizations and companies are members of our greater community, even if > they don't technically have a membership role. At this morning's membership > meeting - it was restated that NANOG is highly dependent on sponsorships > (rarely do we see such financial contributions from individuals that would > be enough to support NANOG). It would be a shame to loose that income > source when only minor content guidelines could be made. > > >> NANOG is not and has never been a "safe space" for sponsors or >> organizations that exist in the network space. It never should be. If LINX >> or AMSIX or anyone else didn't like what was said, they should have rocked >> the mic (which they did!) and they should come to the next NANOG and >> present a counterpoint. > > > I'm sorry Dan, but this sort of "old boys network" attitude has gone on > for way too long in NANOG. I've already received 13 off list responses > "well said", "nicely done", "finally a reality check", etc. I'm not at all > suggesting bashing should go away, as you note - that is a paramount > feature of NANOG. Instead the question is when is it appropriate to shame > members of the industry and how do we frame that in an professional manner > (I realize you may have challenges in such a demonstration) . > > Clearly a disconnect exists between some members and some board / PC > members. As a board member, it would be nice to see a commitment to > improving this situation. Thank you. > From randy at psg.com Tue Jun 14 17:49:28 2016 From: randy at psg.com (Randy Bush) Date: Wed, 15 Jun 2016 02:49:28 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: > A possible PC revision could have been 1) add more flavor of dominate > US IXP's (of all organization structures) - as that geographical focus > makes more sense for NANOG 2) don't list specific organizations by > name, but instead just list their organization structure and a random > identifier. < rant > pablum nog. you are pandering to vendors to keep attendee costs down so you can have a high attendee count most of whom are sales folk. what can possibly go wrong? the pc be should have at least two talks including the unvarnished truth about specific named vendors, and at least one talk must be about a 'sponsor', whatever the hell that is and why it is needed. different ones every time, it is a target rich environment. the O in nanog is operator, not sponsor, panderer, suck up, ... we're spending millions for half debugged underperforming crap and we are cornered by infrastructure providers (e.g. ixps) who run us over time and again if it makes an extra penny. if you tell the vendors the truth, the real vendor engineers can go home and explain why they need management support to fix things. the truth makes us all free. randy From guillaume at ironie.org Tue Jun 14 17:50:12 2016 From: guillaume at ironie.org (Guillaume Tournat) Date: Tue, 14 Jun 2016 19:50:12 +0200 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: References: <4cf4a1790eda2263bb3bc288cefcffdc@mail.cmsws.com> Message-ID: <76D8AAB9-03DA-4E70-A943-D3C110E2DCD3@ironie.org> Zimbra is a full featured groupware server. I don't think you can just use the webmail part with existing IMAP server. So it doesn't fulfill requirements stated by initial poster. > Le 13 juin 2016 ? 21:24, Greg Sowell a ?crit : > > +1 for Zimbra > >> On Sun, Jun 12, 2016 at 12:53 PM, Jim Lucas wrote: >> >> June 8 2016 6:08 PM, "Eric Kuhnke" wrote: >>> If you had to put up a public facing webmail interface for people to use, >>> and maintain it for the foreseeable future (5-6 years), what would you >> use? >>> >>> Roundcube? >>> https://roundcube.net >>> >>> Rainloop? >>> http://www.rainloop.net >>> >>> Something else? >>> >>> Requirements: >>> Needs to be open souce and GPL, BSD or Apache licensed >>> >>> Email storage will be accessed via IMAP/TLS1.2 >>> >>> Runs on a Debian based platform with apache2 or nginx >>> >>> Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" >>> size screens with Chrome and Safari >> >> I work for an ISP, and recently we were faced with the same dilemma. We >> knew that our RoundCube was rather old and needed a facelift. We started >> looking at new clients what I came across RainLoop. >> >> IMO RoundCube still doesn't have a decent working mobile theme. >> >> I went ahead and installed RainLoop on my personal server. Configuration >> was a breeze. The interface is very nice. And the mobile layout is very >> slick. >> >> I did come across a problem with displaying emails and when I emailed >> their support email, they were very quick to respond. And within 24 hors >> they were able to write a fix for my specific issue and build a new release >> for me to download and test. >> >> I think that says something for their support team. >> >> Even if my office doesn't adopt RainLoop, I will continue using it on my >> personal server for the forsee able future. >> >> -- >> Jim Lucas >> C - 5414085189 >> H - 5413234219 >> http://cmsws.com > > > > -- > > GregSowell.com > TheBrothersWISP.com From Bryan at bryanfields.net Tue Jun 14 18:12:55 2016 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 14 Jun 2016 14:12:55 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: <57604927.3080705@bryanfields.net> On 6/14/16 1:30 PM, Matt Peterson wrote: > On Tue, Jun 14, 2016 at 11:18 AM, Daniel Golding wrote: >> Matt is being coy, for some reason. He didn't like Dave Temkin's talk about >> IXP costs. I listened very carefully and did not hear any specific members >> or people targeted - only organizations and companies. >> > > As noted earlier in the thread, the specific presentation isn't my interest > here - I actually enjoyed the talk and agree with many of the points > stated. What made me uncomfortable was peer IXP's feeling uncomfortable and > even a college immersion participant asking "is NANOG always such a > threatening environment?". Nothing was threatening, it was debate. Sometimes debate is heated, but that was not even heated debate. If you were offended, grow a thicker skin. You don't have a right against offense and much thought provoking discussion can be offensive to some people. I thought it was great to see some back and forth. To the college student, this was debate in it's purist form. There are no "free speech zones" here. > Organizations and companies are members of our greater community, even if > they don't technically have a membership role. At this morning's membership > meeting - it was restated that NANOG is highly dependent on sponsorships > (rarely do we see such financial contributions from individuals that would > be enough to support NANOG). It would be a shame to loose that income > source when only minor content guidelines could be made. I'd rather lose a sponsorship than restrict our debate. Censorship is evil, prior restraint is just as bad. > I'm sorry Dan, but this sort of "old boys network" attitude has gone on for > way too long in NANOG. I've already received 13 off list responses "well > said", "nicely done", "finally a reality check", etc. I'm not at all > suggesting bashing should go away, as you note - that is a paramount > feature of NANOG. Instead the question is when is it appropriate to shame > members of the industry and how do we frame that in an professional manner > (I realize you may have challenges in such a demonstration) . Oh come on, it was a small ribbing at worst. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From m.waehlisch at fu-berlin.de Tue Jun 14 18:39:19 2016 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Tue, 14 Jun 2016 13:39:19 -0500 (Central Sommerzeit) Subject: RPKI and offline routes In-Reply-To: <20160614155745.GA8389@bamboo.slabnet.com> References: <18D189BA-2EC6-4DE2-8ADB-DFFB8C3528EE@ciscodude.net> <20160614155745.GA8389@bamboo.slabnet.com> Message-ID: Hi, yes. In this context the discussion at IETF92 might be interesting: https://www.ietf.org/proceedings/92/minutes/minutes-92-sidr (search for "Extemporaneous Presentation") Cheers matthias On Tue, 14 Jun 2016, Hugo Slabbert wrote: > > On Mon 2016-Jun-13 17:53:45 -0500, Matthias Waehlisch > wrote: > > > Hi, > > > > the creation of a ROA does not require the announcement of the prefix. > > Creation of a ROA, prefix announcement, and validation of the prefix are > > decoupled. If you are the legitimate resource holder you can create a > > ROA for this prefix (even if you don't advertise the prefix). As soon as > > the prefix is advertised, third parties can validate based on the > > created ROA. > > > > However, in case the hijacker is able to use the legitimate origin > > ASN, the validation outcome would be valid. You would need to assign the > > prefix to an ASN that cannot be hijacked or is dropped for other > > reasons. (Or do BGPsec. ;) > > Would this not be a valid use case for creating an ROA with origin AS 0? > > RFC7607[1] > > Autonomous System 0 was listed in the IANA Autonomous System Number > Registry as "Reserved - May be use [sic] to identify non-routed > networks" ([IANA.AS_Numbers][2]). > > [RFC6491] specifies that AS 0 in a Route Origin Attestation (ROA) is > used to mark a prefix and all its more specific prefixes as not to be > used in a routing context. This allows a resource holder to signal > that a prefix (and the more specifics) should not be routed by > publishing a ROA listing AS 0 as the only origin. To respond to this > signal requires that BGP implementations not accept or propagate > routes containing AS 0. > > RFC6491[3] > > AS 0 ROA: A ROA containing a value of 0 in the ASID field. > "Validation of Route Origination Using the Resource Certificate > Public Key Infrastructure (PKI) and Route Origination Authorizations > (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is > an attestation by the holder of a prefix that the prefix described in > the ROA, and any more specific prefix, should not be used in a > routing context. > > With the most detail in RFC6483[4]. > > Yes/no? > > > > > > > Cheers > > matthias > > From jfbeam at gmail.com Tue Jun 14 18:57:40 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 14 Jun 2016 14:57:40 -0400 Subject: Netflix banning HE tunnels In-Reply-To: <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> Message-ID: On Sun, 12 Jun 2016 19:47:18 -0400, Owen DeLong wrote: >> NAT may not be security, yet it's the only thing securing billions of >> people. > > Nope? NAT Can?t be done without stateful inspection. Negative. - 1:1 NAT (inside address A == outside address B) requires no state of any kind. - Connection Tracking is not stateful inspection - NAT Helpers / ALG / etc. (things that look for embedded addresses) aren't "stateful inspection" The only "security" one gets from NAT comes from the lack of outside visibility through the NAT. An outside host cannot initiate a connection to any specific inside host of their choosing. I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 traffic. IPv4 goes through NAT, so one gets the pseudo-security of not being directly touchable from the internet. From Valdis.Kletnieks at vt.edu Tue Jun 14 19:34:37 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jun 2016 15:34:37 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> Message-ID: <27713.1465932877@turing-police.cc.vt.edu> On Tue, 14 Jun 2016 14:57:40 -0400, "Ricky Beam" said: > I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 > traffic. IPv4 goes through NAT, so one gets the pseudo-security of not > being directly touchable from the internet. And a very big *PSEUDO* on that. It's amazing how many vendor firmwares suck so bad that it's no challenge to pwn the CPE and then leapfrog from there.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From swmike at swm.pp.se Tue Jun 14 19:38:58 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 14 Jun 2016 21:38:58 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: Message-ID: On Tue, 14 Jun 2016, Matt Peterson wrote: > As a community, how do we provide constructive criticism to industry > suppliers (that may also be fellow competitors, members, and/or > suppliers)? For example, router vendors are routinely compared without > specific names mentioned (say in the case of a unpublished > vulnerability) - how is a service provider any different? I think we should have the discussion in a constructive manner. What do we want the IXPs to do? What do we want the RIRs to do? What do we want the ccTLDs to do? What do we want IANA, ISOC, IETF etc to do? Right now they're doing things that they see as "good for the community", and not only spending money on producing their own service. They do outreach because not everybody knows about every service available. They hire community members and send them to conferences (IGF for instance) to try to achieve that governments hear from us. They spend money on research. They might spend money on acilliary services such as root/ccTLD name servers or NTP servers on the IXP. When asking community what should be done, a wide range of different answers are given. I don't have a problem having this discussion. I don't see it as "vendor bashing" but instead as someone who has an opinion on how things are done today. Question is, how can it be had in a constructive manner? -- Mikael Abrahamsson email: swmike at swm.pp.se From pauldotwall at gmail.com Tue Jun 14 20:08:47 2016 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 14 Jun 2016 16:08:47 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tue, Jun 14, 2016 at 1:49 PM, Randy Bush wrote: > the O in nanog is operator, not sponsor, panderer, suck up, ... Ogre? Drive slow, Paul From stefan at kaltenbrunner.cc Tue Jun 14 19:54:20 2016 From: stefan at kaltenbrunner.cc (Stefan Kaltenbrunner) Date: Tue, 14 Jun 2016 21:54:20 +0200 Subject: Measuring the quality of Internet access In-Reply-To: <575F0573.1050406@netassist.ua> References: <575F0573.1050406@netassist.ua> Message-ID: <576060EC.4080503@kaltenbrunner.cc> On 06/13/2016 09:11 PM, Max Tulyev wrote: > Hi All, > > I know there are many people from many countries. > > Do you know something about mandatory measurements of Internet access > quality from country telecom regulators? If yes, could you please share > that information with me? austria does something like this: https://www.rtr.at/en/tk/netztesthilfe includes a lot of information and even sourcecode on the measurement apps... Stefan From jheitz at cisco.com Tue Jun 14 20:19:37 2016 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 14 Jun 2016 20:19:37 +0000 Subject: RPKI and offline routes Message-ID: <68b6825f781f4fa5be01da6b200e6362@XCH-ALN-014.cisco.com> ASN 0 is used for this purpose. Look for the word "zero" in https://tools.ietf.org/html/rfc6907 Thanks, Jakob. > Date: Mon, 13 Jun 2016 17:53:45 -0500 (Central Sommerzeit) > From: Matthias Waehlisch > To: Theodore Baschak > Cc: NANOG Operators' Group > Subject: Re: RPKI and offline routes > > Hi, > > the creation of a ROA does not require the announcement of the prefix. > Creation of a ROA, prefix announcement, and validation of the prefix are > decoupled. If you are the legitimate resource holder you can create a > ROA for this prefix (even if you don't advertise the prefix). As soon as > the prefix is advertised, third parties can validate based on the > created ROA. > > However, in case the hijacker is able to use the legitimate origin > ASN, the validation outcome would be valid. You would need to assign the > prefix to an ASN that cannot be hijacked or is dropped for other > reasons. (Or do BGPsec. ;) > > > Cheers > matthias > > On Mon, 13 Jun 2016, Theodore Baschak wrote: > > > Can RPKI be used with routes that are not being advertised at the moment? > > As in to sign a route that *could* be there, but is not there presently. > > > > There's been several BGP hijacks that I've followed closely that > > involved hijacking IP space as well as the ASN that would normally > > originate it. I'm wondering if having valid ROAs/RPKI would have > > helped in this case or not. > > > > > > Theodore Baschak - AS395089 - Hextet Systems > > From jared at puck.nether.net Tue Jun 14 20:20:19 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Jun 2016 16:20:19 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: Message-ID: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> > On Jun 14, 2016, at 11:12 AM, Matt Peterson wrote: > > This week at NANOG67, a presentation was given early on that did not > reflect well for our community at large. I think that the data presented was interesting but the style of the presenter and tone could have been different. It seemed to be a variant of ?The Rent is Too Damn High?[1] while it can be interesting, there wasn?t a complete talk there IMHO. The feedback mechanism for this is honestly the survey[2]. I?m confident that the PC will take this input seriously and work with presenters in this regard. The IXP cost sheet[3] that is being maintained by Job I think gives an idea of the peering vs transit costs assuming various bitrates and list prices. The fates of IXPs and their roles will naturally resolve itself through market economics I suspect. - Jared - snip - links - snip - 1 - https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party 2 - https://www.nanog.org/meetings/nanog67/survey 3 - https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 From rsk at gsp.org Tue Jun 14 20:29:14 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 14 Jun 2016 16:29:14 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: <20160614202914.GA17790@gsp.org> On Tue, Jun 14, 2016 at 01:40:20PM -0400, Peter Beckman wrote: > Negative feedback, respectfully and objectively delivered, should be > embraced as opportunities to improve ourselves, our products and our > services, not shunned and silenced because it points out a flaw. 1. This. A hundred times this. 2. This is why we have RFC 2142 (which specifies role addresses such as postmaster@, abuse@, and so on): so that we can easily and quickly tell each other when we're screwing up so that it can be fixed. This is why all professional and responsible operations maintain those addresses, pay attention to what shows up there, read it, analyze it, act on it, and respond to it. This is and has been an instrinic part of our operational culture for decades -- even though we all know that just about every message ever received via them will be negative. (Because nobody's going to drop a line to hostmaster@ noting that our DNS servers are all working perfectly.) A critical presentation is really no different than an email message to webmaster@ that points out a 404'd URL. It's an opportunity to fix something and to do better. ---rsk From paras at protrafsolutions.com Tue Jun 14 20:51:36 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Tue, 14 Jun 2016 16:51:36 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160614202914.GA17790@gsp.org> References: <20160614155024.GB8504@bamboo.slabnet.com> <20160614202914.GA17790@gsp.org> Message-ID: The world of networking is in itself decentralized. In the event a certain network starts behaving badly, other networks will take appropriate action by themselves if they see it as a problem. I see no need to become a nanny state over issues like this. If someone is being belligerent and harming people, that's a different story. But criticism is criticism, and a sharp tongue isn't reason enough to try to censor viewpoints. Individuals who see it as a problem are more than free to take action to protect themselves (read: stop listening to them). On Tue, Jun 14, 2016 at 4:29 PM, Rich Kulawiec wrote: > On Tue, Jun 14, 2016 at 01:40:20PM -0400, Peter Beckman wrote: > > Negative feedback, respectfully and objectively delivered, should be > > embraced as opportunities to improve ourselves, our products and our > > services, not shunned and silenced because it points out a flaw. > > 1. This. A hundred times this. > > 2. This is why we have RFC 2142 (which specifies role addresses > such as postmaster@, abuse@, and so on): so that we can easily and > quickly tell each other when we're screwing up so that it can be fixed. > This is why all professional and responsible operations maintain those > addresses, pay attention to what shows up there, read it, analyze it, > act on it, and respond to it. This is and has been an instrinic part > of our operational culture for decades -- even though we all know > that just about every message ever received via them will be negative. > (Because nobody's going to drop a line to hostmaster@ noting that our > DNS servers are all working perfectly.) > > A critical presentation is really no different than an email message > to webmaster@ that points out a 404'd URL. It's an opportunity to > fix something and to do better. > > ---rsk > -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation From bill at herrin.us Tue Jun 14 21:05:19 2016 From: bill at herrin.us (William Herrin) Date: Tue, 14 Jun 2016 17:05:19 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On Tue, Jun 14, 2016 at 12:30 PM, Daniel Golding wrote: >> "If a presentation will name a particular vendor, that vendor should receive >> an advance >> draft so that their reps are prepared to speak at the mic about their >> intentions. " > > One of the least savory aspects of the technical press and industry analyst > worlds is something called pre-pub review. That's where big vendors pay you > to see stuff before its printed, so they can attempt to censor it. It > happens all the time, and you never know about it. Hi Daniel, That's quite a bit further than anything I suggested. My notion was that after the presentation has been accepted, the mentioned vendors receive a copy... not so they can attempt to squelch it but so that they can respond when the presentation is given. Besides, which among you would dare try to squelch a NANOG presentation? Y'all are well familiar with the Streisand Effect. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Tue Jun 14 21:38:40 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2016 14:38:40 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <57603722.4000609@bryanfields.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: So I just watched the video of Dave?s talk. While my overall impression is that it?s 51 minutes of my life that I?d rather have back and I don?t agree with several of his conclusions, I don?t see anything inherently wrong or hurtful about it. I don?t think it painted anyone in a bad light beyond fair criticism. He was clear about what was his opinion and what wasn?t. I do think he?s flat out wrong in his belief about marketing budgets of regulated utilities. I know for a fact, that PG&E spends tons of money on marketing. Sure, they aren?t sponsoring coffee bars at NANOG, that?s not their target market. Neither are the IXPs running television ads (at least none that I know of) since that?s not their target market. PG&E does do lots of TV ads, billboards, and other consumer-oriented marketing. I?m sure if you were to attend electrical industry trade shows, you?d find they have a presence there as well, though I have no idea, it?s not my industry. I do think we could all benefit from more cost-effective ISPs and I do think that models like MICE, SIX, and SFMIX are better for most of their participants than the ultra-expensive premium exchanges with branch offices in all the major markets. However, I suspect that in the long run, market demand will actually sort that out. Owen From owen at delong.com Tue Jun 14 21:48:51 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2016 14:48:51 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: > On Jun 14, 2016, at 14:05 , William Herrin wrote: > > On Tue, Jun 14, 2016 at 12:30 PM, Daniel Golding wrote: >>> "If a presentation will name a particular vendor, that vendor should receive >>> an advance >>> draft so that their reps are prepared to speak at the mic about their >>> intentions. " >> >> One of the least savory aspects of the technical press and industry analyst >> worlds is something called pre-pub review. That's where big vendors pay you >> to see stuff before its printed, so they can attempt to censor it. It >> happens all the time, and you never know about it. > > Hi Daniel, > > That's quite a bit further than anything I suggested. My notion was > that after the presentation has been accepted, the mentioned vendors > receive a copy... not so they can attempt to squelch it but so that > they can respond when the presentation is given. Here?s the problem with your theory, William? Once you hand it to the vendors, you lose any semblance of control over how they use it. Indeed, you?d like to hand it to them for that purpose, but once you do, nothing prevents them from the actions described by Daniel. Indeed, this tradition in the print press began with exactly the kind of fair-minded idea of which you speak. Nonetheless, commercial interests drove it off the rails into exactly the dark and twisted kind of thing that Daniel describes. Such is the nature of commerce. > Besides, which among you would dare try to squelch a NANOG > presentation? Y'all are well familiar with the Streisand Effect. Well? Some $LARGE_ORGANIZATIONS seem to either not know, don?t learn, or don?t care. Hard to tell which. For example, there?s a certain industry that has gone through the following progression: 1. The FCC put forth very light-handed almost voluntary regulations on net neutrality. 2. They sued the FCC claiming it had no such authority. 3. The FCC put forth a slightly heavier-handed regulation. 4. They sued the FCC claiming it had no such authority. 5. The FCC issued a ruling entirely within its authority which was quite a bit more heavy-handed. It was the only tool left in the tool box once the lighter approaches were ruled invalid. 6. They complained that the regulation was ?too heavy-handed?. 7. They sued the FCC claiming it had no such authority. 8. A federal appeals court just upheld the FCC 2:1. 9. They say they want to take it to the supreme court. The bottom line, when there?s enough money on the line, some organizations with a vested interest will do anything and everything they can to protect their ability to obtain that money. Helping them is optional. Helping them by trying to be nice is naive. Owen From owen at delong.com Tue Jun 14 21:54:13 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2016 14:54:13 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e2601d1c1ad$9b27b9f0$d1772dd0$@tndh.net> <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> Message-ID: <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> > On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > > On Sun, 12 Jun 2016 19:47:18 -0400, Owen DeLong wrote: >>> NAT may not be security, yet it's the only thing securing billions of people. >> >> Nope? NAT Can?t be done without stateful inspection. > > Negative. > - 1:1 NAT (inside address A == outside address B) requires no state of any kind. Sigh? This is not the kind of NAT we are talking about here. We are talking about address multiplexing NAT. 1:1 NAT provides no security whatsoever, either. > - Connection Tracking is not stateful inspection Yes, actually, it is a form of stateful inspection. > - NAT Helpers / ALG / etc. (things that look for embedded addresses) aren't "stateful inspection? Yes, actually, they are part of the more general category of stateful inspection. > The only "security" one gets from NAT comes from the lack of outside visibility through the NAT. An outside host cannot initiate a connection to any specific inside host of their choosing. If you are doing 1:1 NAT without stateful inspection, you don?t get this. > I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 traffic. IPv4 goes through NAT, so one gets the pseudo-security of not being directly touchable from the internet. Those are by definition poorly designed CPE. We used (and arguably still do) have lots of poorly designed IPv4 CPE, too. Blaming the protocol for bad CPE design is kind of silly. Each and every one of those CPEs you describe _IS_ doing some form of stateful inspection of the packet in order to be able to perform its translation function or drop the unrelated packet. An open 1:1 NAT with no stateful inspection is no more secure than a direct route. Changing the packet header doesn?t make you any less reachable. In fact, it further proves my point that no security comes from the NAT itself, but, rather from the validation of inbound packets as to whether they match an existing outbound session or not. That validation, however it is done, _IS_ stateful inspection. Without it, you?ve offered no security advantage and prevented no reachability. Owen From kraig at enguity.com Tue Jun 14 22:34:14 2016 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 14 Jun 2016 18:34:14 -0400 Subject: Verizon Wireless 4G Voice/Data Message-ID: Looks like Verizon Wireless 4G voice, intermittent data services and some 3g voices services are currently non-functional, specifically in the SE, however, seeing reports nationwide as well. -- From rwfireguru at gmail.com Tue Jun 14 22:45:38 2016 From: rwfireguru at gmail.com (Robert Webb) Date: Tue, 14 Jun 2016 18:45:38 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: Message-ID: Seeing no issues in WV. Speeds are 50/10. On Jun 14, 2016 6:35 PM, "Kraig Beahn" wrote: > Looks like Verizon Wireless 4G voice, intermittent data services and some > 3g voices services are currently non-functional, specifically in the SE, > however, seeing reports nationwide as well. > > > -- > From josh at imaginenetworksllc.com Tue Jun 14 22:51:36 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 14 Jun 2016 18:51:36 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: Message-ID: 25/8 in Troy. Phone works. I am using the "advanced calling" not sure what it is though. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 14, 2016 6:45 PM, "Robert Webb" wrote: > Seeing no issues in WV. Speeds are 50/10. > On Jun 14, 2016 6:35 PM, "Kraig Beahn" wrote: > > > Looks like Verizon Wireless 4G voice, intermittent data services and some > > 3g voices services are currently non-functional, specifically in the SE, > > however, seeing reports nationwide as well. > > > > > > -- > > > From mfidelman at meetinghouse.net Tue Jun 14 23:03:18 2016 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 14 Jun 2016 19:03:18 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: Message-ID: <53d150f9-50f1-e37d-f763-d29a07ddb0a5@meetinghouse.net> No problems in Newton, MA (Boston suburb). 43/5. Miles Fidelman On 6/14/16 6:51 PM, Josh Luthman wrote: > 25/8 in Troy. Phone works. I am using the "advanced calling" not sure > what it is though. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 14, 2016 6:45 PM, "Robert Webb" wrote: > >> Seeing no issues in WV. Speeds are 50/10. >> On Jun 14, 2016 6:35 PM, "Kraig Beahn" wrote: >> >>> Looks like Verizon Wireless 4G voice, intermittent data services and some >>> 3g voices services are currently non-functional, specifically in the SE, >>> however, seeing reports nationwide as well. >>> >>> >>> -- >>> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From alex.buie at frozenfeline.net Tue Jun 14 23:13:45 2016 From: alex.buie at frozenfeline.net (Alex Buie) Date: Tue, 14 Jun 2016 19:13:45 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: Message-ID: Large scale outage in FL, primarily affecting customers who have Advanced Calling (VoLTE) turned on and calling CDMA/PSTN destinations. However it appears there are many areas whose data connectivity is also affected. Will pass along any updates I can. Over 2k calls in the Tech Support queue right now, wish me luck! Time to jump into the sharks. Haha. Alex (VZW tech) All statements and opinions are my own and do not reflect that of Verizon Wireless or its subsidiaries. On Jun 14, 2016 6:35 PM, "Kraig Beahn" wrote: Looks like Verizon Wireless 4G voice, intermittent data services and some 3g voices services are currently non-functional, specifically in the SE, however, seeing reports nationwide as well. -- From kraig at enguity.com Tue Jun 14 23:32:48 2016 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 14 Jun 2016 19:32:48 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: <015163C7-16EE-4D0A-A023-DFA8C85CD619@gmail.com> References: <015163C7-16EE-4D0A-A023-DFA8C85CD619@gmail.com> Message-ID: Thanks Alex and Allen, All of the devices tested on our side have Florida NPA/NXX's, including data only devices, which is more than likely the reason we are seeing issues elsewhere across the country. Seems to be reports elsewhere of similar issues, however is probably related to the same style MSC/HLR routing (back to Florida) The issue still persists, as of the timestamp of this email, tho, we did confirm 911 was unaffected, at least in the North Florida territory. Sent via EnguiFi LTE Mobile On Jun 14, 2016 7:15 PM, "Allen Kitchen" wrote: > Confirming problems making or receiving calls to phone numbers with a > Florida LATA, no matter where those phones actually reside. (In this case, > SW PA.) Verizon wireless website shows "temporarily unavailable while we > upgrade our systems" on selected My Vz pages. > > ..Allen > > > > On Jun 14, 2016, at 18:34, Kraig Beahn wrote: > > > > Looks like Verizon Wireless 4G voice, intermittent data services and some > > 3g voices services are currently non-functional, specifically in the SE, > > however, seeing reports nationwide as well. > > > > > > -- > From alex.buie at frozenfeline.net Wed Jun 15 00:05:09 2016 From: alex.buie at frozenfeline.net (Alex Buie) Date: Tue, 14 Jun 2016 20:05:09 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: <015163C7-16EE-4D0A-A023-DFA8C85CD619@gmail.com> Message-ID: Issue is supposedly resolved. Please test :) On Jun 14, 2016 7:33 PM, "Kraig Beahn" wrote: > Thanks Alex and Allen, > > All of the devices tested on our side have Florida NPA/NXX's, including > data only devices, which is more than likely the reason we are seeing > issues elsewhere across the country. > > Seems to be reports elsewhere of similar issues, however is probably > related to the same style MSC/HLR routing (back to Florida) > > The issue still persists, as of the timestamp of this email, tho, we did > confirm 911 was unaffected, at least in the North Florida territory. > > Sent via EnguiFi LTE Mobile > On Jun 14, 2016 7:15 PM, "Allen Kitchen" > wrote: > > > Confirming problems making or receiving calls to phone numbers with a > > Florida LATA, no matter where those phones actually reside. (In this > case, > > SW PA.) Verizon wireless website shows "temporarily unavailable while we > > upgrade our systems" on selected My Vz pages. > > > > ..Allen > > > > > > > On Jun 14, 2016, at 18:34, Kraig Beahn wrote: > > > > > > Looks like Verizon Wireless 4G voice, intermittent data services and > some > > > 3g voices services are currently non-functional, specifically in the > SE, > > > however, seeing reports nationwide as well. > > > > > > > > > -- > > > From kraig at enguity.com Wed Jun 15 00:38:14 2016 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 14 Jun 2016 20:38:14 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: <015163C7-16EE-4D0A-A023-DFA8C85CD619@gmail.com> Message-ID: So far, except having to wait for remote reboots on several hundred sites, looking good. Voice, Data and and the few VZW 4G Network Extenders are processing LTE packets properly. Thanks Alex, for the insight and update (s). Sent via EnguiFi LTE Mobile On Jun 14, 2016 8:05 PM, "Alex Buie" wrote: > Issue is supposedly resolved. Please test :) > On Jun 14, 2016 7:33 PM, "Kraig Beahn" wrote: > >> Thanks Alex and Allen, >> >> All of the devices tested on our side have Florida NPA/NXX's, including >> data only devices, which is more than likely the reason we are seeing >> issues elsewhere across the country. >> >> Seems to be reports elsewhere of similar issues, however is probably >> related to the same style MSC/HLR routing (back to Florida) >> >> The issue still persists, as of the timestamp of this email, tho, we did >> confirm 911 was unaffected, at least in the North Florida territory. >> >> Sent via EnguiFi LTE Mobile >> On Jun 14, 2016 7:15 PM, "Allen Kitchen" >> wrote: >> >> > Confirming problems making or receiving calls to phone numbers with a >> > Florida LATA, no matter where those phones actually reside. (In this >> case, >> > SW PA.) Verizon wireless website shows "temporarily unavailable while we >> > upgrade our systems" on selected My Vz pages. >> > >> > ..Allen >> > >> > >> > > On Jun 14, 2016, at 18:34, Kraig Beahn wrote: >> > > >> > > Looks like Verizon Wireless 4G voice, intermittent data services and >> some >> > > 3g voices services are currently non-functional, specifically in the >> SE, >> > > however, seeing reports nationwide as well. >> > > >> > > >> > > -- >> > >> > From hank at efes.iucc.ac.il Wed Jun 15 05:25:04 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 15 Jun 2016 08:25:04 +0300 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: On 14/06/2016 20:49, Randy Bush wrote: > the O in nanog is operator, not sponsor, panderer, suck up, ... we're > spending millions for half debugged underperforming crap and we are > cornered by infrastructure providers (e.g. ixps) who run us over time > and again if it makes an extra penny. I am not at NANOG67 and am following this issue remotely. Excuse me if I am getting this all wrong. Dave shows a slide that LINX made $2.3M profit and AMS-IX made $4.1M last year and Randy states "that the IXPs run us over to make an extra penny"? Would we prefer that Level3 which reported profits of $122M operate the IXPs instead? Or perhaps NTT with $4.7B in profits in 2015? The Internet is no longer a volunteer operation run out of a few CS departments in major universities. If an IXP makes $4M of profit - good for them. I'd rather have each of these IXPs not only secure from cyber attacks but also secure financially. To all IXPs that keep the bits flowing - keep up the good work. Kudos! -Hank From eric.kuhnke at gmail.com Wed Jun 15 05:43:13 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 14 Jun 2016 22:43:13 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> Message-ID: Re: Item #3 there, the Google Docs spreadsheet with the IX costs... Scroll all the way down to the bottom in $/Mbps and you will find the SIX. Everyone in the Pacific NW should appreciate the excellent work that the SIX does. It's a nonprofit with transparency in its finances, a health cash reserve for emergencies and new equipment and meets very stringent uptime and reliability requirements. ISP entities and enterprise end users 1000 km away from the SIX in random locations in British Columbia, Montana, Utah and other western US states benefit from it. People who have no idea what an IX is or how it functions have better, faster and lower cost last mile Internet access thanks to their local small ISP that has had the foresight to purchased a transport circuit to Seattle to reach the SIX. It is worth mentioning that the fine people at the NWAX in Portland are working to build on the example set by the SIX, and are a 501(c)6 nonprofit: http://www.nwax.net/ On Tue, Jun 14, 2016 at 1:20 PM, Jared Mauch wrote: > > > On Jun 14, 2016, at 11:12 AM, Matt Peterson wrote: > > > > This week at NANOG67, a presentation was given early on that did not > > reflect well for our community at large. > > I think that the data presented was interesting but the style of > the presenter and tone could have been different. It seemed > to be a variant of ?The Rent is Too Damn High?[1] while it can > be interesting, there wasn?t a complete talk there IMHO. > > The feedback mechanism for this is honestly the survey[2]. I?m confident > that the PC will take this input seriously and work with presenters > in this regard. > > The IXP cost sheet[3] that is being maintained by Job I think gives an > idea of the peering vs transit costs assuming various bitrates and > list prices. > > The fates of IXPs and their roles will naturally resolve itself through > market economics I suspect. > > - Jared > > - snip - links - snip - > 1 - https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party > 2 - https://www.nanog.org/meetings/nanog67/survey > 3 - > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 From adrian.minta at gmail.com Wed Jun 15 09:11:03 2016 From: adrian.minta at gmail.com (Adrian M) Date: Wed, 15 Jun 2016 12:11:03 +0300 Subject: Webmail / IMAPS software for end-user clients in 2016 In-Reply-To: <76D8AAB9-03DA-4E70-A943-D3C110E2DCD3@ironie.org> References: <4cf4a1790eda2263bb3bc288cefcffdc@mail.cmsws.com> <76D8AAB9-03DA-4E70-A943-D3C110E2DCD3@ironie.org> Message-ID: >From AfterLogic you may use the following webmail clients: - without calendar -> WebMail-lite PHP - with personal calendar -> WebMail PHP - with calendar and full sharing exchange style -> Aurora On Tue, Jun 14, 2016 at 8:50 PM, Guillaume Tournat wrote: > Zimbra is a full featured groupware server. I don't think you can just use > the webmail part with existing IMAP server. > > So it doesn't fulfill requirements stated by initial poster. > > > > > Le 13 juin 2016 ? 21:24, Greg Sowell a ?crit : > > > > +1 for Zimbra > > > >> On Sun, Jun 12, 2016 at 12:53 PM, Jim Lucas wrote: > >> > >> June 8 2016 6:08 PM, "Eric Kuhnke" wrote: > >>> If you had to put up a public facing webmail interface for people to > use, > >>> and maintain it for the foreseeable future (5-6 years), what would you > >> use? > >>> > >>> Roundcube? > >>> https://roundcube.net > >>> > >>> Rainloop? > >>> http://www.rainloop.net > >>> > >>> Something else? > >>> > >>> Requirements: > >>> Needs to be open souce and GPL, BSD or Apache licensed > >>> > >>> Email storage will be accessed via IMAP/TLS1.2 > >>> > >>> Runs on a Debian based platform with apache2 or nginx > >>> > >>> Desktop browser CSS and mobile device CSS/HTML functionality on 4" to > 7" > >>> size screens with Chrome and Safari > >> > >> I work for an ISP, and recently we were faced with the same dilemma. We > >> knew that our RoundCube was rather old and needed a facelift. We > started > >> looking at new clients what I came across RainLoop. > >> > >> IMO RoundCube still doesn't have a decent working mobile theme. > >> > >> I went ahead and installed RainLoop on my personal server. Configuration > >> was a breeze. The interface is very nice. And the mobile layout is very > >> slick. > >> > >> I did come across a problem with displaying emails and when I emailed > >> their support email, they were very quick to respond. And within 24 > hors > >> they were able to write a fix for my specific issue and build a new > release > >> for me to download and test. > >> > >> I think that says something for their support team. > >> > >> Even if my office doesn't adopt RainLoop, I will continue using it on > my > >> personal server for the forsee able future. > >> > >> -- > >> Jim Lucas > >> C - 5414085189 > >> H - 5413234219 > >> http://cmsws.com > > > > > > > > -- > > > > GregSowell.com > > TheBrothersWISP.com > > From aledm at qix.co.uk Wed Jun 15 10:43:40 2016 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 15 Jun 2016 11:43:40 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: On 14 June 2016 at 22:38, Owen DeLong wrote: > So I just watched the video of Dave?s talk. > Me too and I was confused about what the point of it was. I had always assumed the customers of those IXs he singled out were generally happy with the service they were getting and the money they are paying. Is Dave trying to say they are being duped? Is he trying to identify a need for regulation? I would hope that any company looking to join an IX does so with their eyes open and with due diligence (and I don't think it is my place to tell them if they should or not use an IX, unless they hire me to give them that advice :-) Perhaps Dave was advocating the SIX model and suggesting the customers of the existing exchanges should be looking to organise an alternative in their localities. Or perhaps this is a wakeup call for LoNAP and the smaller exchanges who "compete" with AMS-IX, DE-CIX and NetNod - stop trying to mimic their commercial models (big fees which pay for staff and marketing) and look instead at the lean SIX as the way of offering a service at a price competitive to transit. Or was there a hidden message in Dave's presentation that I missed? Aled From randy at psg.com Wed Jun 15 10:47:21 2016 From: randy at psg.com (Randy Bush) Date: Wed, 15 Jun 2016 19:47:21 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: > I am not at NANOG67 and am following this issue remotely. Excuse me > if I am getting this all wrong. Dave shows a slide that LINX made > $2.3M profit and AMS-IX made $4.1M last year and Randy states "that > the IXPs run us over to make an extra penny"? confusing coincidence and causality is a common mistake From dave at temk.in Wed Jun 15 11:21:00 2016 From: dave at temk.in (Dave Temkin) Date: Wed, 15 Jun 2016 04:21:00 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: On Wed, Jun 15, 2016 at 3:43 AM, Aled Morris wrote: > > > Me too and I was confused about what the point of it was. > > I had always assumed the customers of those IXs he singled out were > generally happy with the service they were getting and the money they are > paying. > > Is Dave trying to say they are being duped? Is he trying to identify a > need for regulation? > I was pointing out facts about IXPs that many did not know, including the actual organizational structure. I was also opining on how these IXPs could be better; mainly, how they choose to spend money. > > Perhaps Dave was advocating the SIX model and suggesting the customers of > the existing exchanges should be looking to organise an alternative in > their localities. > Absolutely correct (which should answer Hank's question, as well). > > Or perhaps this is a wakeup call for LoNAP and the smaller exchanges who > "compete" with AMS-IX, DE-CIX and NetNod - stop trying to mimic their > commercial models (big fees which pay for staff and marketing) and look > instead at the lean SIX as the way of offering a service at a price > competitive to transit. > Also absolutely correct. I don't want to see them falling into a trap of conflating marketing and outreach and/or offering an overly rich product set at the cost of price and operational simplicity. > Or was there a hidden message in Dave's presentation that I missed? > Seems like you got it. > Aled > From nanog at ics-il.net Wed Jun 15 12:37:22 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Jun 2016 07:37:22 -0500 (CDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> Message-ID: <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> I agree that the SIX is a fine organization, but the framework of the organization has little to do with the members getting screwed over. A non-profit donation-based IX that doesn't produce results could be screwing its "customers" over more than a MRC-based for-profit IX that does produce. I also think that the individual merits of an organization or business model is pretty astray from the OP's original point (correct or not) about using the NANOG presentation platform for thinly veiled personal agenda. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Kuhnke" To: nanog at nanog.org Sent: Wednesday, June 15, 2016 12:43:13 AM Subject: Re: NANOG67 - Tipping point of community and sponsor bashing? Re: Item #3 there, the Google Docs spreadsheet with the IX costs... Scroll all the way down to the bottom in $/Mbps and you will find the SIX. Everyone in the Pacific NW should appreciate the excellent work that the SIX does. It's a nonprofit with transparency in its finances, a health cash reserve for emergencies and new equipment and meets very stringent uptime and reliability requirements. ISP entities and enterprise end users 1000 km away from the SIX in random locations in British Columbia, Montana, Utah and other western US states benefit from it. People who have no idea what an IX is or how it functions have better, faster and lower cost last mile Internet access thanks to their local small ISP that has had the foresight to purchased a transport circuit to Seattle to reach the SIX. It is worth mentioning that the fine people at the NWAX in Portland are working to build on the example set by the SIX, and are a 501(c)6 nonprofit: http://www.nwax.net/ On Tue, Jun 14, 2016 at 1:20 PM, Jared Mauch wrote: > > > On Jun 14, 2016, at 11:12 AM, Matt Peterson wrote: > > > > This week at NANOG67, a presentation was given early on that did not > > reflect well for our community at large. > > I think that the data presented was interesting but the style of > the presenter and tone could have been different. It seemed > to be a variant of ?The Rent is Too Damn High?[1] while it can > be interesting, there wasn?t a complete talk there IMHO. > > The feedback mechanism for this is honestly the survey[2]. I?m confident > that the PC will take this input seriously and work with presenters > in this regard. > > The IXP cost sheet[3] that is being maintained by Job I think gives an > idea of the peering vs transit costs assuming various bitrates and > list prices. > > The fates of IXPs and their roles will naturally resolve itself through > market economics I suspect. > > - Jared > > - snip - links - snip - > 1 - https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party > 2 - https://www.nanog.org/meetings/nanog67/survey > 3 - > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 From bicknell at ufp.org Wed Jun 15 13:26:56 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jun 2016 06:26:56 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> Message-ID: <20160615132656.GA76899@ussenterprise.ufp.org> In a message written on Wed, Jun 15, 2016 at 08:25:04AM +0300, Hank Nussbacher wrote: > I am not at NANOG67 and am following this issue remotely. Excuse me if I am getting this all wrong. Dave shows a slide that LINX made $2.3M profit and AMS-IX made $4.1M last year and Randy states "that the IXPs run us over to make an extra penny"? When I vew the presentation from a raw money basis, it seems like just a "we hate our suppliers" whine. For instance it's quite normal for a "not for profit" to both pay salaries and marketing, and to even "make a profit" from a raw accounting perspective. There's also nothing in the non-profit rules that disallow marketing departments or spending money on socials. If those things further their non-profit mission, it's all good. However there is another perspective where I think a good point is raised, and perhaps a bit lost. Some of these IXP's are "community run". Or well, they say they are "community run". But when the curtian is pulled back, perhaps they look a lot less community run and a lot more like a business with a savvy marketing department leading people to believe they are community run. I do wonder how many people became a _member_ of these "community run" IXP's thinking that entited them to some say over how it was run, only to discover due to the bylaws and corporate structure they have in fact little to no say over anything? That is a form of bait-and-switch, and _may_ be a problem with some IXP's. Maybe the community wants a no-marketing cost-recovery co-op service, and this is a way of rallying and organizing for that. It's on that point that the presentation is classic NANOG, a bunch of operators getting together to discuss their common issues and figure out if there if there is a path forward to make things better. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at foobar.org Wed Jun 15 13:38:32 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 15 Jun 2016 14:38:32 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: <57615A58.1060809@foobar.org> Dave Temkin wrote: > I was pointing out facts about IXPs that many did not know, including the > actual organizational structure. Dave, was this talk about IXPs in general, or the 4 IXPs you named in your talk? Nick From allenmckinleykitchen at gmail.com Tue Jun 14 23:15:12 2016 From: allenmckinleykitchen at gmail.com (Allen Kitchen) Date: Tue, 14 Jun 2016 19:15:12 -0400 Subject: Verizon Wireless 4G Voice/Data In-Reply-To: References: Message-ID: <015163C7-16EE-4D0A-A023-DFA8C85CD619@gmail.com> Confirming problems making or receiving calls to phone numbers with a Florida LATA, no matter where those phones actually reside. (In this case, SW PA.) Verizon wireless website shows "temporarily unavailable while we upgrade our systems" on selected My Vz pages. ..Allen > On Jun 14, 2016, at 18:34, Kraig Beahn wrote: > > Looks like Verizon Wireless 4G voice, intermittent data services and some > 3g voices services are currently non-functional, specifically in the SE, > however, seeing reports nationwide as well. > > > -- From dave at temk.in Wed Jun 15 13:46:34 2016 From: dave at temk.in (Dave Temkin) Date: Wed, 15 Jun 2016 13:46:34 +0000 (UTC) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <57615A58.1060809@foobar.org> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <57615A58.1060809@foobar.org> Message-ID: General, with the four being used as varying examples. I could have included US IXP's, but almost none publish their prices and the ones that do only started recently, so the comparison wasn't worthwhile.? On Wed, Jun 15, 2016 at 8:39 AM -0500, "Nick Hilliard" wrote: Dave Temkin wrote: > I was pointing out facts about IXPs that many did not know, including the > actual organizational structure. Dave, was this talk about IXPs in general, or the 4 IXPs you named in your talk? Nick From sryan at arbor.net Wed Jun 15 15:16:30 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 15 Jun 2016 11:16:30 -0400 Subject: Comcast (DOCSIS) issues in Boston? Message-ID: Anyone seeing any issues with routing into Boston? We have a DOCSIS link that seems unroutable past 350 E Cermak in Chicago, traceroutes from two carries here in Michigan stop there. We have a fiber (EDI/BGP) with them at the same location and I'm not seeing any issues on that link. The site itself can ping it's default gateway but can't get anywhere else. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From jneiberger at gmail.com Wed Jun 15 15:32:58 2016 From: jneiberger at gmail.com (John Neiberger) Date: Wed, 15 Jun 2016 09:32:58 -0600 Subject: Comcast (DOCSIS) issues in Boston? In-Reply-To: References: Message-ID: I'd be glad to take a look. I'll reply off-list to get more details from you. Thanks, John On Wed, Jun 15, 2016 at 9:16 AM, Spencer Ryan wrote: > Anyone seeing any issues with routing into Boston? We have a DOCSIS link > that seems unroutable past 350 E Cermak in Chicago, traceroutes from two > carries here in Michigan stop there. We have a fiber (EDI/BGP) with them at > the same location and I'm not seeing any issues on that link. > > The site itself can ping it's default gateway but can't get anywhere else. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > From nick at foobar.org Wed Jun 15 15:48:22 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 15 Jun 2016 16:48:22 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <57615A58.1060809@foobar.org> Message-ID: <576178C6.10204@foobar.org> Hi Dave, Dave Temkin wrote: > General, with the four being used as varying examples. Then there is a problem - you only presented info relating to those four organisations, not for any other IXP, at least outside a small number of sponsor-supported IXPs in the US. With respect to all parties involved in this discussion, I'd suggest that these four IXPs are not representative of the IXP community in the areas that you talked about, namely size, marketing budgets, corporate profit / surplus or expansion intentions. In addition, Job's excellent pricing comparison sheet: > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit?pref=2&pli=1#gid=0 ... suggests that of the four you chose to talk about, all of them are in the top pricing bracket. This is an observation rather than a criticism of this pricing, btw - I have heard people from other large US multinationals say that LINX's outreach and policy representation alone were worth the port charges they pay. Netnod runs a dns root server system (i.root-servers.net) as well as a heavy duty time service. We're all free to agree or disagree with whether these things are worthwhile spending money on, but it would have been useful from the point of view of the broader discussion to have mentioned them in the main body of your presentation. Regarding the pricing reduction on page 16 of your preso, the US$ and UK? are not much different than what they were 5 years ago, but the ? has dropped by 30% against the US$. The transit pricing you quoted was base-lined in ? from the Teleogeography source (but converted to US$ at today's rate), but both DE-CIX and AMS-IX's prices are denominated in ?. This means that the reduction in pricing in local currency for those two IXPs is out by about 30% with respect to the transit pricing. I haven't worked out the figures exactly, but in the case of AMS-IX, it looks like this would bring their price reductions over 5 years to be ~equivalent to the drop in transit pricing. Also, AMS-IX's 2015 report shows a net operating loss of ?1.3 million. LINX made a operating loss in 2015 too, even if they were also EBITDA positive like AMS-IX. The EBITDA figures which you gave on page 11 are important indicators of a company's financial health, but the net surplus or loss needs to be given. There's a breakdown in their annual reports: > https://www.linx.net/documents/www.linx.net/uploads/files/LINX-2015-Annual-Report.pdf > https://ams-ix.net/annual_report/AMS-IX_Annual-Report_2015.pdf You made the point that some US companies buy services in Europe using US$, but not all do. Plenty of US companies buying IXP ports in europe pay from local offices using euro / pounds / whatever the local currency is. I'm not being a bean-counter, so can't speculate about which option works better for which company but I'm sure there are sound financial reasons why some US companies buy in dollars rather than local currency. Regardless of all that, Job's pricing spreadsheet suggests that the pricing models are substantially lower for the other IXPs in his list, and have seen proportional reductions at least equal to transit pricing drops, if not greater. If your talk was about IXPs in general, this was an important omission. Two of the organisations you mentioned are member-owned and are bound by formal votes from their membership. Member votes are, in fact, legally binding in most if not all member-owned IXPs that I'm aware of in Europe. Netnod, DECIX and many others are not participant-owned, so this does not apply. In the area of marketing budgets and expansion, there is probably a correlation between the two, but I think it's worth mentioning that pretty much no other IXP - at least out of those mentioned in Job's spreadsheet - have anything close to that % of their overall budgets dedicated to marketing, or have similar expansion plans. I know that a lot of european IXP marketing budgets are pitifully small. Again, this needs to be mentioned if your talk was about IXPs in general. If people don't like the idea of LINX, DE-CIX and AMS-IX expanding outside their current markets, they don't have to connect to them and that's ok because this is a fully unregulated market: no-one has ever forced anyone to connect to any IXP. Otherwise, thanks for giving a great talk - it's both refreshing and stimulating to have this discussion, and it's great to get feedback from the community about it. Nick -- CTO INEX, but these are personal opinions From dave at temk.in Wed Jun 15 16:19:43 2016 From: dave at temk.in (Dave Temkin) Date: Wed, 15 Jun 2016 09:19:43 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <576178C6.10204@foobar.org> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <57615A58.1060809@foobar.org> <576178C6.10204@foobar.org> Message-ID: I hope you'll excuse the aggressive snipping, as I wanted to try to address as many of your points without repeating myself as possible. On Wed, Jun 15, 2016 at 8:48 AM, Nick Hilliard wrote: > Hi Dave, > > Dave Temkin wrote: > > With respect to all parties involved in this discussion, I'd suggest > that these four IXPs are not representative of the IXP community in the > areas that you talked about, namely size, marketing budgets, corporate > profit / surplus or expansion intentions. > They are representative of the most important IXPs to deliver traffic from in Western Europe. I would posit that what defines important to me may not be what defines important to you and the same can be said when you look at how various "internet" companies look at what's important in their vertical. > > > > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit?pref=2&pli=1#gid=0 > > I have heard people from other large US > multinationals say that LINX's outreach and policy representation alone > were worth the port charges they pay. I dedicated an entire slide to this. I think Malcom does great work. > Netnod runs a dns root server > system (i.root-servers.net) as well as a heavy duty time service. There are others who do this for no cost and some who do it for government money. Whether or not my port fees should subsidize this is a valid question, and was brought up in the Q&A afterwards. > > Regarding the pricing reduction on page 16 of your preso, the US$ and > UK? are not much different than what they were 5 years ago, but the ? > has dropped by 30% against the US$. > You speak to this below, however if my business is primarily run in USD (which was the relevant use case presented: I'm a US company deciding if I should peer in Europe or buy transit) then those currency fluctuations have a very different impact than if I'm a European company functioning primarily in local currency. > > You made the point that some US companies buy services in Europe using > US$, but not all do. > Not all do. Again, this wasn't an exhaustive list of what every IXP and every member does. This is what I see, and the entire presentation was framed as that. How currency fluctuations impact my business will likely vary significantly from how they impact yours. > Regardless of all that, Job's pricing spreadsheet suggests that the > pricing models are substantially lower for the other IXPs in his list, > and have seen proportional reductions at least equal to transit pricing > drops, if not greater. If your talk was about IXPs in general, this was > an important omission. > There are absolutely some great pricing models on IXPs. There are also some terrible ones. I highlighted the ones I find to be bad. Again, my presentation, my opinion, in the same way that someone might stand up and say "Cisco sucks because they don't have the CLI I want" or "Juniper sucks because they charge too much for ports with TCAM". I don't have to then present an exhaustive list of those that are better in order to validate my claim. I did purposefully mention SIX as a polar opposite example - there is definitely a happy medium to be found. > Two of the organisations you mentioned are member-owned and are bound by > formal votes from their membership. Member votes are, in fact, legally > binding in most if not all member-owned IXPs that I'm aware of in > Europe. Netnod, DECIX and many others are not participant-owned, so > this does not apply. > Which I mentioned in my presentation. I refrained from exhaustively explaining each model as IANAL and didn't feel it made sense for me to attempt to explain four different nations laws. I did invite comment from the floor for the organizations mentioned to do so, and they declined. To be clear: I did apologize both in the Plenary and then later on Twitter if the "Membership" slide was misleading, as I did not intend on implying that LINX is not a member owned organization. > > In the area of marketing budgets and expansion, there is probably a > correlation between the two, but I think it's worth mentioning that > pretty much no other IXP - at least out of those mentioned in Job's > spreadsheet - have anything close to that % of their overall budgets > dedicated to marketing > It wasn't. It was about the IXPs that mattered to me. If we had an entire day to talk about this I could've been way more exhaustive (and everyone would've been way more exhausted...). LONAP and INEX are great counter examples. > If people don't like the idea of LINX, DE-CIX and AMS-IX expanding > outside their current markets, they don't have to connect to them and > that's ok because this is a fully unregulated market: no-one has ever > forced anyone to connect to any IXP. > Completely agree! > > Otherwise, thanks for giving a great talk - it's both refreshing and > stimulating to have this discussion, and it's great to get feedback from > the community about it. > > Thank you! That was the point of the talk: to start the discussion. It definitely has, and I'm glad for that. > > From mangawilly at gmail.com Wed Jun 15 15:56:47 2016 From: mangawilly at gmail.com (Willy MANGA) Date: Wed, 15 Jun 2016 16:56:47 +0100 Subject: Link-local v6 and mobile phones Message-ID: <57617ABF.3070208@gmail.com> Hello, a little question :) For mobile operators using v6 on their networks, how do you manage link-local communication between mobile phones ? While I understand it's layer 2 related, am i able for example to make ping sweep and be able to communicate directly with other phone (customer) ? -- Willy Manga (from where I stand mobile operators do not use yet v6 :-\ ) freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From swmike at swm.pp.se Wed Jun 15 17:34:58 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 15 Jun 2016 19:34:58 +0200 (CEST) Subject: Link-local v6 and mobile phones In-Reply-To: <57617ABF.3070208@gmail.com> References: <57617ABF.3070208@gmail.com> Message-ID: On Wed, 15 Jun 2016, Willy MANGA wrote: > Hello, > > a little question :) > > For mobile operators using v6 on their networks, how do you manage > link-local communication between mobile phones ? > > While I understand it's layer 2 related, am i able for example to make > ping sweep and be able to communicate directly with other phone (customer) ? No. Your phone has a tunnel to a node in the mobile network and that's the only one you can send packets to. It's a GTP tunnel, but it's very similar to GRE or IPIP or whatever. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Wed Jun 15 17:40:41 2016 From: joelja at bogus.com (joel jaeggli) Date: Wed, 15 Jun 2016 10:40:41 -0700 Subject: Link-local v6 and mobile phones In-Reply-To: <57617ABF.3070208@gmail.com> References: <57617ABF.3070208@gmail.com> Message-ID: <3870094a-d7ed-570f-6e13-a6fc7f59a271@bogus.com> On 6/15/16 8:56 AM, Willy MANGA wrote: > Hello, > > a little question :) > > For mobile operators using v6 on their networks, how do you manage > link-local communication between mobile phones ? the link local address is bound to eps bearer the other end of which is the p-gw. so it's a point-to-point link. so you say what about the radio bearer? there are two kinds, the srb where signalling is present, and the user data which is associated with an eps databearer. > While I understand it's layer 2 related, am i able for example to make > ping sweep and be able to communicate directly with other phone (customer) ? appart from your nexthop, no. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Wed Jun 15 17:57:27 2016 From: randy at psg.com (Randy Bush) Date: Thu, 16 Jun 2016 02:57:27 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: > Perhaps Dave was advocating the SIX model that is where the big euro exchanges started. then they got equinix envy and colonialism. let's see (and help) the six avoid these diseases over the next years. randy From swmike at swm.pp.se Wed Jun 15 18:10:35 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 15 Jun 2016 20:10:35 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: On Thu, 16 Jun 2016, Randy Bush wrote: > that is where the big euro exchanges started. then they got equinix > envy and colonialism. let's see (and help) the six avoid these diseases > over the next years. Well, the customers also wanted more functions and features. They wanted sFLOW statistics to show traffic, customer portals, better SLAs, distributed IXes, remote peering, more hand-holding when connecting etc. They also told IX operators that it was good if they did good-for-the-Internet things. They also sent lawyers to (re)negotiate contracts, demand special discounts, treat the IXP like any other supplier of services that you want to negotiate with. So now IXPs started to look a lot more like small/medium ISPs than anything else. This means economy of scale, which means expansion to get bigger footprint using same systems makes sense. So here we are now... Where do we want to go? -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Wed Jun 15 18:23:40 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 15 Jun 2016 20:23:40 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> > So here we are now... Where do we want to go? I think IXPs have indeed become too much like ISPs, providing more services but also increasing complexity and cost. I prefer simple, scalable and cheap solutions! I want to go to an IXP being a nice simple ethernet switch. Add some nice graphs and a route server, and we're done. Redundancy is a separate switch :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Wed Jun 15 18:33:43 2016 From: randy at psg.com (Randy Bush) Date: Thu, 16 Jun 2016 03:33:43 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> Message-ID: > I want to go to an IXP being a nice simple ethernet switch. Add some > nice graphs and a route server, and we're done. Redundancy is a > separate switch :) come to seattle. but mikael has a point. big peers do their own s-flow, and sparkly things. then smaller ix members want those things too, but can or will not do it for themselves. and soon they find an ix engineer who wants to show their sparkle fu. next thing you know, there is a salesperson to take orders and promte sparkly things. slippery slope. like nanog itself, when you start to assess quality by measuring quantity, you get a low end american supermarket, a jillion false choices of poor food. randy From swmike at swm.pp.se Wed Jun 15 18:34:36 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 15 Jun 2016 20:34:36 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> Message-ID: On Wed, 15 Jun 2016, Sander Steffann wrote: > I want to go to an IXP being a nice simple ethernet switch. Add some > nice graphs and a route server, and we're done. Redundancy is a separate > switch :) So how should the larger distributed IXPs solve this? Provide optical DWDM transport? Dark fiber? What if there are no chassis on the market large enough to accomodate creating a single switch for all customers to connect to? Have multiple L2 domains and require people to connect to multiple switches? Even bumping people off of an existing switch when that is full, to move some traffic over to another new switch chassis? What about buffer requirements? If you want a buffered switch, it increases capex and lowers number of switch-models that can be used. Microbuffered switches may lose packets in microbursts when ports are being run (near) full. -- Mikael Abrahamsson email: swmike at swm.pp.se From sethm at rollernet.us Wed Jun 15 19:10:24 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2016 12:10:24 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> Message-ID: On 6/15/16 11:23, Sander Steffann wrote: > I think IXPs have indeed become too much like ISPs, providing more services but also increasing complexity and cost. I prefer simple, scalable and cheap solutions! That was one thing mentioned in the talk, "just give me layer 2" or something to that effect. ~Seth From sethm at rollernet.us Wed Jun 15 19:14:21 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2016 12:14:21 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> Message-ID: <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> On 6/15/16 05:37, Mike Hammett wrote: > I agree that the SIX is a fine organization, but the framework of the organization has little to do with the members getting screwed over. A non-profit donation-based IX that doesn't produce results could be screwing its "customers" over more than a MRC-based for-profit IX that does produce. An IX just needs to "produce" a layer 2 peering fabric. That's not a tall order to get results from. Anything beyond that is extra fluff. Some people want to pay more for the fluff, some don't. ~Seth From nanog at ics-il.net Wed Jun 15 20:14:34 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Jun 2016 15:14:34 -0500 (CDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> Message-ID: <118024904.58409.1466021671089.JavaMail.mhammett@ThunderFuck> Getting people to show up can be a challenge. I've been asked by members of two midwestern IXes to come to their markets because their existing donation-supported loose and easy IX isn't really doing anything for them. Not arguing models, arguing that what should matter is results. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Seth Mattinen" To: nanog at nanog.org Sent: Wednesday, June 15, 2016 2:14:21 PM Subject: Re: NANOG67 - Tipping point of community and sponsor bashing? On 6/15/16 05:37, Mike Hammett wrote: > I agree that the SIX is a fine organization, but the framework of the organization has little to do with the members getting screwed over. A non-profit donation-based IX that doesn't produce results could be screwing its "customers" over more than a MRC-based for-profit IX that does produce. An IX just needs to "produce" a layer 2 peering fabric. That's not a tall order to get results from. Anything beyond that is extra fluff. Some people want to pay more for the fluff, some don't. ~Seth From D.Lasher at f5.com Wed Jun 15 21:03:37 2016 From: D.Lasher at f5.com (Donn Lasher) Date: Wed, 15 Jun 2016 21:03:37 +0000 Subject: Netflix banning HE tunnels In-Reply-To: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> References: <0ce898b3-8bd2-28ad-414f-5cc1db252b25@rollernet.us> Message-ID: On 6/12/16, 8:10 PM, "NANOG on behalf of Seth Mattinen" wrote: >On 6/7/16 4:23 AM, Davide Davini wrote: >> Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I >> can't use it if I don't disable the HE tunnel, which is the only way for >> me to have IPv6 at the moment. > > >This is a rights management issue not a technical one. Netflix is not to >blame, HE is not to blame. Hate on geolcaotion all you want, but that's >what the content owners insist upon and Netflix has no choice but to >disable access from sources that they can't geolocate well enough to >make the content owners happy. > >~Seth As someone who has been trying to get solid, consistent IPv6 at home since 2010, I continue to resort back to my HE tunnels, which have been both useful and dependable. Given the data Netflix client has available to it (IPv4 address, IPv6 address, anything else exposed to android/IOS/windows/etc app) it?s surprising to me that missing/incorrect geolocation data on an IPv6 address is enough to block service. The end result is, yet again, making IPv6 adoption harder than it needs to be. From arnold at nipper.de Wed Jun 15 22:28:40 2016 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 16 Jun 2016 00:28:40 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> Message-ID: <51112585-f163-6557-70eb-ae35e66a1f7c@nipper.de> On 15.06.2016 20:23, Sander Steffann wrote: >> So here we are now... Where do we want to go? > > I think IXPs have indeed become too much like ISPs, providing more > services but also increasing complexity and cost. I prefer simple, > scalable and cheap solutions! > You all know this saying: Fast, Good or Cheap. Pick any two! > I want to go to an IXP being a nice simple ethernet switch. Add some > nice graphs and a route server, and we're done. Redundancy is a > separate switch :) > Unfortunately the IXP world - at least for the really big IXPs - is not longer that simple. Paradise was yesterday ;-) btdt Arnold -- Arnold Nipper email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From arnold at nipper.de Wed Jun 15 22:36:46 2016 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 16 Jun 2016 00:36:46 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> Message-ID: On 15.06.2016 21:14, Seth Mattinen wrote: > On 6/15/16 05:37, Mike Hammett wrote: >> I agree that the SIX is a fine organization, but the framework of >> the organization has little to do with the members getting screwed >> over. A non-profit donation-based IX that doesn't produce results >> could be screwing its "customers" over more than a MRC-based >> for-profit IX that does produce. > > > An IX just needs to "produce" a layer 2 peering fabric. That's not a > tall order to get results from. Anything beyond that is extra fluff. > Some people want to pay more for the fluff, some don't. > This is a *common* misunderstanding. The by far easiest part of running a successful IXP is the technical part. The more challenging is to build a community around it. And that's purely non technical and involves a lot of *social* networking and bringing people together. btdt Arnold -- Arnold Nipper email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From woody at pch.net Wed Jun 15 23:03:36 2016 From: woody at pch.net (Bill Woodcock) Date: Wed, 15 Jun 2016 19:03:36 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> Message-ID: <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> >>> On 6/15/16 05:37, Mike Hammett wrote: >>> A non-profit donation-based IX that doesn't produce results >>> could be screwing its "customers" over more than a MRC-based >>> for-profit IX that does produce. >> >> On 15.06.2016 21:14, Seth Mattinen wrote: >> An IX just needs to "produce" a layer 2 peering fabric. That's not a >> tall order to get results from. Anything beyond that is extra fluff. >> Some people want to pay more for the fluff, some don't. > > On Jun 15, 2016, at 6:36 PM, Arnold Nipper wrote: > This is a *common* misunderstanding. > The by far easiest part of running a successful IXP is the technical part. > The more challenging is to build a community around it. And that's > purely non technical and involves a lot of *social* networking and > bringing people together. There?s a difference between the cost and the product. As regards the cost, Arnold is exactly right. Across the many hundreds of exchanges that we?ve worked with over the past 22 years, our observation has been that, at a rough average, most IXPs spend 45% of their first-year effort on location selection, 45% on governance definition and establishment, and 10% on technical decisions and implementation. But the total effort and the governance portion both increase drastically for those that choose to handle money; at a very, very rough average, about four-fold. In subsequent years, location selection generally drops away to near zero, except in cases like the JINX, and technical work dips for the first couple of years, and then spikes once every three years or so as switches are replaced and new configs are needed. Many exchanges have an annual in-person meeting where elections are conducted and policy changes ratified, so that typically becomes the largest ongoing expense, as Arnold implies. As regards the product, no, Seth, the layer 2 peering fabric is merely a necessary precondition for producing bandwidth. The actual bandwidth production has other preconditions as well: peers physically connected to the peering switch fabric, BGP sessions established between the peers, routes advertised across those sessions, a reasonable matching of potential traffic sources and sinks available through those routes, and a set of customer behaviors that prefer those source/sink matchings. Only then does an IXP produce bandwidth. So, the role of a salesperson or advocate or evangelist or tout can be a net beneficial one, if they do a good job of recruiting participants, making sure they follow through with peering, and encouraging the preference of locally-available content. WAIX was among the first IXPs to do this well, in my opinion. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sethm at rollernet.us Thu Jun 16 02:58:10 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2016 19:58:10 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: On 6/15/16 4:03 PM, Bill Woodcock wrote: > There?s a difference between the cost and the product. As regards the cost, Arnold is exactly right. Across the many hundreds of exchanges that we?ve worked with over the past 22 years, our observation has been that, at a rough average, most IXPs spend 45% of their first-year effort on location selection, 45% on governance definition and establishment, and 10% on technical decisions and implementation. But the total effort and the governance portion both increase drastically for those that choose to handle money; at a very, very rough average, about four-fold. In subsequent years, location selection generally drops away to near zero, except in cases like the JINX, and technical work dips for the first couple of years, and then spikes once every three years or so as switches are replaced and new configs are needed. Many exchanges have an annual in-person meeting where elections are conducted and policy changes ratified, so that typically becomes the largest ongoing expense, as Arnold implies. Why do IXes seek to create a bureaucracy that needs to be fed increasing sums of money? ~Seth From eric.kuhnke at gmail.com Thu Jun 16 03:21:52 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 15 Jun 2016 20:21:52 -0700 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? Message-ID: a lot of PR fluff, but this may be of interest: http://www.wired.com/2016/06/barefoot-networks-new-chips-will-transform-tech-industry/ https://barefootnetworks.com/media/white_papers/Barefoot-Worlds-Fastest-Most-Programmable-Networks.pdf Based on their investors, could have interesting results for much lower cost 100GbE whitebox switches. From cb.list6 at gmail.com Thu Jun 16 03:24:04 2016 From: cb.list6 at gmail.com (Ca By) Date: Wed, 15 Jun 2016 20:24:04 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: On Wednesday, June 15, 2016, Seth Mattinen wrote: > On 6/15/16 4:03 PM, Bill Woodcock wrote: > >> There?s a difference between the cost and the product. As regards the >> cost, Arnold is exactly right. Across the many hundreds of exchanges that >> we?ve worked with over the past 22 years, our observation has been that, at >> a rough average, most IXPs spend 45% of their first-year effort on location >> selection, 45% on governance definition and establishment, and 10% on >> technical decisions and implementation. But the total effort and the >> governance portion both increase drastically for those that choose to >> handle money; at a very, very rough average, about four-fold. In >> subsequent years, location selection generally drops away to near zero, >> except in cases like the JINX, and technical work dips for the first couple >> of years, and then spikes once every three years or so as switches are >> replaced and new configs are needed. Many exchanges have an annual >> in-person meeting where elections are conducted and policy changes >> ratified, so that typically becomes the largest ongoing expense, as Arnold >> implies. >> > > Why do IXes seek to create a bureaucracy that needs to be fed increasing > sums of money? > > ~Seth > Cough cough ARIN cough. I don't know why they need to meet face to face 2 or 3 times a year. But, i am sure ppml will tell you it is a ground up process and these people on ppml like traveling and talking about policy.... And they do what members want. Much of our industry can be gleened by googling pictures of "peering cruise". At my office, we joke about that a lot. Peering cruise ...jeeshhh. I can't recommend SIX enough. Epic IX, amazing support. I get much better support from SIX than any of my transit providers. Amazing support. I also like sfmix and fl-ix. From sethm at rollernet.us Thu Jun 16 03:29:44 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2016 20:29:44 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: <1fc6877d-c5d6-f17d-abf0-1c0b2b5c9b1a@rollernet.us> On 6/15/16 8:24 PM, Ca By wrote: > > Cough cough ARIN cough. I don't know why they need to meet face to face > 2 or 3 times a year. But, i am sure ppml will tell you it is a ground up > process and these people on ppml like traveling and talking about > policy.... And they do what members want. Yeah, I guess. Although many of the policy proposals I see on ppml about IPv4-this or IPv4-that post runout are eye roll territory for me. ~Seth From cb.list6 at gmail.com Thu Jun 16 03:31:41 2016 From: cb.list6 at gmail.com (Ca By) Date: Wed, 15 Jun 2016 20:31:41 -0700 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: On Wednesday, June 15, 2016, Eric Kuhnke wrote: > a lot of PR fluff, but this may be of interest: > > > http://www.wired.com/2016/06/barefoot-networks-new-chips-will-transform-tech-industry/ > > > https://barefootnetworks.com/media/white_papers/Barefoot-Worlds-Fastest-Most-Programmable-Networks.pdf > > > Based on their investors, could have interesting results for much lower > cost 100GbE whitebox switches. > Where is the price tag? Why would you think it is inexpensive? I do think p4 is very interesting, but is it really much different from openflow? Which...umm ... Did not succeed in the market. From hannigan at gmail.com Thu Jun 16 03:41:22 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 15 Jun 2016 22:41:22 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: <141D7D51-BBA0-4563-8B26-4113170E0082@gmail.com> > On Jun 15, 2016, at 22:24, Ca By wrote: > >> On Wednesday, June 15, 2016, Seth Mattinen wrote: >> >>> On 6/15/16 4:03 PM, Bill Woodcock wrote: >>> [ clip ] > > I also like sfmix and fl-ix. FL-IX is great. It created real competition in the American South and for the Americas peering. I kept my interconnections to VZ while we see what happens when Zayo needs to recover their costs for the panel they're using to drain NOTA. There will be a day of reckoning, free is never free. Its a good hedge. SFMIX is great. But poorly distributed. We should support their efforts, but how many IXPs do we need in the Bay area? AMS-IX Bay Area is creating a market along with SFMIX. There is still copious amounts of traffic at VZ NOTA MIA. Two in a market works well IMHO. Best, -M< From geekgirl at gmail.com Thu Jun 16 06:12:02 2016 From: geekgirl at gmail.com (Leslie) Date: Wed, 15 Jun 2016 23:12:02 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <141D7D51-BBA0-4563-8B26-4113170E0082@gmail.com> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <141D7D51-BBA0-4563-8B26-4113170E0082@gmail.com> Message-ID: On Wed, Jun 15, 2016 at 8:41 PM, Martin Hannigan wrote: > > SFMIX is great. But poorly distributed. We should support their efforts, but how many IXPs do we need in the Bay area? AMS-IX Bay Area is creating a market along with SFMIX. > SFMIX is in 5 physical locations( https://www.sfmix.org/connect/locations ) and is always open to talking to other providers about extending into their datacenter. So I'd say we're in a variety of locations! We've also just celebrated our 10 year anniversary :) Leslie From hannigan at gmail.com Thu Jun 16 06:27:16 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 16 Jun 2016 01:27:16 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <141D7D51-BBA0-4563-8B26-4113170E0082@gmail.com> Message-ID: <35158EBF-D479-40DA-B1AC-FA3D5BF78360@gmail.com> > On Jun 16, 2016, at 01:12, Leslie wrote: > >> On Wed, Jun 15, 2016 at 8:41 PM, Martin Hannigan wrote: > >> SFMIX is great. But poorly distributed. We should support their efforts, but how many IXPs do we need in the Bay area? AMS-IX Bay Area is creating a market along with SFMIX. > > SFMIX is in 5 physical locations( > https://www.sfmix.org/connect/locations ) and is always open to > talking to other providers about extending into their datacenter. So > I'd say we're in a variety of locations! We've also just celebrated > our 10 year anniversary :) > > Leslie Agreed. Extended XC? Best, -M< From pavel.odintsov at gmail.com Thu Jun 16 06:28:19 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 16 Jun 2016 09:28:19 +0300 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: Looks very promising! On Thu, Jun 16, 2016 at 6:21 AM, Eric Kuhnke wrote: > a lot of PR fluff, but this may be of interest: > > http://www.wired.com/2016/06/barefoot-networks-new-chips-will-transform-tech-industry/ > > https://barefootnetworks.com/media/white_papers/Barefoot-Worlds-Fastest-Most-Programmable-Networks.pdf > > > Based on their investors, could have interesting results for much lower > cost 100GbE whitebox switches. -- Sincerely yours, Pavel Odintsov From jheitz at cisco.com Thu Jun 16 07:24:09 2016 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 16 Jun 2016 07:24:09 +0000 Subject: RPKI implementation Message-ID: During the RPKI presentation there was a question about resilience of the router if the RPKI cache loses connectivity. The IOS-XR implementation allows multiple caches to be configured. When a cache loses connectivity, the entries from that cache are purged after a time interval. Default is 60 seconds and it is configurable. A lookup of a prefix that is not loaded will return not-found. 5 seconds after the latest RPKI database update, a refresh request is sent to each neighbor, provided that the neighbor either: - dropped any received route due to a policy that contains validation-state, or - received a route, the validation state of which changed. If soft reconfiguration inbound is configured, then the refresh is avoided, because the received paths are stored. Thanks, Jakob. From saku at ytti.fi Thu Jun 16 07:51:35 2016 From: saku at ytti.fi (Saku Ytti) Date: Thu, 16 Jun 2016 10:51:35 +0300 Subject: 1GE L3 aggregation Message-ID: Hey, I've been bit poking around trying to find reasonable option for 1GE L3 full BGP table aggregator. It seems vendors are mostly pushing Satellite/Fusion for this application. I don't really like the added complexity and tight coupling Satellite/Fusion forces me. I'd prefer standards based routing redundancy to reduce impact of defects. ASR9001 and MX104 are not an options, due to control-plane scale. New boxes in vendor pipeline are completely ignoring 1GE. I've casually talked with other people, and it seems I'm not really alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface VLANs, ipfix or sflow, at least per-port QoS with shaper, martini pseudowires). With tinfoil hat tightly fit on my head, I wonder why vendors are ignoring 1GE? Are business cases entirely driven now by Amazon, Google, Facebook and the likes? Are SP volumes so insignificant in comparison it does not make sense to produce boxes for them? Heck even 10GE is starting to become problematic, if your application is anything else than DC, because you can't choose arbitrary optics. -- ++ytti From owen at delong.com Thu Jun 16 07:53:35 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2016 00:53:35 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> > Cough cough ARIN cough. I don't know why they need to meet face to face 2 > or 3 times a year. But, i am sure ppml will tell you it is a ground up > process and these people on ppml like traveling and talking about > policy.... And they do what members want. I don?t speak for the organization or even for the Advisory Council, but I can tell you that we get more focused community input and participation during those face to face meetings than we do during the rest of the year. Like it or not, when trying to get interactive participation from more than 5 or so people, there?s really no useful substitute for the face-to-face meeting. Every existing alternative is less useful and comes with significant drawbacks. So, yes, I believe ARIN does what the members want, but more importantly, I believe that the face to face meetings are a useful mechanism to preserve the bottom up nature of the policy development process. > Much of our industry can be gleened by googling pictures of "peering > cruise". At my office, we joke about that a lot. Peering cruise ?jeeshhh. I suppose you can joke about anything you want. Personally, I?ve never been on a peering cruise, but I will say that it?s a pretty classic fallacy to discount the value of the social times at conferences. In fact, I find those times to often be when most of the real work gets done and when most of the benefit of getting everyone together in the same place is realized. While NANOG puts on a good technical program, my company gets far more benefit from the time I spend meeting with network partners, suppliers, and potential customers during the conference than they will ever see from my time in the sessions. So much so that I generally attend the sessions on an as-available basis when I?m not able to schedule a more useful meeting. There are, of course exceptions. Some of the sessions (maybe 3-4 per conference) are worth holding my time open to attend, but most are not. This does not mean that I don?t consider NANOG valuable, just that the primary value is in the ability to meet with other attendees rather than directly in the technical program itself. I don?t mean this to be insulting to NANOG. I think the PC generally does a fine job of putting on a good conference with great content. Most importantly, it?s good enough that it draws in a large selection of people I need/want to meet with in a concentrated time frame in a single location. Peering fora, peering cruises, and the like have a similar effect. So scoff all you want, but if you imagine that these events are silly junkets where nothing gets accomplished, then you are seriously underestimating this community, IMHO. Owen From saku at ytti.fi Thu Jun 16 08:19:13 2016 From: saku at ytti.fi (Saku Ytti) Date: Thu, 16 Jun 2016 11:19:13 +0300 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: On 16 June 2016 at 06:21, Eric Kuhnke wrote: > Based on their investors, could have interesting results for much lower > cost 100GbE whitebox switches. Why lower cost? The BOM isn't the expensive part, the code is the expensive part. Only way I see this happening, is if we get open source routing suite for the box, i.e. 0 cost software. If you're thinking of writing your own routing suite, even if your requirements are trivial, it's still probably take 2-3 years and +2MUSD in salaries, and then maintenance +300kUSD/year in salaries. Need quite significant annual unit number scale to make it cheap. I'm quite fascinated by the idea of doing something really novel in routing suite space, but I don't see how it could possibly work commercially. How many customers would there be for licensing COTS routing-suite when costs are millions annually to develop it for general use-case. -- ++ytti From glen.kent at gmail.com Thu Jun 16 08:43:25 2016 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 16 Jun 2016 14:13:25 +0530 Subject: Strange Problem with 16 byte packets Message-ID: Hi, I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer. Thanks ! From ruairi.carroll at gmail.com Thu Jun 16 08:47:26 2016 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Thu, 16 Jun 2016 10:47:26 +0200 Subject: Strange Problem with 16 byte packets In-Reply-To: References: Message-ID: Follow the TCP stream - which side times out the link, and for what sequences of data do you get ACKs for? /Ruairi On 16 June 2016 at 10:43, Glen Kent wrote: > Hi, > > I am using a proprietary protocol and sending a bunch of bytes to a Draytek > router at an enterprise site. When i send the data in TCP batches of 1 MB i > see no problem. However, when i first send 16 bytes followed by 1 MB of > data, and then repeat this till the entire data has beeen sent out. During > this process I see that my TCP session times out. Unable to understand why > this could be happening? How can sending 16 bytes of data followed by 1MB > of data affect the transfer. > > Thanks ! > From petrus.lt at gmail.com Thu Jun 16 08:52:19 2016 From: petrus.lt at gmail.com (Pierre Emeriaud) Date: Thu, 16 Jun 2016 10:52:19 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: Hello Saku, > I've casually talked with other people, and it seems I'm not really > alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much > full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface > VLANs, ipfix or sflow, at least per-port QoS with shaper, martini > pseudowires). I'd go with a Nokia/ALu 7750. Two 48x1G IMM, or 5x m20-1gb-xp-sfp MDA + 3 IOM3-XP, and 100G IMMs (1 or 2 CFP ports - no idea about qsfp28 options though) with SF/CPM5. This would fit in a SR7. Not sure about the smaller models (-c or -a series). The 7450 might be an option too, but I don't know this hardware. RIB size is 20M iirc (shared between all af) and fib size 3 or 5M depending of the card. SR-OS is weird when you're used to ios or junos, but in the end the cli is very efficient and quite enjoyable actually. HTH, pierre From glen.kent at gmail.com Thu Jun 16 09:36:24 2016 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 16 Jun 2016 15:06:24 +0530 Subject: Strange Problem with 16 byte packets In-Reply-To: References: Message-ID: Thanks i will. However, the doubt is that what does introducing a 16 byte data into the steam does that causes the session to time out. I added instrumentation to push some dummy data so that instead of 16 bytes, we push 1 MB of data. In that case i saw no issues. Any idea if there is a firewall setting that could be coming into play here? On Thu, Jun 16, 2016 at 2:17 PM, Ruairi Carroll wrote: > Follow the TCP stream - which side times out the link, and for what > sequences of data do you get ACKs for? > > /Ruairi > > On 16 June 2016 at 10:43, Glen Kent wrote: > >> Hi, >> >> I am using a proprietary protocol and sending a bunch of bytes to a >> Draytek >> router at an enterprise site. When i send the data in TCP batches of 1 MB >> i >> see no problem. However, when i first send 16 bytes followed by 1 MB of >> data, and then repeat this till the entire data has beeen sent out. During >> this process I see that my TCP session times out. Unable to understand why >> this could be happening? How can sending 16 bytes of data followed by 1MB >> of data affect the transfer. >> >> Thanks ! >> > > From ruairi.carroll at gmail.com Thu Jun 16 10:42:46 2016 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Thu, 16 Jun 2016 12:42:46 +0200 Subject: Strange Problem with 16 byte packets In-Reply-To: References: Message-ID: It's hard to tell based on no data. Anything from here would be an assumption and hear-say, since you're debugging a black box and trying to infer inner workings based on external observations. You _need_ to collect more data and observe the data at the source and destination devices, and probably in transit if you're tunnelling/fragmenting. Basica, On 16 June 2016 at 11:36, Glen Kent wrote: > Thanks i will. However, the doubt is that what does introducing a 16 byte > data into the steam does that causes the session to time out. I added > instrumentation to push some dummy data so that instead of 16 bytes, we > push 1 MB of data. In that case i saw no issues. Any idea if there is a > firewall setting that could be coming into play here? > > On Thu, Jun 16, 2016 at 2:17 PM, Ruairi Carroll > wrote: > >> Follow the TCP stream - which side times out the link, and for what >> sequences of data do you get ACKs for? >> >> /Ruairi >> >> On 16 June 2016 at 10:43, Glen Kent wrote: >> >>> Hi, >>> >>> I am using a proprietary protocol and sending a bunch of bytes to a >>> Draytek >>> router at an enterprise site. When i send the data in TCP batches of 1 >>> MB i >>> see no problem. However, when i first send 16 bytes followed by 1 MB of >>> data, and then repeat this till the entire data has beeen sent out. >>> During >>> this process I see that my TCP session times out. Unable to understand >>> why >>> this could be happening? How can sending 16 bytes of data followed by 1MB >>> of data affect the transfer. >>> >>> Thanks ! >>> >> >> > From rea+nanog at grid.kiae.ru Thu Jun 16 11:34:16 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Thu, 16 Jun 2016 14:34:16 +0300 Subject: Strange Problem with 16 byte packets In-Reply-To: References: Message-ID: <20160616113416.GD1339light@light> Thu, Jun 16, 2016 at 03:06:24PM +0530, Glen Kent wrote: > Thanks i will. However, the doubt is that what does introducing a 16 byte > data into the steam does that causes the session to time out. I added > instrumentation to push some dummy data so that instead of 16 bytes, we > push 1 MB of data. In that case i saw no issues. Any idea if there is a > firewall setting that could be coming into play here? Collect TCP dumps from both sides, come back and show that (or analyze yourself ;) -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From randy at psg.com Thu Jun 16 11:39:15 2016 From: randy at psg.com (Randy Bush) Date: Thu, 16 Jun 2016 20:39:15 +0900 Subject: RPKI implementation In-Reply-To: References: Message-ID: > When a cache loses connectivity, the entries from that cache > are purged after a time interval. Default is 60 seconds why not the poll interval for that cache server? randy From randy at psg.com Thu Jun 16 11:40:32 2016 From: randy at psg.com (Randy Bush) Date: Thu, 16 Jun 2016 20:40:32 +0900 Subject: Strange Problem with 16 byte packets In-Reply-To: References: Message-ID: tcpdump is your friend From jrex at CS.Princeton.EDU Thu Jun 16 11:54:54 2016 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Thu, 16 Jun 2016 07:54:54 -0400 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: <6DF88AAE-D644-4BA5-954C-28B2C29F7F50@cs.princeton.edu> > I do think p4 is very interesting, but is it really much different from > openflow? Which...umm ... Did not succeed in the market. P4 is quite different from OpenFlow. The various generations of the OpenFlow specification assume a fixed-format packet header with an ever increasing number of header fields (from 12 in OF 1.0 to 41 in OF 1.4), a fixed set of packet-processing actions, and so on. P4 allows programmable parsing and flexible match-action processing. In P4, the program tells the data plane how to act; in OpenFlow, the way the data plane can act is ?baked? in advance. So, OpenFlow 1.x can be one of many *programs* you can write in P4, whereas many other P4 programs can exist. For some discussion of the differences, see Clarifying the differences between P4 and OpenFlow http://p4.org/p4/clarifying-the-differences-between-p4-and-openflow/ ? Jen From prem at barefootnetworks.com Thu Jun 16 06:05:50 2016 From: prem at barefootnetworks.com (Prem Jonnalagadda) Date: Wed, 15 Jun 2016 23:05:50 -0700 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: On Wed, Jun 15, 2016 at 8:31 PM, Ca By wrote: > On Wednesday, June 15, 2016, Eric Kuhnke wrote: > > > a lot of PR fluff, but this may be of interest: > > > > > > > http://www.wired.com/2016/06/barefoot-networks-new-chips-will-transform-tech-industry/ > > > > > > > https://barefootnetworks.com/media/white_papers/Barefoot-Worlds-Fastest-Most-Programmable-Networks.pdf > > > > > > Based on their investors, could have interesting results for much lower > > cost 100GbE whitebox switches. > > > > Where is the price tag? Why would you think it is inexpensive? > > I do think p4 is very interesting, but is it really much different from > openflow? Great question! OpenFlow enabled decoupling of the control plane from the data plane, whereas P4 allows you to define the data plane. Check out this popular P4 program that defines the data plane of a L2/L3 switch - https://github.com/p4lang/switch/tree/master/p4src OpenFlow is a protocol, whereas P4 is a programming language. You can use OpenFlow controller to control a P4 data plane - Check out this OpenFlow agent on top of a P4 data plane - https://github.com/p4lang/p4ofagent Check out this blog post which explains the differences between P4 and OpenFlow quite well - http://p4.org/p4/clarifying-the-differences-between-p4-and-openflow/ More questions? Shoot me an email :-) Which...umm ... Did not succeed in the market. > From zbynek at dialtelecom.cz Thu Jun 16 10:21:35 2016 From: zbynek at dialtelecom.cz (=?UTF-8?B?WmJ5bsSbayBQb3Nww61jaGFs?=) Date: Thu, 16 Jun 2016 12:21:35 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): > Well, the customers also wanted more functions and features. They wanted > sFLOW statistics to show traffic, customer portals, better SLAs, > distributed IXes, remote peering, more hand-holding when connecting etc. Are you sure they still want them if they have to pay for these features separately? Currently, such luxury functions are increasing costs also for networks who don't need/want it. Best Regards, Zbynek From colton.conor at gmail.com Thu Jun 16 12:40:13 2016 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 16 Jun 2016 07:40:13 -0500 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: Saku, I agree completely. Isn't this what Arista did? They coded from like 2004 to 2008 before launching EOS using commercial chipsets. You seem to really understand routing software, so I would love to hear your take on Arista EOS. On Thu, Jun 16, 2016 at 3:19 AM, Saku Ytti wrote: > On 16 June 2016 at 06:21, Eric Kuhnke wrote: > > Based on their investors, could have interesting results for much lower > > cost 100GbE whitebox switches. > > Why lower cost? The BOM isn't the expensive part, the code is the > expensive part. Only way I see this happening, is if we get open > source routing suite for the box, i.e. 0 cost software. > > If you're thinking of writing your own routing suite, even if your > requirements are trivial, it's still probably take 2-3 years and > +2MUSD in salaries, and then maintenance +300kUSD/year in salaries. > Need quite significant annual unit number scale to make it cheap. > > I'm quite fascinated by the idea of doing something really novel in > routing suite space, but I don't see how it could possibly work > commercially. How many customers would there be for licensing COTS > routing-suite when costs are millions annually to develop it for > general use-case. > > -- > ++ytti > From cb.list6 at gmail.com Thu Jun 16 13:03:08 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 16 Jun 2016 06:03:08 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> Message-ID: On Thursday, June 16, 2016, Owen DeLong wrote: > > Cough cough ARIN cough. I don't know why they need to meet face to face 2 > > or 3 times a year. But, i am sure ppml will tell you it is a ground up > > process and these people on ppml like traveling and talking about > > policy.... And they do what members want. > > I don?t speak for the organization or even for the Advisory Council, but I > can > tell you that we get more focused community input and participation during > those > face to face meetings than we do during the rest of the year. > > Like it or not, when trying to get interactive participation from more > than 5 or so people, > there?s really no useful substitute for the face-to-face meeting. Every > existing > alternative is less useful and comes with significant drawbacks. > > So, yes, I believe ARIN does what the members want, but more importantly, I > believe that the face to face meetings are a useful mechanism to preserve > the > bottom up nature of the policy development process. > > > Much of our industry can be gleened by googling pictures of "peering > > cruise". At my office, we joke about that a lot. Peering cruise ?jeeshhh. > > I suppose you can joke about anything you want. Personally, I?ve never > been on a > peering cruise, but I will say that it?s a pretty classic fallacy to > discount the > value of the social times at conferences. In fact, I find those times to > often > be when most of the real work gets done and when most of the benefit of > getting > everyone together in the same place is realized. > > While NANOG puts on a good technical program, my company gets far more > benefit from > the time I spend meeting with network partners, suppliers, and potential > customers > during the conference than they will ever see from my time in the > sessions. So much > so that I generally attend the sessions on an as-available basis when I?m > not able > to schedule a more useful meeting. There are, of course exceptions. Some > of the > sessions (maybe 3-4 per conference) are worth holding my time open to > attend, but > most are not. > > This does not mean that I don?t consider NANOG valuable, just that the > primary value > is in the ability to meet with other attendees rather than directly in the > technical > program itself. > > I don?t mean this to be insulting to NANOG. I think the PC generally does > a fine job > of putting on a good conference with great content. Most importantly, it?s > good enough > that it draws in a large selection of people I need/want to meet with in a > concentrated > time frame in a single location. > > Peering fora, peering cruises, and the like have a similar effect. > > So scoff all you want, but if you imagine that these events are silly > junkets where > nothing gets accomplished, then you are seriously underestimating this > community, IMHO. > > Owen > > > Owen, I agree with most of what you are saying. I'll digress on if arin needs to meet or exist. Perhaps it is me and my sensibilities, perhaps it is my miser corp culture, but i could not even dream of asking to go to Jamaica (arin area) for the last ARIN meeting. I am not alone. Have a look at Ren's comments from http://research.dyn.com/2006/02/lovely-peering-cruise-on-lake/ Posted here: " The Peering Forum is more for peer & IX information distribution and contact refresh across a multi-continent body of participants than it is for initial trial concerns. The invite only nature implies the attendees are actively peering at one or more of the IXs sponsoring portions of the Forum. Many of us, hand raised here, are taking vacation time, covering flights, upgraded cabins, etc. to help remove the conflict of interest concerns. It is unfortunate there is not a link to the agenda as it is jam packed with useful peering focused presentations and more than qualifies this as a business need. Last year dozens of participants interacted for the first time and I?m looking forward to similar introductions later this month. Putting a face to the name helps significantly in this very relationship based role which has more to do with international relations than enable." I am not willing to fork over my pto or personal cash to "remove the conflict of interest" . I'd rather buy transit. And, i am also not willing to spend my corp money with dec-ix or others to send my competitors on a cruise. Unless ... why cant this just be business? That said, i have never been on a peering cruise and all my peering needs are met with peeringdb and email. So it is just business for me, and no i am not going to spend money at an IX that does not see things the way i do. CB From jheitz at cisco.com Thu Jun 16 13:44:09 2016 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 16 Jun 2016 13:44:09 +0000 Subject: RPKI implementation In-Reply-To: References: , Message-ID: <69BE629E-09F1-42BF-87DE-D20EA0873613@cisco.com> That is also configurable. Thanks, Jakob. On Jun 16, 2016, at 4:39 AM, Randy Bush wrote: >> When a cache loses connectivity, the entries from that cache >> are purged after a time interval. Default is 60 seconds > > why not the poll interval for that cache server? > > randy From peter.phaal at gmail.com Thu Jun 16 14:35:15 2016 From: peter.phaal at gmail.com (Peter Phaal) Date: Thu, 16 Jun 2016 07:35:15 -0700 Subject: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon? In-Reply-To: References: Message-ID: On Thu, Jun 16, 2016 at 1:19 AM, Saku Ytti wrote: > On 16 June 2016 at 06:21, Eric Kuhnke wrote: >> Based on their investors, could have interesting results for much lower >> cost 100GbE whitebox switches. > > Why lower cost? The BOM isn't the expensive part, the code is the > expensive part. Only way I see this happening, is if we get open > source routing suite for the box, i.e. 0 cost software. It shouldn't be long before we see open source routing suites (Bird, Quagga, GoBGP, etc) running on Linux (ONL, OS10, OpenSwitch). There is a P4 program that implements the Switch Abstraction Interface (SAI), which provides a common interface, device independent, interface to merchant silicon. http://p4.org/p4/an-open-source-p4-switch-with-sai-support/ A quick way to do interesting things with the programmable data plane is to use P4 to augment the basic switching / routing behavior provided by SAI: moving resources from layer 2 tables to layer 3 tables, adding telemetry, adding additional control capabilities, etc.: http://blog.sflow.com/2016/06/programmable-hardware-barefoot-networks.html From randy at psg.com Thu Jun 16 14:38:35 2016 From: randy at psg.com (Randy Bush) Date: Thu, 16 Jun 2016 23:38:35 +0900 Subject: RPKI implementation In-Reply-To: <69BE629E-09F1-42BF-87DE-D20EA0873613@cisco.com> References: Message-ID: > That is also configurable. >>> When a cache loses connectivity, the entries from that cache >>> are purged after a time interval. Default is 60 seconds >> why not the poll interval for that cache server? i am aware of that. my point was that cache purge default might better be set to cache refresh interval than 60 secs. randy From dave at temk.in Thu Jun 16 14:40:08 2016 From: dave at temk.in (Dave Temkin) Date: Thu, 16 Jun 2016 09:40:08 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: Hi Nurani, Much of what you've asked me below is answered up-thread, so I'm not going to rehash it for the sanity of the others following this discussion. I have snipped what hasn't been. On Thu, Jun 16, 2016 at 8:52 AM, Nurani Nimpuno wrote: > > > I take your point about the Netnod fees (even though I would also like to > point out that we have actually reduced our other port fees for 100mbps, > 1G, remote peering). But I?m not sure why you haven?t brought it to us > directly. Netflix has been at several Netnod meetings in the past, so we > have had plenty of opportunity to discuss this. > Nothing in my presentation said "Netflix seeks to get better port fees". You'll find that I, not once, in my deck or oral presentation, mentioned Netflix. I spoke at length with LINX after the presentation and pointed out that I seek to help the entire market, not just my employer, better understand how IXPs price their services, what things are negotiable, and what things need to change. Call it thinly-veiled, but I didn't even use my employer slide master - this was geared as a community discussion. > And I don?t represent a membership-based IXP. > An important distinction. Poring through http://www.netnod.se/about/documents , there is very little transparency into the actual operations of NetNod. > > If you stop adding value to those networks peering at the IX, you will > slowly become irrelevant. > And therein lies the rub, we (many of us, not just you and I) disagree about what "adding value" is defined as. I'm glad we can have this conversation. > > While some think that a good technical solution would sell itself, I > believe that is a fallacy (not only in the IXP world). Netnod started out > as a very small IXPs with only a few local operators connected to it. And I > strongly believe that if we hadn?t done as much outreach as we do, we > would?ve stayed tiny until this day. > Outreach is fantastic! > > > We work in a similar way with our pricing. (You mention that there is a > lot of negotiations on pricing with IXPs.) I would like to be 100% clear > that for the Netnod IX, we don?t negotiate or give ?sweet deals? to anyone. > We publish our fee schedule and we stick to it. Whenever someone wants a > special deal (which happens often, particularly with the larger customers), > our response is that we treat everyone equally. If you want a cheaper deal, > then another customer is basically funding your reduction. So we don?t do > this. We believe this is more fair and transparent. > That's fantastic, and I agree with this approach. And that's why it's important to make this a community discussion, not a "Netflix and Netnod" discussion. > > As for a general discussion about costs, service levels and IXPs, I think > there is a very interesting discussion that could be had with a more > focused discussion. How do ?we? best serve today's very diverse set of > operators? How does an IXP strike that balance? How do operators best solve > their interconnection needs (through IXPs, private peering, transit etc) > and is that changing? What type of interconnection environment do we > believe best scales Internet growth in the future? What is the total cost > of interconnection, where are the big costs, what are the different models > and where is the whole industry moving? Now THOSE are discussions I > personally would find very valuable! > We agree. I'm really glad that this has sprouted so many threads of discussion. This seems to have kicked off the discussion within the larger community beyond just the four examples, and I think that what we've seen thus far is healthy discourse. From joelja at bogus.com Thu Jun 16 15:05:19 2016 From: joelja at bogus.com (joel jaeggli) Date: Thu, 16 Jun 2016 08:05:19 -0700 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: <91fd16a2-1055-c45c-de4e-474d994570ab@bogus.com> On 6/16/16 12:51 AM, Saku Ytti wrote: > Hey, > > I've been bit poking around trying to find reasonable option for 1GE > L3 full BGP table aggregator. It seems vendors are mostly pushing > Satellite/Fusion for this application. > > I don't really like the added complexity and tight coupling > Satellite/Fusion forces me. I'd prefer standards based routing > redundancy to reduce impact of defects. > > ASR9001 and MX104 are not an options, due to control-plane scale. New > boxes in vendor pipeline are completely ignoring 1GE. > > I've casually talked with other people, and it seems I'm not really > alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much > full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface > VLANs, ipfix or sflow, at least per-port QoS with shaper, martini > pseudowires). > > With tinfoil hat tightly fit on my head, I wonder why vendors are > ignoring 1GE? Are business cases entirely driven now by Amazon, > Google, Facebook and the likes? Are SP volumes so insignificant in > comparison it does not make sense to produce boxes for them? > Heck even 10GE is starting to become problematic, if your application > is anything else than DC, because you can't choose arbitrary optics. There's not a lot of innovation going on in lower end 1G chipsets. The natural consequent of that is that you can build a high-end gig switch or router around a chipset supporting 10Gb/s ports or feeds and speeds your cogs are naturally going to be rather similar to the 10Gb/s offering. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tom at ninjabadger.net Thu Jun 16 15:08:41 2016 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 16 Jun 2016 16:08:41 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: <5762C0F9.6080501@ninjabadger.net> On 16/06/16 15:40, Dave Temkin wrote: > Nothing in my presentation said "Netflix seeks to get better port fees". > You'll find that I, not once, in my deck or oral presentation, mentioned > Netflix. I spoke at length with LINX after the presentation and pointed out > that I seek to help the entire market, not just my employer, better > understand how IXPs price their services, what things are negotiable, and > what things need to change. Call it thinly-veiled, but I didn't even use my > employer slide master - this was geared as a community discussion. I wasn't sure if you were talking on behalf of Netflix either. Mainly because the first thing you said at the Nanog presentation was to correct everyone on your title at Netflix. ;) Rather than alluding to it, letting everyone come to their own conclusion, you'd have been better off just saying it outright. Definitely do not be surprised when anyone's confused as to this fact, however. -- Tom From niels=nanog at bakker.net Thu Jun 16 15:17:19 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jun 2016 17:17:19 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> Message-ID: <20160616151719.GB9938@excession.tpb.net> * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 CEST]: >Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): > >>Well, the customers also wanted more functions and features. They >>wanted sFLOW statistics to show traffic, customer portals, better >>SLAs, distributed IXes, remote peering, more hand-holding when >>connecting etc. > >Are you sure they still want them if they have to pay for these >features separately? > >Currently, such luxury functions are increasing costs also for >networks who don't need/want it. sFlow statistics isn't a luxury function. Neither is remote peering. The others Mikael mentioned are debatable at worst but you'd be telling the membership what they really want rather than listening to them saying what they want. This thread is full of people who have never run large L2 networks stating their opinions on running large L2 networks, and they invariably underestimate their complexity and the logistics required. -- Niels. From randy at psg.com Thu Jun 16 15:56:01 2016 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jun 2016 00:56:01 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160616151719.GB9938@excession.tpb.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: > This thread is full of people who have never run large L2 networks > stating their opinions on running large L2 networks, and they > invariably underestimate their complexity and the logistics required. maybe the complexity and the logistics required are WHY they don't build large L2 networks. SMITH: Doctor, it hurts when I do this. DALE: Don't do that. > sFlow statistics isn't a luxury function. Neither is remote peering. by 'remote peering' do you mean an exchange essentially selling transit? randy From niels=nanog at bakker.net Thu Jun 16 16:07:04 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jun 2016 18:07:04 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: <20160616160704.GC9938@excession.tpb.net> >> This thread is full of people who have never run large L2 networks >> stating their opinions on running large L2 networks, and they >> invariably underestimate their complexity and the logistics required. * randy at psg.com (Randy Bush) [Thu 16 Jun 2016, 17:56 CEST]: >maybe the complexity and the logistics required are WHY they don't build >large L2 networks. SMITH: Doctor, it hurts when I do this. DALE: Don't >do that. Wait. I thought vijay "your solution doesn't scale" gill was a hero of the NANOG community, but now you're telling me that actually scaling up is a sin? >> sFlow statistics isn't a luxury function. Neither is remote peering. >by 'remote peering' do you mean an exchange essentially selling transit? I mean the common practice of connecting via a L2 pseudowire with a provider that has an arrangement with the IXP to do so, rather than putting a router in a datacenter the IXP is in and then connecting to that router with possibly the same provider to the rest of your network. Mikael Abrahamsson probably meant the same thing when he used the term two mails upthread. -- Niels. From will at harg.net Thu Jun 16 16:56:36 2016 From: will at harg.net (Will Hargrave) Date: Thu, 16 Jun 2016 17:56:36 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> Message-ID: <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> On 15 Jun 2016, at 19:23, Sander Steffann wrote: >> So here we are now... Where do we want to go? > I think IXPs have indeed become too much like ISPs, providing more > services but also increasing complexity and cost. I prefer simple, > scalable and cheap solutions! > I want to go to an IXP being a nice simple ethernet switch. Add some > nice graphs and a route server, and we're done. Redundancy is a > separate switch :) (I spoke on this topic in the session - I regret insufficiently coherently, but I?ll try again) Most of the major IXs in the European market operate in multiple datacentres. Why? Because it decreases the monopoly conferred upon one particular datacentre in a market which becomes the ?go to? location. Dan Golding disagreed with me but I can certainly speak for LONAP where I feel our mission of ?promoting efficient interconnection in the UK? is hugely enhanced by our ability to provide services in any of our current seven datacentres, across four different operators. London would not be the great city of interconnection it is without the east London cluster of DCs from different operators. We have had a fair few single site IXs in London - e.g. the now defunct RBEIX, Sovex, Meriex. I don?t think it is a viable model for an IXP in a well-developed market. Then there is another concern. What?s the plan for SIX if the Westin Building colo is sold to someone less benevolent and co-operative? I am really pleased their current arrangement seems to work well for SIX, its members and datacentre partners. I think our own members would be less comfortable with that level of risk. Will From asr at latency.net Thu Jun 16 17:58:20 2016 From: asr at latency.net (Adam Rothschild) Date: Thu, 16 Jun 2016 13:58:20 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160616151719.GB9938@excession.tpb.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: I think a fresh conversation is needed around what makes up a "minimally viable" feature set for an IXP: The days of an IXP "needing" to engineer and support a multi-tenant sFlow portal, because the only other option is shelling out the big bucks for Arbor, have long passed -- overlooking the plethora of open sourced tools, folk like Kentik have broken into that market with rationally priced commercial alternatives. Likewise, one might argue that offering layer-2 and layer-3 (!) VPNs is at best non-essential, and a distraction that fuels purchasing very expensive hardware, and at worse competitive with customers. On the other hand, building out a metro topology to cover all relevant carrier hotels, with reasonable path diversity, is absolutely table stakes. And outreach is a great function, *when* it nets unique new participants. To cite a recent example, the various R&E networks and smaller broadband and mobile providers showing up here in the US, due to excellent efforts by the NYIIX and DE-CIX teams. At the end of the day, IXP peering must be significantly cheaper than transit alternatives, many of which are priced based on utilization (as opposed to port capacity). We can dance around this point all we want, but absent a change in trajectory, I worry some IXPs will ultimately price themselves out of the market, and all the gold-plated features in the world won't satiate those making purchasing decisions. $0.02, -a On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker wrote: > * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 CEST]: >> >> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): >> >>> Well, the customers also wanted more functions and features. They wanted >>> sFLOW statistics to show traffic, customer portals, better SLAs, distributed >>> IXes, remote peering, more hand-holding when connecting etc. >> >> >> Are you sure they still want them if they have to pay for these features >> separately? >> >> Currently, such luxury functions are increasing costs also for networks >> who don't need/want it. > > > sFlow statistics isn't a luxury function. Neither is remote peering. The > others Mikael mentioned are debatable at worst but you'd be telling the > membership what they really want rather than listening to them saying what > they want. > > This thread is full of people who have never run large L2 networks stating > their opinions on running large L2 networks, and they invariably > underestimate their complexity and the logistics required. > > > -- Niels. From zbynek at dialtelecom.cz Thu Jun 16 18:19:22 2016 From: zbynek at dialtelecom.cz (=?UTF-8?B?WmJ5bsSbayBQb3Nww61jaGFs?=) Date: Thu, 16 Jun 2016 20:19:22 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160616151719.GB9938@excession.tpb.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: Dne 16.06.16 v 17:17 Niels Bakker napsal(a): > * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 CEST]: >> Are you sure they still want them if they have to pay for these >> features separately? >> >> Currently, such luxury functions are increasing costs also for >> networks who don't need/want it. > > sFlow statistics isn't a luxury function. Anything more than plain L2 in an IXP is a kind of luxury. An IXP member with it's own flow collection (or at least mac accounting) can feel they don't need sFlow statistics in an exchange. It's also proven it's possible to run an IXP, including a big one, without sFlow stats. We can say the same about route servers, SLA, customer portals etc. (ok, remote peering is a different case). If IXP members think they have to pay such functionality in their port fees, ok, it's their own decision, but member's opinion "we don't need it and we don't want to pay for it" is rational and plausible. Best Regards, Zbynek From dwessels at verisign.com Thu Jun 16 18:43:13 2016 From: dwessels at verisign.com (Wessels, Duane) Date: Thu, 16 Jun 2016 18:43:13 +0000 Subject: Call for Presentations - DNS-OARC Fall Workshop, Dallas, Oct. 2016 Message-ID: [with apologies to those who see this on multiple lists] Call for Presentations As announced at the close of NANOG67, the DNS-OARC 25th Workshop will take place in Dallas, Texas during October 15th and 16th 2016, the Saturday and Sunday before NANOG68. To attract the best DNS minds, DNS-OARC is requesting proposals for presentations, with a preference for Resolver's Operations experiences, including running DNSSEC validating resolvers. This workshop intends to build from previous strong DNS-OARC workshops, where both operational content and research are welcome. All DNS-related subjects are accepted. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. A timeslot will be available for lightning talks (5-10 minutes) on Sunday October 16th, for which submissions will be accepted during October 15th on a first-come first-served basis. Workshop Milestones 15th June 2016, Call for Presentations posted and open for submissions 14th August 2016, Deadline for submission 1st September 2016, Final Program published 10th October 2016, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/25/call-for-abstracts/ 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 ensure the quality of the workshop, submissions should include slides. Draft slides are acceptable on submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, 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 nanog at ics-il.net Thu Jun 16 18:43:11 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 16 Jun 2016 13:43:11 -0500 (CDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: <147580931.59483.1466102586782.JavaMail.mhammett@ThunderFuck> I think that's a very limited mindset. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Zbyn?k Posp?chal" To: nanog at nanog.org Sent: Thursday, June 16, 2016 1:19:22 PM Subject: Re: NANOG67 - Tipping point of community and sponsor bashing? Dne 16.06.16 v 17:17 Niels Bakker napsal(a): > * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 CEST]: >> Are you sure they still want them if they have to pay for these >> features separately? >> >> Currently, such luxury functions are increasing costs also for >> networks who don't need/want it. > > sFlow statistics isn't a luxury function. Anything more than plain L2 in an IXP is a kind of luxury. An IXP member with it's own flow collection (or at least mac accounting) can feel they don't need sFlow statistics in an exchange. It's also proven it's possible to run an IXP, including a big one, without sFlow stats. We can say the same about route servers, SLA, customer portals etc. (ok, remote peering is a different case). If IXP members think they have to pay such functionality in their port fees, ok, it's their own decision, but member's opinion "we don't need it and we don't want to pay for it" is rational and plausible. Best Regards, Zbynek From hannigan at gmail.com Thu Jun 16 19:24:04 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 16 Jun 2016 14:24:04 -0500 Subject: IXP economics Was: Re: NANOG67 - Tipping point of community and sponsor bashing? Message-ID: Well. Its complicated. I think this is far more political than about COGS. But hey. Why not? I agree with Dave. Shocking. I know. At least the context. He's right. Thanks for reminding us. We know these things. We'll have to see how IXP communities react now. Perhaps espresso service will be defined as good outreach? If it is, thats certainly up to them. Btw, have you thanked your local US branded euro IXP? They created market pressures that saved many of us a Brinks truck full of cash by increasing competitiveness. A lot of us owe them thanks and support for doing good. If you do, grab Job, John, Henk, Pauline, Arnold or Andreas and give them a big COGS crushing hug. Go easy on Pauline, less crush please. Best, Marty On Thursday, June 16, 2016, Zbyn?k Posp?chal wrote: > Dne 16.06.16 v 17:17 Niels Bakker napsal(a): > > * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun > 2016, 14:23 CEST]: > > >> Are you sure they still want them if they have to pay for these > >> features separately? > >> > >> Currently, such luxury functions are increasing costs also for > >> networks who don't need/want it. > > > > sFlow statistics isn't a luxury function. > > Anything more than plain L2 in an IXP is a kind of luxury. An IXP member > with it's own flow collection (or at least mac accounting) can feel they > don't need sFlow statistics in an exchange. It's also proven it's > possible to run an IXP, including a big one, without sFlow stats. > > We can say the same about route servers, SLA, customer portals etc. (ok, > remote peering is a different case). > > If IXP members think they have to pay such functionality in their port > fees, ok, it's their own decision, but member's opinion "we don't need > it and we don't want to pay for it" is rational and plausible. > > Best Regards, > Zbynek > From baldur.norddahl at gmail.com Thu Jun 16 19:36:13 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 16 Jun 2016 21:36:13 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: Hi If I need to speak BGP with a customer that only has 1G I will simply make a MPLS L2VPN to one of my edge routers. We use the ZTE 5952E switch with 48x 1G plus 4x 10G for the L2VPN end point. If that is not enough the ZTE 8900 platform will provide a ton of ports that can do MPLS. The tunnel is automatically redundant and will promote link down events, so there is not really any downside to doing it this way on low bandwidth peers. Regards Baldur Den 16. jun. 2016 09.52 skrev "Saku Ytti" : Hey, I've been bit poking around trying to find reasonable option for 1GE L3 full BGP table aggregator. It seems vendors are mostly pushing Satellite/Fusion for this application. I don't really like the added complexity and tight coupling Satellite/Fusion forces me. I'd prefer standards based routing redundancy to reduce impact of defects. ASR9001 and MX104 are not an options, due to control-plane scale. New boxes in vendor pipeline are completely ignoring 1GE. I've casually talked with other people, and it seems I'm not really alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface VLANs, ipfix or sflow, at least per-port QoS with shaper, martini pseudowires). With tinfoil hat tightly fit on my head, I wonder why vendors are ignoring 1GE? Are business cases entirely driven now by Amazon, Google, Facebook and the likes? Are SP volumes so insignificant in comparison it does not make sense to produce boxes for them? Heck even 10GE is starting to become problematic, if your application is anything else than DC, because you can't choose arbitrary optics. -- ++ytti From saku at ytti.fi Thu Jun 16 20:27:14 2016 From: saku at ytti.fi (Saku Ytti) Date: Thu, 16 Jun 2016 23:27:14 +0300 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: On 16 June 2016 at 22:36, Baldur Norddahl wrote: Hey, > If I need to speak BGP with a customer that only has 1G I will simply make > a MPLS L2VPN to one of my edge routers. We use the ZTE 5952E switch with > 48x 1G plus 4x 10G for the L2VPN end point. If that is not enough the ZTE > 8900 platform will provide a ton of ports that can do MPLS. I wonder if you'd do this, if you could do L3 to the edge. And why is termination technology dependant on termination rate? > The tunnel is automatically redundant and will promote link down events, so > there is not really any downside to doing it this way on low bandwidth > peers. When you say redundant, do you mean that label can take any path between access port and termination IRB/BVI? Or do you actually have termination redundancy? If you don't have termination redundancy, you have two SPOF, access port and termination. If you do have termination redundancy, you're spending control-plane resource from two devices, doubling your control-plane scale/cost. I'm not saying it's bad solution, I know lot of people do it. But I think people only do it, because L3 at port isn't offered by vendors at lower rates. -- ++ytti From baldur.norddahl at gmail.com Thu Jun 16 21:24:15 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 16 Jun 2016 23:24:15 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: On 16 June 2016 at 22:27, Saku Ytti wrote: > On 16 June 2016 at 22:36, Baldur Norddahl > wrote: > > Hey, > > > If I need to speak BGP with a customer that only has 1G I will simply > make > > a MPLS L2VPN to one of my edge routers. We use the ZTE 5952E switch with > > 48x 1G plus 4x 10G for the L2VPN end point. If that is not enough the ZTE > > 8900 platform will provide a ton of ports that can do MPLS. > > I wonder if you'd do this, if you could do L3 to the edge. And why is > termination technology dependant on termination rate? > The ZTE 5952E (routing switch) can do L3VPN including BGP. But it is limited to about 30k routes. It is usable if the customer wants a default route solution, but not if he wants the full default free zone. The ZTE M6000S-2S4 (carrier grade router) will do all you want, however it is more expensive. We use the MPLS routing switch because it is a $2k device compared to the router which is more like $15k. As a small ISP we have two edge routers (the slightly larger M6000-S3 which is about $20k). Our customers are spread out throughout the city and we have 26 PoPs, so it is much more cost effective to have the cheaper device put the traffic in a tunnel and haul it back to the big iron. > > The tunnel is automatically redundant and will promote link down events, > so > > there is not really any downside to doing it this way on low bandwidth > > peers. > > When you say redundant, do you mean that label can take any path > between access port and termination IRB/BVI? Or do you actually have > termination redundancy? > Our PoPs are connected in a ring topology (actually multiple rings). If a link goes down somewhere, or an intermediate device crashes, the L2VPN will reconfigure and find another path. > If you don't have termination redundancy, you have two SPOF, access > port and termination. > For a BGP customer I could offer two tunnels, one to each of our provider edge routers. But very few of our customers are BGP customers, they just want normal internet. For them we do VRRP between the two provider edge routers and have the one tunnel go to both. > If you do have termination redundancy, you're spending control-plane > resource from two devices, doubling your control-plane scale/cost. > The M6000 devices can handle 64k tunnels and are generally way overpowered for our current business. It is true that I might be limited to 1x 64k customers instead of 2x 64k customers, but with that many customers I would need to upgrade anyway. > I'm not saying it's bad solution, I know lot of people do it. But I > think people only do it, because L3 at port isn't offered by vendors > at lower rates. > We actually moved away from a hybrid solution with L3 termination at the customer edge to simply backhauling everything in L2VPNs. We did this because the L2VPN tunnels are needed anyway for other reasons and it is easier to have one way to do things. Regards, Baldur From nurani at netnod.se Thu Jun 16 13:52:02 2016 From: nurani at netnod.se (Nurani Nimpuno) Date: Thu, 16 Jun 2016 15:52:02 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> Message-ID: <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Hi Dave, So, I watched your presentation this week at NANOG remotely, sorry I couldn?t be there. Ok, so while you make a lot of very different points in your presentations, I *think* the basic argument you are making is that IXPs are too expensive. Correct me if I?m wrong. Or more specifically, you are saying that Ams-IX, Linx, Netnod and DE-CIX are too expensive. You have not looked at US IXPs because they don?t publish their fees, and you have not looked at the whole IXP community. I think you are then also questioning if these IXPs are using their funds wisely. You are also stating that you are talking about these IXPs from the perspective of a big US provider connecting into Europe (i.e not a small local ISP). You question some of the IXP expansions into the US. You question the membership model as a viable model for IXPs. You also say that those who sustain the IXPs growth should benefit from them. And you question why there are so many IXPs, and not only a handful of very big ones. I hope I have captured this correctly. Ok, so firstly, I must say I?m a little disappointed that you or your staff have never approach us to discuss any of this. We have Netnod meetings twice a year, we have been present at many of the same events in the last year and we have always strived to be open, transparent and to listen to our entire customer base. I take your point about the Netnod fees (even though I would also like to point out that we have actually reduced our other port fees for 100mbps, 1G, remote peering). But I?m not sure why you haven?t brought it to us directly. Netflix has been at several Netnod meetings in the past, so we have had plenty of opportunity to discuss this. But ok, let?s leave that aside. I will try to address some of your points. Firstly as many have pointed out, these four IXPs are not representative of all IXPs, and the four of us are also very different from each other. I can?t address the IXP expansion into the US. And I don?t represent a membership-based IXP. The European IXP community is a very diverse one, serving different regions, markets and different types of customers. I personally believe that this rich diversity is one of the reasons the European interconnection scene has been flourishing as well as it has. There is a big difference between Europe and the rest of the world, particularly the US. And the European IXP community was held up as a model for the rest of the world by many. We have been cooperating for many years through the Euro-IX where our common goals have been to improve interconnection in the region, share information and experience and work to improve services for our customers. (I believe you have been trying to do the same through Open-IX.) The diversity has also been seen as important to serve both the very large international providers like yourself, and the small local ISPs. Localising traffic and building a local operator community have been seen as an important ingredient in the value of the IXPs. Our challenge as IXPs is to find the best way to serve all these different needs and wishes from our very diverse customer base. Having only a handful of very large IXPs would in my view not serve these different needs as well. Personally I am a subscriber to both Netflix and HBO. I like diversity. :) But sure, it?s an interesting discussion to be had! As others have pointed out, contrary to common belief, the technical part of an IXP is one of the simplest. There is a plethora of examples of IXPs in Africa, but also in the US, where IXPs simply are a single switch sitting in a closet somewhere, only serving a handful of ASes. One of the biggest challenges for an IXP is to gain customers and get enough gravitation and value to the exchange. A growing exchange point is not only a "nice-to-have" for those operating it, but vital to those networks who peer there. If you stop adding value to those networks peering at the IX, you will slowly become irrelevant. While some think that a good technical solution would sell itself, I believe that is a fallacy (not only in the IXP world). Netnod started out as a very small IXPs with only a few local operators connected to it. And I strongly believe that if we hadn?t done as much outreach as we do, we would?ve stayed tiny until this day. As for how we do this outreach and what events we go to, while I can?t speak for any other IXes, I seriously doubt that any professional IXP today would not carefully assess the business value for each event it attends. At Netnod, we evaluate each event we send people to, and assess and measure the value afterwards. Then I thought I would write some words about Netnod specifically since you bring us up. (As others have pointed out, the RIPE meeting social is covered partly by the RIPE NCC, partly by the sponsor, and partly by the participants themselves, so I?ll just leave that there.) Firstly, yes we are a little strange. We are not just an IXP. We run i-root.servers.net and we provide DNS anycast service, among other things. We also have a funny governance structure for historical reasons (which was set up when Netnod was established and the IXP and I-root ?moved? there) many years ago. We are owned by a foundation and we describe ourselves as non-profit. In Sweden there is actually no ?non-profit? status as such, but we have always operated under that principle. We are not a membership organisation, but we have always strived to be transparent, and whenever we have wanted to make major changes to our services, we have consulted the customer base. That is how we have worked on both the IX and DNS side. We work in a similar way with our pricing. (You mention that there is a lot of negotiations on pricing with IXPs.) I would like to be 100% clear that for the Netnod IX, we don?t negotiate or give ?sweet deals? to anyone. We publish our fee schedule and we stick to it. Whenever someone wants a special deal (which happens often, particularly with the larger customers), our response is that we treat everyone equally. If you want a cheaper deal, then another customer is basically funding your reduction. So we don?t do this. We believe this is more fair and transparent. Coming back to Netnod's broader scope, this also means that we do other things than sell peering. We go to, and sponsor events that might not make sense from a peering perspective. We support other ?Good of the Internet? initiatives, we participate in standards development (particularly on the DNS side), we participate in TLD associations etc. Some of these activities may seem odd to some who are only involved with one part of our business, I understand that. We try to be open with this though. As for a general discussion about costs, service levels and IXPs, I think there is a very interesting discussion that could be had with a more focused discussion. How do ?we? best serve today's very diverse set of operators? How does an IXP strike that balance? How do operators best solve their interconnection needs (through IXPs, private peering, transit etc) and is that changing? What type of interconnection environment do we believe best scales Internet growth in the future? What is the total cost of interconnection, where are the big costs, what are the different models and where is the whole industry moving? Now THOSE are discussions I personally would find very valuable! Cheers, Nurani Netnod > On 15 juni 2016, at 13:21, Dave Temkin wrote: > > On Wed, Jun 15, 2016 at 3:43 AM, Aled Morris wrote: > >> >> >> Me too and I was confused about what the point of it was. >> >> I had always assumed the customers of those IXs he singled out were >> generally happy with the service they were getting and the money they are >> paying. >> >> Is Dave trying to say they are being duped? Is he trying to identify a >> need for regulation? >> > > I was pointing out facts about IXPs that many did not know, including the > actual organizational structure. > > I was also opining on how these IXPs could be better; mainly, how they > choose to spend money. > > > >> >> Perhaps Dave was advocating the SIX model and suggesting the customers of >> the existing exchanges should be looking to organise an alternative in >> their localities. >> > > Absolutely correct (which should answer Hank's question, as well). > > >> >> Or perhaps this is a wakeup call for LoNAP and the smaller exchanges who >> "compete" with AMS-IX, DE-CIX and NetNod - stop trying to mimic their >> commercial models (big fees which pay for staff and marketing) and look >> instead at the lean SIX as the way of offering a service at a price >> competitive to transit. >> > > Also absolutely correct. I don't want to see them falling into a trap of > conflating marketing and outreach and/or offering an overly rich product > set at the cost of price and operational simplicity. > > >> Or was there a hidden message in Dave's presentation that I missed? >> > > Seems like you got it. > > >> Aled >> > From job at instituut.net Thu Jun 16 22:55:52 2016 From: job at instituut.net (Job Snijders) Date: Thu, 16 Jun 2016 17:55:52 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: <20160616225552.GK89698@dhcp-223-209.meetings.nanog.org> On Thu, Jun 16, 2016 at 03:52:02PM +0200, Nurani Nimpuno wrote: > A growing exchange point is not only a "nice-to-have" for those > operating it, but vital to those networks who peer there. If you stop > adding value to those networks peering at the IX, you will slowly > become irrelevant. I view this differently: an IXP that does not grow, still provides value to the existing members/customers. The value is not growth itself, just like the amount of connected networks is not a metric for value, but a metric for the potential of value. The value an IXP brings can be defined as the delta between what it would cost to 'do it yourself' and run everything over private peering and using a public internet exchange. And this definition of value is underlined by the fact that a "public to private" lifecycle exists. > We work in a similar way with our pricing. (You mention that there is > a lot of negotiations on pricing with IXPs.) I would like to be 100% > clear that for the Netnod IX, we don?t negotiate or give ?sweet deals? > to anyone. We publish our fee schedule and we stick to it. This is an admirable quality. I believe an IXP is most successful when it presents a level playing field. Hope you never change this :) Kind regards, Job From pr at isprime.com Thu Jun 16 23:06:33 2016 From: pr at isprime.com (Phil Rosenthal) Date: Thu, 16 Jun 2016 19:06:33 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> Message-ID: <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> Hello all, I wasn't able to attend NANOG this time around, but watched Dave Temkin's presentation on youtube. My comments are: 1) Over the past 5 years: My cost for switch/router ports have gone down a lot. My cost for transit has gone down a lot. My cost for exchange ports have gone down, but not quite as fast as my transit and switch/router ports, and this does lead to some value questions. Dave is right to ask them. However: exchange port fees are not my biggest enemy today. My cross connect fees have not gone down *at all*. On a proportion basis, cross connect fees have gone from "not mattering" to being an important part of any deployment cost calculation. Why aren't we raising hell about cross connect fees? 2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on an exchange. If it could be done 'free' with commodity hardware, then fine -- but if it translates to requiring Big Expensive Routers instead of a cheaper but fast switch, this should translate to higher pricing for the customers requiring these exotic features -- not the customers who just want a big L2 vlan. 3) Remote peering -- This is mostly a question about distance for value. There is a clear benefit in providing multi-datacenter exchanges within a metro, and both FL-IX and SIX are doing this with a very good value proposition. Having the ability to join DECIX Frankfurt from NYC and vice versa -- again, this is a bizarre service to be offered, and regular users should not be expected to pay for this. If there is a market for these services at an unsubsidized price, then fine -- but regular members should not be subsidizing this service. 4) sFlow -- I'm not sure why this is even really a topic. Commodity hardware does have sFlow capability, and FLIX demonstrates this well. With that said, for us, it is of extremely limited value. We might check these graphs to validate measurements of our internal netflow/sflow graphing systems, but generally, I look at the graphs generated by my exchange vendors less than once per year per exchange. I am honestly not even sure if SIX offers this service, as I never had a reason to check. 5) Marketting vs Outreach: These things are honestly basically the same thing, mostly separated by the question of "is it good marketing or not". I like having more members at the exchanges I am a member of. If it translates to an additional 3% per year to have an additional 5% of traffic to new members, I am fine with this. If it translates to an extra 50% of cost for 5% of additional traffic, I am not fine with it. Finally -- there is nothing wrong with asking questions. If you are an exchange company and you can defend your prices for what you offer, then there is no problem. If you are an exchange and are mostly just hoping nobody asks the questions because you won't have any good answers -- well, I think this is exactly why Dave asked the question. Best Regards, -Phil Rosenthal > On Jun 16, 2016, at 1:58 PM, Adam Rothschild wrote: > > I think a fresh conversation is needed around what makes up a > "minimally viable" feature set for an IXP: > > The days of an IXP "needing" to engineer and support a multi-tenant > sFlow portal, because the only other option is shelling out the big > bucks for Arbor, have long passed -- overlooking the plethora of open > sourced tools, folk like Kentik have broken into that market with > rationally priced commercial alternatives. Likewise, one might argue > that offering layer-2 and layer-3 (!) VPNs is at best non-essential, > and a distraction that fuels purchasing very expensive hardware, and > at worse competitive with customers. > > On the other hand, building out a metro topology to cover all relevant > carrier hotels, with reasonable path diversity, is absolutely table > stakes. And outreach is a great function, *when* it nets unique new > participants. To cite a recent example, the various R&E networks and > smaller broadband and mobile providers showing up here in the US, due > to excellent efforts by the NYIIX and DE-CIX teams. > > At the end of the day, IXP peering must be significantly cheaper than > transit alternatives, many of which are priced based on utilization > (as opposed to port capacity). We can dance around this point all we > want, but absent a change in trajectory, I worry some IXPs will > ultimately price themselves out of the market, and all the gold-plated > features in the world won't satiate those making purchasing decisions. > > $0.02, > -a > > On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker wrote: >> * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 CEST]: >>> >>> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): >>> >>>> Well, the customers also wanted more functions and features. They wanted >>>> sFLOW statistics to show traffic, customer portals, better SLAs, distributed >>>> IXes, remote peering, more hand-holding when connecting etc. >>> >>> >>> Are you sure they still want them if they have to pay for these features >>> separately? >>> >>> Currently, such luxury functions are increasing costs also for networks >>> who don't need/want it. >> >> >> sFlow statistics isn't a luxury function. Neither is remote peering. The >> others Mikael mentioned are debatable at worst but you'd be telling the >> membership what they really want rather than listening to them saying what >> they want. >> >> This thread is full of people who have never run large L2 networks stating >> their opinions on running large L2 networks, and they invariably >> underestimate their complexity and the logistics required. >> >> >> -- Niels. From eric.kuhnke at gmail.com Thu Jun 16 23:08:49 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 16 Jun 2016 16:08:49 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> Message-ID: On the point raised by this index of IXP costs - has anyone put together a table of information on the opposite side of the question: What is the cost of establishing a PNI direct crossconnect in a major IX point? This varies widely by particular location and which real estate investment company/datacenter developer happens to own a particular property. There's to-remain-unnamed colo & power providers who like to get people into a facility with cheap rack & power and then charge hundreds of dollars per month per fiber pair for a regular 9/125 XC between two racks or cages in the same facility. Others where the cost is $0 monthly and you can pull your own fiber through the overhead trays to establish PNI. Others where you pay monthly rent for your own 144-strand 4U patch panel in a fiber MMR but the XCs between panels are $0/MRC. Also worth knowing for comparison to the spreadsheet in #3 below: To what extent are intra-facility XC costs available without NDAs to publish and share? Which colo facilities consider NRCs and MRCs for fiber XCs to be proprietary information? 3 - > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 From baldur.norddahl at gmail.com Thu Jun 16 23:09:20 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 Jun 2016 01:09:20 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: Hi, I have studied Netnod extensively because we want to become members, but we can not simply because it is too expensive. I just signed a deal with he.net for a flatrate 10G transit for about the same as the 10G Comix port cost. The difference being that the he.net port provides much more value and besides also provides indirect one-step-away peering with everyone on Comix. So from my perspective it is clear that Netnod has a pricing problem here. Especially for the lower speeds (10G). There is also a value problem because the only Comix peer that moves a lot of traffic to us is Akamai, and they promised that we could peer directly skipping the middleman. We are based in Copenhagen. The Netnod IX in Stockholm would provide a lot more value, but to get there we have to add the cost for transport and after doing that, the comparison to the 10G he.net transit is just silly. Here is an opinion: If the IX pricing is comparable to transit, the service needs to be too. Netnod will need to connect the five (I think there are five) Netnod IX'es into one big domain. I am meeting with NL-IX next week and as I understand it, that is exactly what they did - we will probably buy NL-IX and skip Netnod for this single reason. I feel that smaller providers are being let down by the IX community at this point. The value of "smaller" is going to get larger if the IX community does not move with the transit providers. We want to take part but there is a limit of how much over price you can sign onto and keep your job. Regards, Baldur On 16 June 2016 at 15:52, Nurani Nimpuno wrote: > Hi Dave, > > So, I watched your presentation this week at NANOG remotely, sorry I > couldn?t be there. > > Ok, so while you make a lot of very different points in your > presentations, I *think* the basic argument you are making is that IXPs are > too expensive. Correct me if I?m wrong. Or more specifically, you are > saying that Ams-IX, Linx, Netnod and DE-CIX are too expensive. You have not > looked at US IXPs because they don?t publish their fees, and you have not > looked at the whole IXP community. > > I think you are then also questioning if these IXPs are using their funds > wisely. You are also stating that you are talking about these IXPs from the > perspective of a big US provider connecting into Europe (i.e not a small > local ISP). You question some of the IXP expansions into the US. You > question the membership model as a viable model for IXPs. You also say that > those who sustain the IXPs growth should benefit from them. And you > question why there are so many IXPs, and not only a handful of very big > ones. I hope I have captured this correctly. > > Ok, so firstly, I must say I?m a little disappointed that you or your > staff have never approach us to discuss any of this. We have Netnod > meetings twice a year, we have been present at many of the same events in > the last year and we have always strived to be open, transparent and to > listen to our entire customer base. I take your point about the Netnod fees > (even though I would also like to point out that we have actually reduced > our other port fees for 100mbps, 1G, remote peering). But I?m not sure why > you haven?t brought it to us directly. Netflix has been at several Netnod > meetings in the past, so we have had plenty of opportunity to discuss this. > > But ok, let?s leave that aside. I will try to address some of your points. > > Firstly as many have pointed out, these four IXPs are not representative > of all IXPs, and the four of us are also very different from each other. > > I can?t address the IXP expansion into the US. And I don?t represent a > membership-based IXP. > > The European IXP community is a very diverse one, serving different > regions, markets and different types of customers. I personally believe > that this rich diversity is one of the reasons the European interconnection > scene has been flourishing as well as it has. There is a big difference > between Europe and the rest of the world, particularly the US. And the > European IXP community was held up as a model for the rest of the world by > many. We have been cooperating for many years through the Euro-IX where our > common goals have been to improve interconnection in the region, share > information and experience and work to improve services for our customers. > (I believe you have been trying to do the same through Open-IX.) > > The diversity has also been seen as important to serve both the very large > international providers like yourself, and the small local ISPs. Localising > traffic and building a local operator community have been seen as an > important ingredient in the value of the IXPs. Our challenge as IXPs is to > find the best way to serve all these different needs and wishes from our > very diverse customer base. Having only a handful of very large IXPs would > in my view not serve these different needs as well. Personally I am a > subscriber to both Netflix and HBO. I like diversity. :) But sure, it?s an > interesting discussion to be had! > > As others have pointed out, contrary to common belief, the technical part > of an IXP is one of the simplest. There is a plethora of examples of IXPs > in Africa, but also in the US, where IXPs simply are a single switch > sitting in a closet somewhere, only serving a handful of ASes. One of the > biggest challenges for an IXP is to gain customers and get enough > gravitation and value to the exchange. A growing exchange point is not only > a "nice-to-have" for those operating it, but vital to those networks who > peer there. If you stop adding value to those networks peering at the IX, > you will slowly become irrelevant. > > While some think that a good technical solution would sell itself, I > believe that is a fallacy (not only in the IXP world). Netnod started out > as a very small IXPs with only a few local operators connected to it. And I > strongly believe that if we hadn?t done as much outreach as we do, we > would?ve stayed tiny until this day. > > As for how we do this outreach and what events we go to, while I can?t > speak for any other IXes, I seriously doubt that any professional IXP today > would not carefully assess the business value for each event it attends. At > Netnod, we evaluate each event we send people to, and assess and measure > the value afterwards. > > Then I thought I would write some words about Netnod specifically since > you bring us up. > > (As others have pointed out, the RIPE meeting social is covered partly by > the RIPE NCC, partly by the sponsor, and partly by the participants > themselves, so I?ll just leave that there.) > > Firstly, yes we are a little strange. We are not just an IXP. We run > i-root.servers.net and we provide DNS anycast service, among other > things. We also have a funny governance structure for historical reasons > (which was set up when Netnod was established and the IXP and I-root > ?moved? there) many years ago. We are owned by a foundation and we describe > ourselves as non-profit. In Sweden there is actually no ?non-profit? status > as such, but we have always operated under that principle. We are not a > membership organisation, but we have always strived to be transparent, and > whenever we have wanted to make major changes to our services, we have > consulted the customer base. That is how we have worked on both the IX and > DNS side. > > We work in a similar way with our pricing. (You mention that there is a > lot of negotiations on pricing with IXPs.) I would like to be 100% clear > that for the Netnod IX, we don?t negotiate or give ?sweet deals? to anyone. > We publish our fee schedule and we stick to it. Whenever someone wants a > special deal (which happens often, particularly with the larger customers), > our response is that we treat everyone equally. If you want a cheaper deal, > then another customer is basically funding your reduction. So we don?t do > this. We believe this is more fair and transparent. > > Coming back to Netnod's broader scope, this also means that we do other > things than sell peering. We go to, and sponsor events that might not make > sense from a peering perspective. We support other ?Good of the Internet? > initiatives, we participate in standards development (particularly on the > DNS side), we participate in TLD associations etc. Some of these activities > may seem odd to some who are only involved with one part of our business, I > understand that. We try to be open with this though. > > As for a general discussion about costs, service levels and IXPs, I think > there is a very interesting discussion that could be had with a more > focused discussion. How do ?we? best serve today's very diverse set of > operators? How does an IXP strike that balance? How do operators best solve > their interconnection needs (through IXPs, private peering, transit etc) > and is that changing? What type of interconnection environment do we > believe best scales Internet growth in the future? What is the total cost > of interconnection, where are the big costs, what are the different models > and where is the whole industry moving? Now THOSE are discussions I > personally would find very valuable! > > Cheers, > > Nurani > Netnod > > > > > > On 15 juni 2016, at 13:21, Dave Temkin wrote: > > > > On Wed, Jun 15, 2016 at 3:43 AM, Aled Morris wrote: > > > >> > >> > >> Me too and I was confused about what the point of it was. > >> > >> I had always assumed the customers of those IXs he singled out were > >> generally happy with the service they were getting and the money they > are > >> paying. > >> > >> Is Dave trying to say they are being duped? Is he trying to identify a > >> need for regulation? > >> > > > > I was pointing out facts about IXPs that many did not know, including the > > actual organizational structure. > > > > I was also opining on how these IXPs could be better; mainly, how they > > choose to spend money. > > > > > > > >> > >> Perhaps Dave was advocating the SIX model and suggesting the customers > of > >> the existing exchanges should be looking to organise an alternative in > >> their localities. > >> > > > > Absolutely correct (which should answer Hank's question, as well). > > > > > >> > >> Or perhaps this is a wakeup call for LoNAP and the smaller exchanges who > >> "compete" with AMS-IX, DE-CIX and NetNod - stop trying to mimic their > >> commercial models (big fees which pay for staff and marketing) and look > >> instead at the lean SIX as the way of offering a service at a price > >> competitive to transit. > >> > > > > Also absolutely correct. I don't want to see them falling into a trap of > > conflating marketing and outreach and/or offering an overly rich product > > set at the cost of price and operational simplicity. > > > > > >> Or was there a hidden message in Dave's presentation that I missed? > >> > > > > Seems like you got it. > > > > > >> Aled > >> > > > > From eric.kuhnke at gmail.com Thu Jun 16 23:17:51 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 16 Jun 2016 16:17:51 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> Message-ID: > However: exchange port fees are not my biggest enemy today. My cross connect fees have not gone down *at all*. On a proportion basis, cross connect fees have gone from "not mattering" to being an important part of any deployment cost calculation. Why aren't we raising hell about cross connect fees? IMHO we should be, in the spirit of: https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party Assuming the existence of overhead fiber trays throughput, when you consider the actual cost of a two strand XC between two cages in the same facility: 30 meter SC-SC duplex 9/125 G.657.A1 cable: $11 There should be a community effort to lobby facility managers and colo/IX real estate management that the value of their facility will be greater if XCs are free or nearly free, resulting in higher occupancy and a greater critical mass of carriers, rather than trying to extract revenue from the tenants by $300/mo MRC per fiber pair between two racks. On Thu, Jun 16, 2016 at 4:06 PM, Phil Rosenthal wrote: > Hello all, > > I wasn't able to attend NANOG this time around, but watched Dave Temkin's > presentation on youtube. > > My comments are: > 1) Over the past 5 years: > My cost for switch/router ports have gone down a lot. > My cost for transit has gone down a lot. > My cost for exchange ports have gone down, but not quite as fast as my > transit and switch/router ports, and this does lead to some value > questions. Dave is right to ask them. > > However: exchange port fees are not my biggest enemy today. My cross > connect fees have not gone down *at all*. On a proportion basis, cross > connect fees have gone from "not mattering" to being an important part of > any deployment cost calculation. Why aren't we raising hell about cross > connect fees? > > 2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on an > exchange. If it could be done 'free' with commodity hardware, then fine -- > but if it translates to requiring Big Expensive Routers instead of a > cheaper but fast switch, this should translate to higher pricing for the > customers requiring these exotic features -- not the customers who just > want a big L2 vlan. > > 3) Remote peering -- This is mostly a question about distance for value. > There is a clear benefit in providing multi-datacenter exchanges within a > metro, and both FL-IX and SIX are doing this with a very good value > proposition. Having the ability to join DECIX Frankfurt from NYC and vice > versa -- again, this is a bizarre service to be offered, and regular users > should not be expected to pay for this. If there is a market for these > services at an unsubsidized price, then fine -- but regular members should > not be subsidizing this service. > > 4) sFlow -- I'm not sure why this is even really a topic. Commodity > hardware does have sFlow capability, and FLIX demonstrates this well. With > that said, for us, it is of extremely limited value. We might check these > graphs to validate measurements of our internal netflow/sflow graphing > systems, but generally, I look at the graphs generated by my exchange > vendors less than once per year per exchange. I am honestly not even sure > if SIX offers this service, as I never had a reason to check. > > 5) Marketting vs Outreach: These things are honestly basically the same > thing, mostly separated by the question of "is it good marketing or not". I > like having more members at the exchanges I am a member of. If it > translates to an additional 3% per year to have an additional 5% of traffic > to new members, I am fine with this. If it translates to an extra 50% of > cost for 5% of additional traffic, I am not fine with it. > > Finally -- there is nothing wrong with asking questions. If you are an > exchange company and you can defend your prices for what you offer, then > there is no problem. If you are an exchange and are mostly just hoping > nobody asks the questions because you won't have any good answers -- well, > I think this is exactly why Dave asked the question. > > Best Regards, > -Phil Rosenthal > > On Jun 16, 2016, at 1:58 PM, Adam Rothschild wrote: > > > > I think a fresh conversation is needed around what makes up a > > "minimally viable" feature set for an IXP: > > > > The days of an IXP "needing" to engineer and support a multi-tenant > > sFlow portal, because the only other option is shelling out the big > > bucks for Arbor, have long passed -- overlooking the plethora of open > > sourced tools, folk like Kentik have broken into that market with > > rationally priced commercial alternatives. Likewise, one might argue > > that offering layer-2 and layer-3 (!) VPNs is at best non-essential, > > and a distraction that fuels purchasing very expensive hardware, and > > at worse competitive with customers. > > > > On the other hand, building out a metro topology to cover all relevant > > carrier hotels, with reasonable path diversity, is absolutely table > > stakes. And outreach is a great function, *when* it nets unique new > > participants. To cite a recent example, the various R&E networks and > > smaller broadband and mobile providers showing up here in the US, due > > to excellent efforts by the NYIIX and DE-CIX teams. > > > > At the end of the day, IXP peering must be significantly cheaper than > > transit alternatives, many of which are priced based on utilization > > (as opposed to port capacity). We can dance around this point all we > > want, but absent a change in trajectory, I worry some IXPs will > > ultimately price themselves out of the market, and all the gold-plated > > features in the world won't satiate those making purchasing decisions. > > > > $0.02, > > -a > > > > On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker > wrote: > >> * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 > CEST]: > >>> > >>> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): > >>> > >>>> Well, the customers also wanted more functions and features. They > wanted > >>>> sFLOW statistics to show traffic, customer portals, better SLAs, > distributed > >>>> IXes, remote peering, more hand-holding when connecting etc. > >>> > >>> > >>> Are you sure they still want them if they have to pay for these > features > >>> separately? > >>> > >>> Currently, such luxury functions are increasing costs also for networks > >>> who don't need/want it. > >> > >> > >> sFlow statistics isn't a luxury function. Neither is remote peering. > The > >> others Mikael mentioned are debatable at worst but you'd be telling the > >> membership what they really want rather than listening to them saying > what > >> they want. > >> > >> This thread is full of people who have never run large L2 networks > stating > >> their opinions on running large L2 networks, and they invariably > >> underestimate their complexity and the logistics required. > >> > >> > >> -- Niels. > > From nick at foobar.org Thu Jun 16 23:45:22 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 17 Jun 2016 00:45:22 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <57615A58.1060809@foobar.org> <576178C6.10204@foobar.org> Message-ID: <57633A12.60806@foobar.org> Dave Temkin wrote: > They are representative of the most important IXPs to deliver traffic > from in Western Europe. I don't doubt that they are important IXPs for delivering traffic. However, no other IXP in europe (both eastern and western) is doing expansion outside the countries that they operate in, other than three out of the four that you mentioned; none of the member-owned organisations in the region are making large profits or in most cases anything more than marginal profits, and all of them have lower port costs. Also, none of their activities suggest that their marketing budgets are large. These, I think, were the main points of contention you were concerned about. > I would posit that what defines important to me may not be what defines > important to you and the same can be said when you look at how various > "internet" companies look at what's important in their vertical. We're not talking about relative importance; we're talking about whether the problems you identified with the four IXPs named in your talk are representative of problems with the larger IXP community. I cannot find evidence that they are, at least not in the areas that you identified as problems. > Netnod runs a dns root server > system (i.root-servers.net ) as well as a > heavy duty time service. > > There are others who do this for no cost and some who do it for > government money. Whether or not my port fees should subsidize this is a > valid question, and was brought up in the Q&A afterwards. All root operators do this for no charge, but at substantial cost. Running a root dns server system is one of the things what Netnod does because that's one of the things that the organisation is chartered to do. > Regarding the pricing reduction on page 16 of your preso, the US$ and > UK? are not much different than what they were 5 years ago, but the ? > has dropped by 30% against the US$. > > You speak to this below, however if my business is primarily run in USD > (which was the relevant use case presented: I'm a US company deciding if > I should peer in Europe or buy transit) then those currency fluctuations > have a very different impact than if I'm a European company functioning > primarily in local currency. Oh sure, but this is a matter that you need to take up with your financial people. I have no doubt that Netflix employs smart financial people, and that their decisions are the right thing for Netflix. IXPs are going to operate in their local currency and they cannot be held responsible for international currency fluctuations. From this respect, I don't think it's useful to bring this up in a critical context because it's not something that they can influence in any way whatever. > I did purposefully mention SIX as a polar opposite example - there is > definitely a happy medium to be found. This edges into one of the things that is crucial to this discussion, and it was unfortunate that it wasn't explored more. The crux is that there is a substantial cultural difference between how US people view IXPs and how european people view IXPs. As far as I can tell there are, for the most part, two types of IXPs in the US: commercial and co-operative. How they differ from european IXPs is that the commercials are almost all run by the data centres and are tied to those data centres. Most if not all of the co-operative IXPs are to some degree or other financed by donations or sponsorship and the donation types are: cash, equipment and manpower. In europe, there are three types of IXP: commercial, member based and non-member, non-profit. Many of the commercial IXPs are not owned by the data centres (e.g. NL-IX, ECIX, etc). The member-owned IXPs are answerable fully to their membership (e.g. LINX, INEX), and the non-member, non-profit IXPs (Netnod, VIX, etc) provide a service to the community as they see fit, but are not required to answer to the organisations who use them for peering services, even if they are likely to listen to what those organisations say. Crucially, almost all of the european non-profit IXPs are 100% self-funded without donations, sponsorship or subsidisation of manpower. They have offices, admin people, support staff and everything else that a normal business has. IXP staff are paid market rates because if you don't do this, they walk. They do this because this having a dependable income source ensures long term stability and their members / customers / peering participants need to know that the organisation that supports their business is built on a sound structural foundation. This matters to them and they are prepared to pay for it. The flip side of it is that European non-profit IXPs are, by design, more expensive than US non-profit IXPs and there are almost no free / zero-recurrent-cost IXPs in the region. So I would question comparing a european IXP with e.g. SIX or CommunityIX and would suggest that this is a case of apples and bananas. Both are yummy, but whether you prefer one or another is a matter of taste. How IXPs spend revenue is a different matter. You're right to bring this topic up because scrutiny is what keeps things honest. Nick From dgolding at gmail.com Fri Jun 17 00:15:08 2016 From: dgolding at gmail.com (Daniel Golding) Date: Fri, 17 Jun 2016 00:15:08 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> Message-ID: On Thu, Jun 16, 2016 at 12:58 PM Will Hargrave wrote: {snip} > Dan Golding disagreed with me but I can certainly speak for LONAP where > I feel our mission of ?promoting efficient interconnection in the > UK? is hugely enhanced by our ability to provide services in any of > our current seven datacentres, across four different operators. London > would not be the great city of interconnection it is without the east > London cluster of DCs from different operators. > > Of course, that's not what I said, but only people who were present actually know that. You said that LONAP's distributed strategy "kept datacenters honest" to use your exact quote. That implied some sort of benefit for members in acting as some sort of counterweight to (rapacious?) data center providers. I made the point that distributed IX's don't really impact power or space costs in data centers. I can provide actual data on this, if you would like. Dan > {snip} > > > Will > From dave at temk.in Fri Jun 17 01:18:05 2016 From: dave at temk.in (Dave Temkin) Date: Thu, 16 Jun 2016 20:18:05 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: A key point: On Thu, Jun 16, 2016 at 6:09 PM, Baldur Norddahl wrote: I have studied Netnod extensively because we want to become members > You meant a customer, but because of a lack of transparency (and great marketing) amongst some IXPs, it's very easy to conflate member-mutual IXPs, commercial, and non-profit IXPs. Being a "member" of NetNod provides you with a very different set of benefits vs. LINX and unless you read the letters of incorporation, you may not know that. From baldur.norddahl at gmail.com Fri Jun 17 01:47:23 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 Jun 2016 03:47:23 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: On 17 June 2016 at 03:18, Dave Temkin wrote: > A key point: > > On Thu, Jun 16, 2016 at 6:09 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> wrote: > > I have studied Netnod extensively because we want to become members >> > > You meant a customer, but because of a lack of transparency (and great > marketing) amongst some IXPs, it's very easy to conflate member-mutual > IXPs, commercial, and non-profit IXPs. Being a "member" of NetNod provides > you with a very different set of benefits vs. LINX and unless you read the > letters of incorporation, you may not know that. > > Ok, customer. Actually I don't care. I will evaluate the business value no matter who owns it and I will vote with my dollars/euros/kroner. Yes it would be nice if we had a true self owned entity that would help people peer the most cost effective way and only that. Apparently they have something like it in Seattle. But not in my part of the world, hence I view them all as purely commercial entities. I need a good balance of price and quality and will buy from whoever comes with the best business proposal. Regards, Baldur From swmike at swm.pp.se Fri Jun 17 06:21:30 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 17 Jun 2016 08:21:30 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: On Thu, 16 Jun 2016, Dave Temkin wrote: > You meant a customer, but because of a lack of transparency (and great > marketing) amongst some IXPs, it's very easy to conflate member-mutual > IXPs, commercial, and non-profit IXPs. Being a "member" of NetNod provides > you with a very different set of benefits vs. LINX and unless you read the > letters of incorporation, you may not know that. Are you accusing Netnod of using marketing (and lack of transparancy) to try to fool people into believing it is a member based organisation? I've read what you wrote above 5 times now, and it sure seems to me that you do. If you are, I'm very interested in hearing your motivation for doing that. If you're not, please do share what you actually meant. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Fri Jun 17 06:31:29 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 17 Jun 2016 08:31:29 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: On Fri, 17 Jun 2016, Mikael Abrahamsson wrote: > If you are, I'm very interested in hearing your motivation for doing > that. I realised I probably used the wrong english word here. The correct english word(s) would probably be "rationale/reason/facts", not "motivation". -- Mikael Abrahamsson email: swmike at swm.pp.se From nurani at netnod.se Fri Jun 17 07:16:48 2016 From: nurani at netnod.se (Nurani Nimpuno) Date: Fri, 17 Jun 2016 09:16:48 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: <1E0A4E08-85FB-40CA-B944-2CA6265523EC@netnod.se> Hi Dave, > On 16 juni 2016, at 16:40, Dave Temkin wrote: > Nothing in my presentation said "Netflix seeks to get better port fees". You'll find that I, not once, in my deck or oral presentation, mentioned Netflix. I spoke at length with LINX after the presentation and pointed out that I seek to help the entire market, not just my employer, better understand how IXPs price their services, what things are negotiable, and what things need to change. Call it thinly-veiled, but I didn't even use my employer slide master - this was geared as a community discussion. Ok. > And I don?t represent a membership-based IXP. > > An important distinction. Poring through http://www.netnod.se/about/documents , there is very little transparency into the actual operations of NetNod. Well, we do describe our governance structure and we are always clear about being owned by a foundation on our information material. We even present financial figures at our Netnod meetings. But ok, maybe this could be better documented on our website. Fair enough. Our current website sucks somewhat and we?re in the process of reworking it, so I?ll take your point onboard and we?ll try to improve this. > If you stop adding value to those networks peering at the IX, you will slowly become irrelevant. > > And therein lies the rub, we (many of us, not just you and I) disagree about what "adding value" is defined as. I'm glad we can have this conversation. Yes. And we will never agree. You and I may of course agree in one point in time, but all the world?s operators will never agree. I think this thread has proven that. Some seem to argue that all IXPs should simply be a donated L2 switch sitting in free rack space, while others clearly need more than that. Having a discussion about that is useful, I agree. And it?s a discussion that will continue to evolve as the industry evolves. And it will maybe also reach different conclusions for LINX, as opposed to INEX, LONAP or Netnod (which was the point I was trying to make about diversity). Also, as we know, IXPs is not the only solution to interconnection. To me it was not clear that this is the conversation you wanted to have. If that?s the case, then great! > We work in a similar way with our pricing. (You mention that there is a lot of negotiations on pricing with IXPs.) I would like to be 100% clear that for the Netnod IX, we don?t negotiate or give ?sweet deals? to anyone. We publish our fee schedule and we stick to it. Whenever someone wants a special deal (which happens often, particularly with the larger customers), our response is that we treat everyone equally. If you want a cheaper deal, then another customer is basically funding your reduction. So we don?t do this. We believe this is more fair and transparent. > > That's fantastic, and I agree with this approach. And that's why it's important to make this a community discussion, not a "Netflix and Netnod" discussion. This is slightly different (although somewhat related) to ?what value do IXPs bring??. This is about keeping the IXPs honest. Like Nick, I?m all for that. > As for a general discussion about costs, service levels and IXPs, I think there is a very interesting discussion that could be had with a more focused discussion. How do ?we? best serve today's very diverse set of operators? How does an IXP strike that balance? How do operators best solve their interconnection needs (through IXPs, private peering, transit etc) and is that changing? What type of interconnection environment do we believe best scales Internet growth in the future? What is the total cost of interconnection, where are the big costs, what are the different models and where is the whole industry moving? Now THOSE are discussions I personally would find very valuable! > > We agree. I'm really glad that this has sprouted so many threads of discussion. This seems to have kicked off the discussion within the larger community beyond just the four examples, and I think that what we've seen thus far is healthy discourse. Sure. A broader discussion would be both useful and interesting. Nurani From mpetach at netflight.com Fri Jun 17 07:22:07 2016 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 17 Jun 2016 00:22:07 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> Message-ID: On Wed, Jun 15, 2016 at 4:03 PM, Bill Woodcock wrote: >[...] Only then does an IXP produce bandwidth. Minor nitpick--an IXP never 'produces' bandwidth; it facilitates movement of data between entities, but the IXP itself shouldn't be producing bandwidth. It's the allocation of ports and cross connects from members into the IXP that produce the bandwidth, and that would be the case even if the IXP were removed from the picture and the ports were cross-connected back-to-back. (I suppose if an IXP switch fabric were compromised, someone could use it to generate traffic that did not originate from any member port, but that would be a very unusual circumstance indeed...) Thanks! Matt From owen at delong.com Fri Jun 17 08:20:32 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2016 01:20:32 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> Message-ID: <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> > On Jun 16, 2016, at 06:03 , Ca By wrote: > > Perhaps it is me and my sensibilities, perhaps it is my miser corp culture, but i could not even dream of asking to go to Jamaica (arin area) for the last ARIN meeting. You are entitled to your opinion. If ARIN didn?t exist, how would you go about guaranteeing unique registered GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa? As to Jamaica, as you point out, it?s in the ARIN region. We really have two choices there? One, we can avoid the caribbean and do a disservice to our community members there, or, two, we can occasionally (usually about once out of every 4 meetings) meet in the Caribbean. Do you really think that our members in the Caribbean should be excluded from having the possibility of a local meeting simply because they happen to live in a popular vacation spot? If you don?t think that having the meeting in the Caribbean serves our Caribbean community members, you?re flat out wrong. There were many attendees present from the Caribbean region who have not been able (either for financial, Visa, or other reasons) to attend our meetings in the US and Canada. While you might want to make the argument against holding the meeting at a resort destination, the reality is that there alternatives in the Caribbean region that can accommodate a meeting and the number of hotel rooms needed by a group our size are few and far between. Most of the facilities that have adequate facilities ARE resorts. > > I am not alone. Have a look at Ren's comments from > > http://research.dyn.com/2006/02/lovely-peering-cruise-on-lake/ > > Posted here: > " > The Peering Forum is more for peer & IX information distribution and contact refresh across a multi-continent body of participants than it is for initial trial concerns. The invite only nature implies the attendees are actively peering at one or more of the IXs sponsoring portions of the Forum. Many of us, hand raised here, are taking vacation time, covering flights, upgraded cabins, etc. to help remove the conflict of interest concerns. It is unfortunate there is not a link to the agenda as it is jam packed with useful peering focused presentations and more than qualifies this as a business need. Last year dozens of participants interacted for the first time and I?m looking forward to similar introductions later this month. Putting a face to the name helps significantly in this very relationship based role which has more to do with international relations than enable.? What you are leaving out here is that IIRC, Ren was one of the people behind the original idea of having things like Peering Cruises. Frankly, if you want to have a concentrated focused meeting, a cruise can be a very cost-effective approach, where you can cover meeting rooms, hotel rooms, meals, etc. for less per person than the cost of a hotel room in some cities in the US that I suspect you?d consider perfectly acceptable. (NYC, ORD, SFO, SJC, LAX to name just a few) > I am not willing to fork over my pto or personal cash to "remove the conflict of interest" . I'd rather buy transit. I?m not sure what this supposed COI is. > And, i am also not willing to spend my corp money with dec-ix or others to send my competitors on a cruise. Unless ? Well? I?m unaware of DE-CIX providing cruises at their expense, so I?m not sure where that comes from. Perhaps I missed out somewhere. Wouldn?t surprise me. > why cant this just be business? Why can?t it be just business on a cruise? Who says that business has to be a windowless conference room in a city with little or no appeal to tourists? > That said, i have never been on a peering cruise and all my peering needs are met with peeringdb and email. So it is just business for me, and no i am not going to spend money at an IX that does not see things the way i do. I?m happy for you, but you aren?t exactly what I would call a major backbone. I?m pretty sure you have to buy transit from at least one or two major backbones to deal with your networking needs. Are you so certain that those major backbones that you pay didn?t need in person meetings to get some of their peering arrangements done? Are you so sure that there are not significant swaths of internet infrastructure (including much of the state of the art in IXPs today) that didn?t develop and evolve largely in these collaborative environments? You have the luxury of using the tools that others have built to meet your peering needs. You talk about your use of peeringdb? I?m pretty sure that the origin of peeringdb can be traced back to people talking together at some of these fora that you consider non-business for reasons passing understanding. This isn?t an all-business focus question or even a miserly question. It?s purely an optics question. If you want to live in fear of the optics, go for it. I, for one, prefer to look at ?what will this cost? what is the value my company can get from it?? If the latter is greater than or equal to the former, then it?s probably worth making the case to management. Otherwise, I usually don?t even attempt it. YMMV Owen From hugge at nordu.net Fri Jun 17 08:44:58 2016 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Fri, 17 Jun 2016 10:44:58 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> On 17/06/16 01:09, Baldur Norddahl wrote: > Hi, > > I have studied Netnod extensively because we want to become members, but we > can not simply because it is too expensive. I just signed a deal with he.net > for a flatrate 10G transit for about the same as the 10G Comix port cost. > The difference being that the he.net port provides much more value and > besides also provides indirect one-step-away peering with everyone on Comix. > > So from my perspective it is clear that Netnod has a pricing problem here. > Especially for the lower speeds (10G). There is also a value problem > because the only Comix peer that moves a lot of traffic to us is Akamai, > and they promised that we could peer directly skipping the middleman. > > We are based in Copenhagen. The Netnod IX in Stockholm would provide a lot > more value, but to get there we have to add the cost for transport and > after doing that, the comparison to the 10G he.net transit is just silly. > > Here is an opinion: If the IX pricing is comparable to transit, the service > needs to be too. Netnod will need to connect the five (I think there are > five) Netnod IX'es into one big domain. I am meeting with NL-IX next week > and as I understand it, that is exactly what they did - we will probably > buy NL-IX and skip Netnod for this single reason. > > I feel that smaller providers are being let down by the IX community at > this point. The value of "smaller" is going to get larger if the IX > community does not move with the transit providers. We want to take part > but there is a limit of how much over price you can sign onto and keep your > job. > > Regards, > > Baldur For me (and middle-sized non-profit ISP) this is something that will eventually solve itself, because of people tend to vote with the wallets. As of now (looking at job's excellent spreadsheet) we can see that regular transit is cheaper or atleast on-par with 6-8 of the more expensive IXPs in that spreadsheet. We can use hurricane-electrics longlasting google-ad that promises $0.26/Mbps on a 10G as a baseline, there is cheaper and much more expensive bits to be had naturally but for the sake of argument. While transit is almost always a better thing then connecting a IXP if cheap bits is of your prime concern, there is still quality to gain by being able to take care of some of the traffic yourself over an IXP. But this also has a tippingpoint in terms of price. The other battle IXPs needs to take into consideration is the price of PNI?s nowadays. It is MUCH easier to get really good value from private interconnects seeing as most operators has more traffic to less destinations then what we had a few years back, and $BIGCLOUD is usually very forthcoming into helping out with this since the bits is the product they sell, not the transport of the bits. A 10G port at DECIX Frankfurt is 22800EUR/year. For 22800/year you can go out in the market today, buy a jericho-switch which does internet-scale tables and BGP and has buffers and all the stuff you need for a peering-edge and will get 1T worth of faceplate connectors, support for that same switch for about three years and you still has some change left for icecream. Thats alot of possible PNI?s. Then we need to factor in costs of crossconnects - if you are in a $BIGNAMEDATACENTER will probably have to pay anything between 19 - 300 EURO/month for said crossconnect (or the other company has to, or you split it). If you are in $NOTSOBIGNAMEDATACENTER you can perhaps pull the patch yourself and only pay the CAPEX of 11EUR of buying the patch so this varies heavily. What i do when i think about these things is to produce a matrix where the cost of the IXP in that region is measured towards a full TCO of a PNI, factoring in what a 10G/100G port costs in terms of buying hardware and then all the OPEX surrounding it in terms of hardwaresupport/xconns/powerconsumtion/patching/documentation of patching etc etc. For me - PNIs make economical sense if i can shave of 313Mbit/s of my IXP (cheap DC / high IXP cost) in the lowside, and about 3.67Gbit/s on the highside (expensive DC / cheap IX). And this is with quite high port CAPEX (juniper mx), when and if peering-edge is being produced in something like a Jericho-box i expect these requirements will drop to the floor. Last year i added 0 new IXPs, upgraded 0 IXPs, but i added over 30 new PNI's. If IXPs wants more of those bits, adjusting prices much more aggresively is what can bring this back to their market, instead of the datacenter-crossconnect market. -- hugge From will at harg.net Fri Jun 17 09:31:12 2016 From: will at harg.net (Will Hargrave) Date: Fri, 17 Jun 2016 10:31:12 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> Message-ID: <035A493F-A8B4-43D3-8CD9-D4E8EA257262@harg.net> On 17 Jun 2016, at 1:15, Daniel Golding wrote: > You said that LONAP's distributed strategy "kept datacenters honest" > to use > your exact quote. That implied some sort of benefit for members in > acting > as some sort of counterweight to (rapacious?) data center providers. I rely primarily on information from our membership base who reaffirm their desire for a multi-site approach. They (and you) are the people with the data, as they are the people buying these services. The origin of these designs was probably not out of a desire for diversity to promote competition, but actually because existing datacentres were full. Nevertheless, a datacentre which is full, incompetently run, or too expensive all have something in common - to my members they are useless. > I made the point that distributed IX's don't really > impact power or space costs in data centers. I can provide actual data > on > this, if you would like. What about crossconnect prices? It is interesting you have data that indicates that this policy could be futile, because the belief in this principle is almost axiomatic in our/my community. Did we waste time and money spanning metros with IXs? From elfkin at gmail.com Fri Jun 17 10:10:38 2016 From: elfkin at gmail.com (Harald F. Karlsen) Date: Fri, 17 Jun 2016 12:10:38 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> On 16.06.2016 09:51, Saku Ytti wrote: > Hey, > > I've been bit poking around trying to find reasonable option for 1GE > L3 full BGP table aggregator. It seems vendors are mostly pushing > Satellite/Fusion for this application. > > I don't really like the added complexity and tight coupling > Satellite/Fusion forces me. I'd prefer standards based routing > redundancy to reduce impact of defects. > > ASR9001 and MX104 are not an options, due to control-plane scale. New > boxes in vendor pipeline are completely ignoring 1GE. > > I've casually talked with other people, and it seems I'm not really > alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much > full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface > VLANs, ipfix or sflow, at least per-port QoS with shaper, martini > pseudowires). > What about the Huawei NE20E-S2F/NE40E-M2F? 4 * SFP+ and 40 * SFP fixed ports and two PICs with either 4*SFP+ or 1*QSFP each. Decent FIB. Not really sure about the IPFIX/sflow thought. Pricing seems very aggresive on these devices as well. -- Harald From saku at ytti.fi Fri Jun 17 10:43:07 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 17 Jun 2016 13:43:07 +0300 Subject: 1GE L3 aggregation In-Reply-To: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: On 17 June 2016 at 13:10, Harald F. Karlsen wrote: > What about the Huawei NE20E-S2F/NE40E-M2F? > 4 * SFP+ and 40 * SFP fixed ports and two PICs with either 4*SFP+ or 1*QSFP > each. Decent FIB. Not really sure about the IPFIX/sflow thought. Pricing > seems very aggresive on these devices as well. Last I checked you can't commit/replace configuration in VRP. Has this changed? Can you give it full new config and expect it to figure out how to apply the new config without breaking existing? I'm definitely not excluding Huawei. No 1GE PICs? Can you give indicative pricing, what is aggressive pricing? Are these under 5k? -- ++ytti From nanog at ics-il.net Fri Jun 17 11:45:26 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Jun 2016 06:45:26 -0500 (CDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> Message-ID: <2065684541.60068.1466163924445.JavaMail.mhammett@ThunderFuck> I think a similar point was made at NANOG. A distributed IX will let the market dictate that. Places that are better for people to operate in will see a rise in customers and places that aren't won't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Kuhnke" To: nanog at nanog.org Sent: Thursday, June 16, 2016 6:17:51 PM Subject: Re: NANOG67 - Tipping point of community and sponsor bashing? > However: exchange port fees are not my biggest enemy today. My cross connect fees have not gone down *at all*. On a proportion basis, cross connect fees have gone from "not mattering" to being an important part of any deployment cost calculation. Why aren't we raising hell about cross connect fees? IMHO we should be, in the spirit of: https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party Assuming the existence of overhead fiber trays throughput, when you consider the actual cost of a two strand XC between two cages in the same facility: 30 meter SC-SC duplex 9/125 G.657.A1 cable: $11 There should be a community effort to lobby facility managers and colo/IX real estate management that the value of their facility will be greater if XCs are free or nearly free, resulting in higher occupancy and a greater critical mass of carriers, rather than trying to extract revenue from the tenants by $300/mo MRC per fiber pair between two racks. On Thu, Jun 16, 2016 at 4:06 PM, Phil Rosenthal wrote: > Hello all, > > I wasn't able to attend NANOG this time around, but watched Dave Temkin's > presentation on youtube. > > My comments are: > 1) Over the past 5 years: > My cost for switch/router ports have gone down a lot. > My cost for transit has gone down a lot. > My cost for exchange ports have gone down, but not quite as fast as my > transit and switch/router ports, and this does lead to some value > questions. Dave is right to ask them. > > However: exchange port fees are not my biggest enemy today. My cross > connect fees have not gone down *at all*. On a proportion basis, cross > connect fees have gone from "not mattering" to being an important part of > any deployment cost calculation. Why aren't we raising hell about cross > connect fees? > > 2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on an > exchange. If it could be done 'free' with commodity hardware, then fine -- > but if it translates to requiring Big Expensive Routers instead of a > cheaper but fast switch, this should translate to higher pricing for the > customers requiring these exotic features -- not the customers who just > want a big L2 vlan. > > 3) Remote peering -- This is mostly a question about distance for value. > There is a clear benefit in providing multi-datacenter exchanges within a > metro, and both FL-IX and SIX are doing this with a very good value > proposition. Having the ability to join DECIX Frankfurt from NYC and vice > versa -- again, this is a bizarre service to be offered, and regular users > should not be expected to pay for this. If there is a market for these > services at an unsubsidized price, then fine -- but regular members should > not be subsidizing this service. > > 4) sFlow -- I'm not sure why this is even really a topic. Commodity > hardware does have sFlow capability, and FLIX demonstrates this well. With > that said, for us, it is of extremely limited value. We might check these > graphs to validate measurements of our internal netflow/sflow graphing > systems, but generally, I look at the graphs generated by my exchange > vendors less than once per year per exchange. I am honestly not even sure > if SIX offers this service, as I never had a reason to check. > > 5) Marketting vs Outreach: These things are honestly basically the same > thing, mostly separated by the question of "is it good marketing or not". I > like having more members at the exchanges I am a member of. If it > translates to an additional 3% per year to have an additional 5% of traffic > to new members, I am fine with this. If it translates to an extra 50% of > cost for 5% of additional traffic, I am not fine with it. > > Finally -- there is nothing wrong with asking questions. If you are an > exchange company and you can defend your prices for what you offer, then > there is no problem. If you are an exchange and are mostly just hoping > nobody asks the questions because you won't have any good answers -- well, > I think this is exactly why Dave asked the question. > > Best Regards, > -Phil Rosenthal > > On Jun 16, 2016, at 1:58 PM, Adam Rothschild wrote: > > > > I think a fresh conversation is needed around what makes up a > > "minimally viable" feature set for an IXP: > > > > The days of an IXP "needing" to engineer and support a multi-tenant > > sFlow portal, because the only other option is shelling out the big > > bucks for Arbor, have long passed -- overlooking the plethora of open > > sourced tools, folk like Kentik have broken into that market with > > rationally priced commercial alternatives. Likewise, one might argue > > that offering layer-2 and layer-3 (!) VPNs is at best non-essential, > > and a distraction that fuels purchasing very expensive hardware, and > > at worse competitive with customers. > > > > On the other hand, building out a metro topology to cover all relevant > > carrier hotels, with reasonable path diversity, is absolutely table > > stakes. And outreach is a great function, *when* it nets unique new > > participants. To cite a recent example, the various R&E networks and > > smaller broadband and mobile providers showing up here in the US, due > > to excellent efforts by the NYIIX and DE-CIX teams. > > > > At the end of the day, IXP peering must be significantly cheaper than > > transit alternatives, many of which are priced based on utilization > > (as opposed to port capacity). We can dance around this point all we > > want, but absent a change in trajectory, I worry some IXPs will > > ultimately price themselves out of the market, and all the gold-plated > > features in the world won't satiate those making purchasing decisions. > > > > $0.02, > > -a > > > > On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker > wrote: > >> * zbynek at dialtelecom.cz (Zbyn?k Posp?chal) [Thu 16 Jun 2016, 14:23 > CEST]: > >>> > >>> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): > >>> > >>>> Well, the customers also wanted more functions and features. They > wanted > >>>> sFLOW statistics to show traffic, customer portals, better SLAs, > distributed > >>>> IXes, remote peering, more hand-holding when connecting etc. > >>> > >>> > >>> Are you sure they still want them if they have to pay for these > features > >>> separately? > >>> > >>> Currently, such luxury functions are increasing costs also for networks > >>> who don't need/want it. > >> > >> > >> sFlow statistics isn't a luxury function. Neither is remote peering. > The > >> others Mikael mentioned are debatable at worst but you'd be telling the > >> membership what they really want rather than listening to them saying > what > >> they want. > >> > >> This thread is full of people who have never run large L2 networks > stating > >> their opinions on running large L2 networks, and they invariably > >> underestimate their complexity and the logistics required. > >> > >> > >> -- Niels. > > From nanog at ics-il.net Fri Jun 17 11:50:47 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Jun 2016 06:50:47 -0500 (CDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <57633A12.60806@foobar.org> References: <57615A58.1060809@foobar.org> <576178C6.10204@foobar.org> <57633A12.60806@foobar.org> Message-ID: <1051189720.60071.1466164246028.JavaMail.mhammett@ThunderFuck> I think the popularity of the donation-based IX largely a violent reaction to the over-priced major IX operators in the US. People didn't like what was happening, so went to the polar opposite. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Dave Temkin" Cc: "NANOG list" Sent: Thursday, June 16, 2016 6:45:22 PM Subject: Re: NANOG67 - Tipping point of community and sponsor bashing? Dave Temkin wrote: > They are representative of the most important IXPs to deliver traffic > from in Western Europe. I don't doubt that they are important IXPs for delivering traffic. However, no other IXP in europe (both eastern and western) is doing expansion outside the countries that they operate in, other than three out of the four that you mentioned; none of the member-owned organisations in the region are making large profits or in most cases anything more than marginal profits, and all of them have lower port costs. Also, none of their activities suggest that their marketing budgets are large. These, I think, were the main points of contention you were concerned about. > I would posit that what defines important to me may not be what defines > important to you and the same can be said when you look at how various > "internet" companies look at what's important in their vertical. We're not talking about relative importance; we're talking about whether the problems you identified with the four IXPs named in your talk are representative of problems with the larger IXP community. I cannot find evidence that they are, at least not in the areas that you identified as problems. > Netnod runs a dns root server > system (i.root-servers.net ) as well as a > heavy duty time service. > > There are others who do this for no cost and some who do it for > government money. Whether or not my port fees should subsidize this is a > valid question, and was brought up in the Q&A afterwards. All root operators do this for no charge, but at substantial cost. Running a root dns server system is one of the things what Netnod does because that's one of the things that the organisation is chartered to do. > Regarding the pricing reduction on page 16 of your preso, the US$ and > UK? are not much different than what they were 5 years ago, but the ? > has dropped by 30% against the US$. > > You speak to this below, however if my business is primarily run in USD > (which was the relevant use case presented: I'm a US company deciding if > I should peer in Europe or buy transit) then those currency fluctuations > have a very different impact than if I'm a European company functioning > primarily in local currency. Oh sure, but this is a matter that you need to take up with your financial people. I have no doubt that Netflix employs smart financial people, and that their decisions are the right thing for Netflix. IXPs are going to operate in their local currency and they cannot be held responsible for international currency fluctuations. From this respect, I don't think it's useful to bring this up in a critical context because it's not something that they can influence in any way whatever. > I did purposefully mention SIX as a polar opposite example - there is > definitely a happy medium to be found. This edges into one of the things that is crucial to this discussion, and it was unfortunate that it wasn't explored more. The crux is that there is a substantial cultural difference between how US people view IXPs and how european people view IXPs. As far as I can tell there are, for the most part, two types of IXPs in the US: commercial and co-operative. How they differ from european IXPs is that the commercials are almost all run by the data centres and are tied to those data centres. Most if not all of the co-operative IXPs are to some degree or other financed by donations or sponsorship and the donation types are: cash, equipment and manpower. In europe, there are three types of IXP: commercial, member based and non-member, non-profit. Many of the commercial IXPs are not owned by the data centres (e.g. NL-IX, ECIX, etc). The member-owned IXPs are answerable fully to their membership (e.g. LINX, INEX), and the non-member, non-profit IXPs (Netnod, VIX, etc) provide a service to the community as they see fit, but are not required to answer to the organisations who use them for peering services, even if they are likely to listen to what those organisations say. Crucially, almost all of the european non-profit IXPs are 100% self-funded without donations, sponsorship or subsidisation of manpower. They have offices, admin people, support staff and everything else that a normal business has. IXP staff are paid market rates because if you don't do this, they walk. They do this because this having a dependable income source ensures long term stability and their members / customers / peering participants need to know that the organisation that supports their business is built on a sound structural foundation. This matters to them and they are prepared to pay for it. The flip side of it is that European non-profit IXPs are, by design, more expensive than US non-profit IXPs and there are almost no free / zero-recurrent-cost IXPs in the region. So I would question comparing a european IXP with e.g. SIX or CommunityIX and would suggest that this is a case of apples and bananas. Both are yummy, but whether you prefer one or another is a matter of taste. How IXPs spend revenue is a different matter. You're right to bring this topic up because scrutiny is what keeps things honest. Nick From dave at temk.in Fri Jun 17 12:23:38 2016 From: dave at temk.in (Dave Temkin) Date: Fri, 17 Jun 2016 08:23:38 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> Message-ID: It seems as though most subtlety is lost on this crowd, or perhaps there's just a language barrier. I'm saying that if you were to, for example, look at the homepage of https://www.peering-forum.eu and see the "Hosts" block, you might think "There are four similarly named IXPs are all similar organizations hosting a forum" when in reality, they are quite different and it may not be all that easy to figure how/why (by Nurani's own admission, most of that is not easy to find on their website). [image: Inline image 1] On Fri, Jun 17, 2016 at 2:31 AM, Mikael Abrahamsson wrote: > On Fri, 17 Jun 2016, Mikael Abrahamsson wrote: > > If you are, I'm very interested in hearing your motivation for doing that. >> > > I realised I probably used the wrong english word here. The correct > english word(s) would probably be "rationale/reason/facts", not > "motivation". > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From colton.conor at gmail.com Fri Jun 17 12:58:34 2016 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 17 Jun 2016 07:58:34 -0500 Subject: 1GE L3 aggregation In-Reply-To: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: What size FIB/RIB table does that Huawei have? On Fri, Jun 17, 2016 at 5:10 AM, Harald F. Karlsen wrote: > On 16.06.2016 09:51, Saku Ytti wrote: > >> Hey, >> >> I've been bit poking around trying to find reasonable option for 1GE >> L3 full BGP table aggregator. It seems vendors are mostly pushing >> Satellite/Fusion for this application. >> >> I don't really like the added complexity and tight coupling >> Satellite/Fusion forces me. I'd prefer standards based routing >> redundancy to reduce impact of defects. >> >> ASR9001 and MX104 are not an options, due to control-plane scale. New >> boxes in vendor pipeline are completely ignoring 1GE. >> >> I've casually talked with other people, and it seems I'm not really >> alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much >> full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface >> VLANs, ipfix or sflow, at least per-port QoS with shaper, martini >> pseudowires). >> >> > What about the Huawei NE20E-S2F/NE40E-M2F? > 4 * SFP+ and 40 * SFP fixed ports and two PICs with either 4*SFP+ or > 1*QSFP each. Decent FIB. Not really sure about the IPFIX/sflow thought. > Pricing seems very aggresive on these devices as well. > > -- > Harald > From lars.lehtonen at gmail.com Fri Jun 17 09:39:16 2016 From: lars.lehtonen at gmail.com (Lars Lehtonen) Date: Fri, 17 Jun 2016 02:39:16 -0700 Subject: syslog server References: Message-ID: <23tc3d-7qe.ln1@cerise.exp.symmet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maximino Velazquez wrote: > I need help !! > > What is the best syslog server (opensource)? Greylog and Logstash are for having a convenient index of log messages, but they're not particularly robust. I've not seen syslog-ng crash, so I use it for collecting (and shipping) log data. Logstash is convenient, pretty, and utterly unreliable. You end up needing both. - --- Lars Lehtonen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXY8U5AAoJEIE31HTrywTy00QH/2+8pObU5FVvAbYhS7IdIN49 y6CMrrIIS0fwNpBa41Ulx9UHQHLbuLH2ZgyVBFtgivzycMhEJv+SXwXmyun9SoVv WadLR8FeHSHGlvzlA3dmyadbGtOgl4kTqskNM/D9rx5biUeR9XNLWwidSZ+fNBnz Qz74l0+7mKXfI26aIxJYnix5+JBdTtiTFEa1Cqts1Foml8fdLS+Q1RyrW5pOceQ8 MZYPFuNB0WXEwj85Mo7sieVR5doF9ZTbffIlHCbmcfjl/hfni/u4+MZGR73vOKS6 33VddioPCzqyknt+tH4sQhnI8QEMcx/dmdO3AXbh6VmAOXhBlkmx2RPLN3fnYXs= =vHOt -----END PGP SIGNATURE----- From saku at ytti.fi Fri Jun 17 13:05:41 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 17 Jun 2016 16:05:41 +0300 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: On 17 June 2016 at 15:58, Colton Conor wrote: > What size FIB/RIB table does that Huawei have? It has 25M RIB and 4M FIB. Same Solar NPU as their largest kit. -- ++ytti From colton.conor at gmail.com Fri Jun 17 13:17:33 2016 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 17 Jun 2016 08:17:33 -0500 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: Whats the price piont though? Is that the router he was saying in 15K range? On Fri, Jun 17, 2016 at 8:05 AM, Saku Ytti wrote: > On 17 June 2016 at 15:58, Colton Conor wrote: > > What size FIB/RIB table does that Huawei have? > > It has 25M RIB and 4M FIB. Same Solar NPU as their largest kit. > > -- > ++ytti > From saku at ytti.fi Fri Jun 17 13:20:33 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 17 Jun 2016 16:20:33 +0300 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: On 17 June 2016 at 16:17, Colton Conor wrote: > Whats the price piont though? Is that the router he was saying in 15K range? I'm all Shania Twain on 15k. I've seen people buy MX80 for bit over 3k, this isn't that much denser. 5k would impress me much. -- ++ytti From colton.conor at gmail.com Fri Jun 17 13:25:33 2016 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 17 Jun 2016 08:25:33 -0500 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: Thats some extreme level of unheard discount to get a full MX80 for 3K. On Fri, Jun 17, 2016 at 8:20 AM, Saku Ytti wrote: > On 17 June 2016 at 16:17, Colton Conor wrote: > > Whats the price piont though? Is that the router he was saying in 15K > range? > > I'm all Shania Twain on 15k. > > I've seen people buy MX80 for bit over 3k, this isn't that much > denser. 5k would impress me much. > > -- > ++ytti > From bicknell at ufp.org Fri Jun 17 13:48:35 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Jun 2016 06:48:35 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> Message-ID: <20160617134835.GA55732@ussenterprise.ufp.org> In a message written on Thu, Jun 16, 2016 at 05:56:36PM +0100, Will Hargrave wrote: > Most of the major IXs in the European market operate in multiple > datacentres. Why? Because it decreases the monopoly conferred upon one > particular datacentre in a market which becomes the ?go to? > location. It moves the monopoly to the IXP operator! When everyone is in one facility (or at least building) it is typically easy to get low priced (although maybe not low enough, see other posts in this thread) cross connects. It's common to see a pair of public peers fill up a significant part of their port, and then move to a private peering model getting off the IXP and onto glass directly. When the IXP is distributed, this becomes glass between buildings, often requiring yet another supplier as well. The MRCs are higher making the justification to move off harder. What happens is rather than moving off to glass, they have to buy faster/more ports from the IXP and move the traffic over the IXP. The IXP becomes the go-to monopoly as a result. Now, perhaps IXP's are more benevolent than data center opertors, and this is a good trade. I think one thing the presentation was asking people to do was step back, look at the situation, and reevaluate that particular tradeoff. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From marty at cloudflare.com Fri Jun 17 13:58:12 2016 From: marty at cloudflare.com (Marty Strong) Date: Fri, 17 Jun 2016 14:58:12 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160617134835.GA55732@ussenterprise.ufp.org> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> Message-ID: <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> > It moves the monopoly to the IXP operator! I disagree, if there is only one *MAIN* building that an IXP is in then participants are going to have to go to that building, giving the colo provider the monopoly, which affects not just cross connects towards and IXP, but other participants too, that you might want to connect directly to. Yes, if the IXP is distributed across more than one building then you have choice as to where you (and other people) put their equipment, so you may have to go to another building to connect to certain peers. Sadly nobody lives in a perfect world, so IMO having the IXP distributed across multiple buildings is better as you can connect to all those who are in your building directly, and peer with the rest over the distributed IXP. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 17 Jun 2016, at 14:48, Leo Bicknell wrote: > > In a message written on Thu, Jun 16, 2016 at 05:56:36PM +0100, Will Hargrave wrote: >> Most of the major IXs in the European market operate in multiple >> datacentres. Why? Because it decreases the monopoly conferred upon one >> particular datacentre in a market which becomes the ?go to? >> location. > > It moves the monopoly to the IXP operator! > > When everyone is in one facility (or at least building) it is > typically easy to get low priced (although maybe not low enough, > see other posts in this thread) cross connects. It's common to see > a pair of public peers fill up a significant part of their port, > and then move to a private peering model getting off the IXP and > onto glass directly. > > When the IXP is distributed, this becomes glass between buildings, > often requiring yet another supplier as well. The MRCs are higher > making the justification to move off harder. What happens is rather > than moving off to glass, they have to buy faster/more ports from > the IXP and move the traffic over the IXP. > > The IXP becomes the go-to monopoly as a result. > > Now, perhaps IXP's are more benevolent than data center opertors, > and this is a good trade. I think one thing the presentation was > asking people to do was step back, look at the situation, and > reevaluate that particular tradeoff. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ From saku at ytti.fi Fri Jun 17 14:00:49 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 17 Jun 2016 17:00:49 +0300 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: On 17 June 2016 at 16:25, Colton Conor wrote: > Thats some extreme level of unheard discount to get a full MX80 for 3K. Yeah it's best I've seen. 8-10k isn't anything special. -- ++ytti From bicknell at ufp.org Fri Jun 17 14:59:54 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Jun 2016 07:59:54 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> Message-ID: <20160617145954.GA58135@ussenterprise.ufp.org> In a message written on Fri, Jun 17, 2016 at 02:58:12PM +0100, Marty Strong wrote: > Yes, if the IXP is distributed across more than one building then you have choice as to where you (and other people) put their equipment, so you may have to go to another building to connect to certain peers. Sadly nobody lives in a perfect world, so IMO having the IXP distributed across multiple buildings is better as you can connect to all those who are in your building directly, and peer with the rest over the distributed IXP. I don't think there is an absolute right or wrong answer. The ISP who needs to connect to 100 ISP's at 50M each has a dramatically different need than the ISP that needs to connect to 20 ISP's at 6x100G each. Both exist in the world. The presenter clearly thought that a number of IXP's aren't serving their customers/members well. What we're finding out in this thread is how many folks agree or disagree! :) Personally I'm with another poster, the real problem here is colos that want to charge large MRC's for a cross connect. I know of at least one still trying to get $1000/mo for a fiber pair to another customer. For $1000/mo I can get GigE transit delivered _to my office_ by multiple carriers. To charge that for a cross connect is just so, so wrong. IMHO in building fiber should be NRC only, but if it has a MRC component (to pay for future troubleshooting or somesuch) it should be small, like $5/mo. That's $60 year to do nothing, and even if the $40 an hour fiber tech spends a hour troubleshooting _every fiber_ (which doesn't happen) the colo still makes money. Cross connects are our industry's $100 gold plated HDMI cables. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at foobar.org Fri Jun 17 15:29:25 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 17 Jun 2016 16:29:25 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160617145954.GA58135@ussenterprise.ufp.org> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> Message-ID: <57641755.5030300@foobar.org> Leo Bicknell wrote: > Cross connects are our industry's $100 gold plated HDMI cables. In the US maybe. Cross-connect prices are much more reasonable in Europe (?0 - ?50/month). Personally, I don't have a problem with MRCs when ordering cross-connects: data centres are expensive to build and run. But yeah, $300/m is nuts and that price point has zero relationship to the cost of delivery of the service. Nick From drc at virtualized.org Fri Jun 17 16:03:51 2016 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2016 09:03:51 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> Message-ID: <1386CA32-47B7-4D7D-B78F-AE208A5C9DD4@virtualized.org> Owen, On Jun 17, 2016, at 1:20 AM, Owen DeLong wrote: >> On Jun 16, 2016, at 06:03 , Ca By wrote: >> >> Perhaps it is me and my sensibilities, perhaps it is my miser corp culture, but i could not even dream of asking to go to Jamaica (arin area) for the last ARIN meeting. > > You are entitled to your opinion. > > If ARIN didn?t exist, how would you go about guaranteeing unique registered GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa? ICANN operates in-addr.arpa and ip6.arpa. Regards, -drc (speaking only for myself) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dave at temk.in Fri Jun 17 16:50:45 2016 From: dave at temk.in (Dave Temkin) Date: Fri, 17 Jun 2016 11:50:45 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <57641755.5030300@foobar.org> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: Starting to see people like Telehouse move into the monthly XC market, so one might think we're at the precipice of the slippery slope. And with Equinix buying Telecity, how long until we see US-style XCs in Europe? On Fri, Jun 17, 2016 at 10:29 AM, Nick Hilliard wrote: > Leo Bicknell wrote: > > Cross connects are our industry's $100 gold plated HDMI cables. > > In the US maybe. Cross-connect prices are much more reasonable in > Europe (?0 - ?50/month). > > Personally, I don't have a problem with MRCs when ordering > cross-connects: data centres are expensive to build and run. But yeah, > $300/m is nuts and that price point has zero relationship to the cost of > delivery of the service. > > Nick > > From mlm at pixelgate.net Fri Jun 17 17:10:01 2016 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 17 Jun 2016 10:10:01 -0700 (PDT) Subject: Netflix banning HE tunnels In-Reply-To: <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: On Tue, 14 Jun 2016, Owen DeLong wrote: >On Jun 14, 2016, at 11:57 , Ricky Beam wrote: >>I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 traffic. > >Those are by definition poorly designed CPE. This (open by default vs closed) has been discussed before, with plenty of people on either side. /mark From sethm at rollernet.us Fri Jun 17 17:31:10 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 17 Jun 2016 10:31:10 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <20160617145954.GA58135@ussenterprise.ufp.org> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> Message-ID: On 6/17/16 07:59, Leo Bicknell wrote: > > IMHO in building fiber should be NRC only, but if it has a MRC component > (to pay for future troubleshooting or somesuch) it should be small, like > $5/mo. That's $60 year to do nothing, and even if the $40 an hour fiber > tech spends a hour troubleshooting _every fiber_ (which doesn't happen) > the colo still makes money. I would expect some kind of MRC if it has any SLA, service, or support attached. Or someone manages it and protects the infrastructure and enforces the rules of the facility. Or the facility uses that money to maintain the MMR. If it's a free for all where anyone can accidentally unplug it or cut it or rummage around in the overhead causing damage then free is fine. What I don't accept is variable pricing depending on what the xconnect is carrying or what it's for. I don't buy into the thought process that an xconnect is more expensive if it's carrying 10GbE vs. GigE when they're both SMF. ~Seth From arnold at nipper.de Fri Jun 17 19:58:57 2016 From: arnold at nipper.de (Arnold Nipper) Date: Fri, 17 Jun 2016 21:58:57 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> Message-ID: <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> On 17.06.2016 10:44, Fredrik Korsb?ck wrote: > Last year i added 0 new IXPs, upgraded 0 IXPs, but i added over 30 > new PNI's. > > If IXPs wants more of those bits, adjusting prices much more > aggresively is what can bring this back to their market, instead of > the datacenter-crossconnect market. > Did you ever think about *who* brought in all the networks you are able to peer with? Seems to be really easy to bash IXPs. Seems to really hard to value what IXPs have done for the interconnection industry. Arnold -- Arnold Nipper email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From dgolding at gmail.com Fri Jun 17 20:53:06 2016 From: dgolding at gmail.com (Daniel Golding) Date: Fri, 17 Jun 2016 20:53:06 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> Message-ID: Hmm - as far as whether this was a good or bad NANOG presentation...this is some of the best discussion I've seen on list in a while. There is a frank exchange of views between many different parties. This may result in some follow-up presentations at future NANOGs by IXP operators (please!). Seems that, whether you agree with Dave or not, it was successful. It also seems that the IXP operators who came under the most criticism have reacted with a lot of professionalism and maturity. Other IXP operators have reacted pretty poorly, which is ironic. Dan From Anthony.DeLaCruz at CenturyLink.com Fri Jun 17 21:16:49 2016 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Fri, 17 Jun 2016 21:16:49 +0000 Subject: Looking for a Level 3 Routing Registry contact Message-ID: <398B250423578A4E97AFE1B8B67C686C4C3DC969@PDDCWMBXEX503.ctl.intranet> Please contact me off list if you can help me get in touch with an actual person that can clear out old entries in the Level 3 routing registry. I can't do jack with the automated and the contacts that put them in are non responsive for clearing out their years old mess. Thanks. This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From randy at psg.com Fri Jun 17 23:27:36 2016 From: randy at psg.com (Randy Bush) Date: Sat, 18 Jun 2016 08:27:36 +0900 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <57641755.5030300@foobar.org> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: >> Cross connects are our industry's $100 gold plated HDMI cables. > > In the US maybe. Cross-connect prices are much more reasonable in > Europe (?0 - ?50/month). > > Personally, I don't have a problem with MRCs when ordering > cross-connects: data centres are expensive to build and run. But > yeah, $300/m is nuts and that price point has zero relationship to the > cost of delivery of the service. [ i know you know this, but i hope you do not mind being a soapbox ] back in the day, the seattle westin building (not the hotel, but a 33 story office building next door) had a smart manager. he had a riser shaft built out and set a very low nrc/mrc for copper and fiber. given the building's copper mmr (meet me room) and a fiber mmr, colos exploded, and now the building is mostly racks, vying for being the largest carrier hotel in the left coast. the six was built and expanded rapidly in this fertile environment. no, the westin is not making millions off of cross-connects, but they do not have rental vacancies. due to the shortage, and maybe price (dunno), of westin space, the six has been extended to a few other buildings; see diagram at bottom of https://www.seattleix.net/topology. this makes sense to me. extensions to distant cities make less sense to me; but i am an old fogey. randy From eric.kuhnke at gmail.com Sat Jun 18 03:57:09 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 17 Jun 2016 20:57:09 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: As I write this I'm sitting about 100 feet away (vertically) from the Westin fiber MMR, so you can definitely say that I'm biased in favor of the Westin and the SIX approach of doing things. What Randy just wrote is exactly the point I was trying to make in my last email. Some real estate facility owners/managers have got into the mistaken mindset that they can get the greatest value and the most monthly revenue from the square-footage of their building by charging additional MRC XC fees to the tenants of the building. When in fact the opposite is true, and we need a concerted community effort to lobby every IX real estate owner with this fact: Your real estate will be MORE valuable and will attract a greater critical mass of carriers, eyeball networks, CDNs, huge hosting providers/colo/VM, etc if you make the crossconnects free. There is a reason why Amazon's HQ was built right across the street, and one of them is the the ridiculously high density of carriers in the Westin. They even removed two whole elevators, which is possible now due to much lower persons/hour elevator traffic and filled the elevator shafts with riser and cooling. Not just North American carriers are here, but every noteworthy Asian network that has capacity in the WA and OR landed submarine cables. And it's the endpoint to the longhaul DWDM/submarine capacity into all the non-satellite-dependent communities in Alaska - so logically a lot of Alaska actually looks like it could be a distant suburb of Seattle, network topology wise. The Westin does still have a *few* office space vacancies, but not much in colo space. Based on my observations over the past 12-14 years they have slowly been reclaiming the office space by not renewing peoples' office space leases and converting the space to modern hot aisle/cold aisle enclosed cabinet space (as on the 4th floor), or conditioned cage space. On Fri, Jun 17, 2016 at 4:27 PM, Randy Bush wrote: > >> Cross connects are our industry's $100 gold plated HDMI cables. > > > > In the US maybe. Cross-connect prices are much more reasonable in > > Europe (?0 - ?50/month). > > > > Personally, I don't have a problem with MRCs when ordering > > cross-connects: data centres are expensive to build and run. But > > yeah, $300/m is nuts and that price point has zero relationship to the > > cost of delivery of the service. > > [ i know you know this, but i hope you do not mind being a soapbox ] > > back in the day, the seattle westin building (not the hotel, but a 33 > story office building next door) had a smart manager. he had a riser > shaft built out and set a very low nrc/mrc for copper and fiber. given > the building's copper mmr (meet me room) and a fiber mmr, colos > exploded, and now the building is mostly racks, vying for being the > largest carrier hotel in the left coast. the six was built and expanded > rapidly in this fertile environment. > > no, the westin is not making millions off of cross-connects, but they > do not have rental vacancies. > > due to the shortage, and maybe price (dunno), of westin space, the six > has been extended to a few other buildings; see diagram at bottom of > https://www.seattleix.net/topology. this makes sense to me. extensions > to distant cities make less sense to me; but i am an old fogey. > > randy > From pete at fiberphone.co.nz Sat Jun 18 08:49:38 2016 From: pete at fiberphone.co.nz (Pete Mundy) Date: Sat, 18 Jun 2016 20:49:38 +1200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> Message-ID: <3B28E80C-58BB-4843-BBDD-88EFB9A3B14C@fiberphone.co.nz> Our DC (granted, not in the US!) charges a one-off fee of $75 to install the XC, which includes the cable too. Terminated to a 1U patch panel at TOR. Only one end pays the 1-off charge (the customer that requested the order). No ongoing charges. No one else rummages in the overheads other than the DC operator themselves.  I guess perhaps what we have is a bit of a luxury, but it's part of the reason we chose that DC over others available in the same vicinity, so it did give them a competitive advantage :) Pete > On 18/06/2016, at 5:31 am, Seth Mattinen wrote: > > I would expect some kind of MRC if it has any SLA, service, or support attached. Or someone manages it and protects the infrastructure and enforces the rules of the facility. Or the facility uses that money to maintain the MMR. If it's a free for all where anyone can accidentally unplug it or cut it or rummage around in the overhead causing damage then free is fine. What I don't accept is variable pricing depending on what the xconnect is carrying or what it's for. I don't buy into the thought process that an xconnect is more expensive if it's carrying 10GbE vs. GigE when they're both SMF. > > ~Seth From mark.tinka at seacom.mu Sat Jun 18 11:03:43 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jun 2016 13:03:43 +0200 Subject: RPKI implementation In-Reply-To: References: Message-ID: On 16/Jun/16 16:38, Randy Bush wrote: > i am aware of that. my point was that cache purge default might better > be set to cache refresh interval than 60 secs. I would agree with (and in fact, prefer) this protocol. Mark. From mark.tinka at seacom.mu Sat Jun 18 11:04:49 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jun 2016 13:04:49 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> On 16/Jun/16 21:36, Baldur Norddahl wrote: > Hi > > If I need to speak BGP with a customer that only has 1G I will simply make > a MPLS L2VPN to one of my edge routers. We use the ZTE 5952E switch with > 48x 1G plus 4x 10G for the L2VPN end point. If that is not enough the ZTE > 8900 platform will provide a ton of ports that can do MPLS. > > The tunnel is automatically redundant and will promote link down events, so > there is not really any downside to doing it this way on low bandwidth > peers. Personally (and at work), I stay away from such topologies. Centralizing IP connectivity like this may seem sexy and cheap in the start, but it has serious scaling and operational issues down the line, IMHO. We push IP/MPLS all the way into the Metro-E Access using a team of Cisco ASR920's and ME3600X's. The value of being able to instantiate an IP service or BGP session directly in the Metro-E Access simplifies network operations a great deal for us. Needless to say, not having to deal with eBGP Multi-Hop drama does not hurt. Centralizing is just horrible, but that's just me. The goal is to make all these unreliable boxes work together to offer a reliable service to your customers, so making them too inter-dependent on each other has the potential to that away in the long run. Mark. From mark.tinka at seacom.mu Sat Jun 18 11:05:37 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jun 2016 13:05:37 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: On 16/Jun/16 22:27, Saku Ytti wrote: > I'm not saying it's bad solution, I know lot of people do it. But I > think people only do it, because L3 at port isn't offered by vendors > at lower rates. A lot of people did it because because there really wasn't a cheap, dense solution until about 2010. And even then, the traditional strategy had become so entrenched that running IP all the way in the Access was such a foreign concept which was most certainly a lot more expensive than incumbent Layer 2-based Access models. I feel this has since changed with the current offerings from Cisco, Juniper and Brocade. The problem now is how to scale the low-speed port density up, as well as add 10Gbps port density, without increasing the cost or size of the platforms. Mark. From mark.tinka at seacom.mu Sat Jun 18 11:07:18 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jun 2016 13:07:18 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: On 16/Jun/16 23:24, Baldur Norddahl wrote: > The ZTE 5952E (routing switch) can do L3VPN including BGP. But it is > limited to about 30k routes. It is usable if the customer wants a default > route solution, but not if he wants the full default free zone. Might be worthwhile to ask ZTE to develop their own implementation of BGP Selective Download. > Our PoPs are connected in a ring topology (actually multiple rings). If a > link goes down somewhere, or an intermediate device crashes, the L2VPN will > reconfigure and find another path. Which is what would happen anyway with your IGP if the service were delivered in the Access, but with fewer moving parts and less inter-dependence if the problem went beyond just ring failure or device crash. > For a BGP customer I could offer two tunnels, one to each of our provider > edge routers. But very few of our customers are BGP customers, they just > want normal internet. For them we do VRRP between the two provider edge > routers and have the one tunnel go to both. If your BGP customer-count grows, while managing 2 eBGP sessions per customer is not life-threatening, it's certainly won't go unnoticed from an operational perspective, especially if you are doing this as a matter of (redundancy) course, in lieu of a revenue-generating request by the customer to increase their SLA. > > We actually moved away from a hybrid solution with L3 termination at the > customer edge to simply backhauling everything in L2VPNs. We did this > because the L2VPN tunnels are needed anyway for other reasons and it is > easier to have one way to do things. I've never been one to support the confluence of infrastructure tunnels with customer service tunnels. That's why we avoid infrastructure tunnels in general, e.g., creating a tunnel from a data centre to a peering point over which you will run peering traffic because the device at the data centre can't support peering, or running a tunnel between two PoP's to handle intra-PoP traffic, e.t.c. When you have all these tunnels running around, side-by-side with customer revenue-generating tunnels for their own sake (like a site-to-site l2vpn you've sold to a customer), it can get hairy at scale, I think. Too much inter-dependence, too many lines coming together. But again, that's just me. Mark. From randy at psg.com Sat Jun 18 11:10:15 2016 From: randy at psg.com (Randy Bush) Date: Sat, 18 Jun 2016 20:10:15 +0900 Subject: RPKI implementation In-Reply-To: References: Message-ID: >> i am aware of that. my point was that cache purge default might >> better be set to cache refresh interval than 60 secs. > > I would agree with (and in fact, prefer) this protocol. i remembered wrongly RFC6810 A client SHOULD delete the data from a cache when it has been unable to refresh from that cache for a configurable timer value. The default for that value is twice the polling period for that cache. randy From bross at pobox.com Sat Jun 18 17:54:01 2016 From: bross at pobox.com (Brandon Ross) Date: Sat, 18 Jun 2016 13:54:01 -0400 (EDT) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: On Fri, 17 Jun 2016, Eric Kuhnke wrote: > What Randy just wrote is exactly the point I was trying to make in my last > email. Some real estate facility owners/managers have got into the mistaken > mindset that they can get the greatest value and the most monthly revenue > from the square-footage of their building by charging additional MRC XC > fees to the tenants of the building. There are some VERY sucessful companies that would strongly disagree with you. > When in fact the opposite is true, and we need a concerted community effort > to lobby every IX real estate owner with this fact: Your real estate will > be MORE valuable and will attract a greater critical mass of carriers, > eyeball networks, CDNs, huge hosting providers/colo/VM, etc if you make the > crossconnects free. But then why would we want to do that? If you are correct and doing so would raise the value of the real esatate, doesn't that mean that the building managers would be able to charge operators a whole lot more than they are able to today, in aggregate? Value based pricing is all the rage these days, which is why they charge you so much for cross connects. Why do you think they wouldn't take advantage of higher value real estate by charging you more for that, instead? After all, the free cross connect situation would be a great way for the owners to lock you into their real estate, then all they have to do is dramatically hike the rates when you can no longer leave. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From baldur.norddahl at gmail.com Sat Jun 18 19:31:37 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 18 Jun 2016 21:31:37 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: On 18 June 2016 at 13:07, Mark Tinka wrote: > > Our PoPs are connected in a ring topology (actually multiple rings). If a > > link goes down somewhere, or an intermediate device crashes, the L2VPN > will > > reconfigure and find another path. > > Which is what would happen anyway with your IGP if the service were > delivered in the Access, but with fewer moving parts and less > inter-dependence if the problem went beyond just ring failure or device > crash. > Is the claim about fewer moving parts actually true? Yes if you are comparing to a plain native single-stack network with IPv4 (or IPv6) directly on the wire. But we are doing MPLS, so in our case it is L2VPN vs L3VPN. Both will reroute using the exact same mechanism, so no difference here. I found that I could remove large parts of the configuration on the access edge devices when we went from L3VPN to L2VPN. Some people will find the network easier to understand when all major configuration is in only two devices, and those two devices are mostly a mirror of each other. I agree that L3VPN is the better solution, at least in principle. That is why we started by implementing L3VPN. But in practice the L2VPN solution we have now is actually easier. Regards, Baldur From baldur.norddahl at gmail.com Sat Jun 18 19:55:09 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 18 Jun 2016 21:55:09 +0200 Subject: 1GE L3 aggregation In-Reply-To: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> Message-ID: On 18 June 2016 at 13:04, Mark Tinka wrote: > We push IP/MPLS all the way into the Metro-E Access using a team of > Cisco ASR920's and ME3600X's. The value of being able to instantiate an > IP service or BGP session directly in the Metro-E Access simplifies > network operations a great deal for us. Needless to say, not having to > deal with eBGP Multi-Hop drama does not hurt. > Just want to point out that there is no eBGP multi-hop involved. These are L2 tunnels so the devices appear to be directly connected on the layer 3 level. The advantage of using L2VPN is that you can connect the customer to whatever can handle the requirements. You are not limited to what your access edge devices can do. 99% of our customers are not BGP customers, so it would be silly to spend cash on equipment that will support full table BGP at each PoP. The major downside is a) hops are invisible to traceroute, b) some traffic might travel longer than necessary. We are a residential ISP and we find that traffic between customers is minimal. We choose to accept that traffic between two neighbors might be backhauled to a central location and back instead of staying local. Regards, Baldur From swmike at swm.pp.se Sat Jun 18 20:05:30 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 18 Jun 2016 22:05:30 +0200 (CEST) Subject: Do people even read these? Re: BGP Update Report In-Reply-To: <201606172200.u5HM05Fo046561@wattle.apnic.net> References: <201606172200.u5HM05Fo046561@wattle.apnic.net> Message-ID: On Fri, 17 Jun 2016, cidr-report at potaroo.net wrote: > > TOP 20 Unstable Prefixes > Rank Prefix Upds % Origin AS -- AS Name > 1 - 202.65.32.0/21 28086 0.8% AS10131 -- CKTELECOM-CK-AP Telecom Cook Islands, CK > 2 - 110.170.17.0/24 21868 0.7% AS134438 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited, TH > 3 - 123.231.192.0/24 21562 0.7% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID > 4 - 93.181.192.0/19 20895 0.6% AS13118 -- ASN-YARTELECOM Verhnevolzhsky branch, RU > 5 - 123.231.206.0/24 19170 0.6% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID > 6 - 123.231.193.0/24 19082 0.6% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID > 7 - 195.128.159.0/24 15455 0.5% AS56636 -- ASVEDARU , RU > 8 - 192.254.88.0/24 15452 0.5% AS21859 -- ZNET - Zenlayer Inc, US > 9 - 185.11.121.0/24 14957 0.5% AS202105 -- DSP-AS , SA Everyone of these prefixes have managed to average one update per 40 seconds during a week, or worse. How is that even possible? Yes, I know we don't generally have dampening anymore, but geez, that's a lot of updates. -- Mikael Abrahamsson email: swmike at swm.pp.se From larrysheldon at cox.net Sat Jun 18 20:23:02 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 18 Jun 2016 15:23:02 -0500 Subject: Do people even read these? Re: BGP Update Report In-Reply-To: References: <201606172200.u5HM05Fo046561@wattle.apnic.net> Message-ID: You did. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From gih at apnic.net Sat Jun 18 21:22:08 2016 From: gih at apnic.net (Geoff Huston) Date: Sun, 19 Jun 2016 07:22:08 +1000 Subject: Do people even read these? Re: BGP Update Report In-Reply-To: References: <201606172200.u5HM05Fo046561@wattle.apnic.net> Message-ID: <44026AF3-24C5-42D6-B2F2-972A66E656D6@apnic.net> > On 19 Jun 2016, at 6:05 AM, Mikael Abrahamsson wrote: > > On Fri, 17 Jun 2016, cidr-report at potaroo.net wrote: > >> >> TOP 20 Unstable Prefixes >> Rank Prefix Upds % Origin AS -- AS Name >> 1 - 202.65.32.0/21 28086 0.8% AS10131 -- CKTELECOM-CK-AP Telecom Cook Islands, CK >> 2 - 110.170.17.0/24 21868 0.7% AS134438 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited, TH >> 3 - 123.231.192.0/24 21562 0.7% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID >> 4 - 93.181.192.0/19 20895 0.6% AS13118 -- ASN-YARTELECOM Verhnevolzhsky branch, RU >> 5 - 123.231.206.0/24 19170 0.6% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID >> 6 - 123.231.193.0/24 19082 0.6% AS133841 -- IDOLA-BROADBAND-AS-ID INDONESIA BROADBAND ACCESS - ANYWHERE, ID >> 7 - 195.128.159.0/24 15455 0.5% AS56636 -- ASVEDARU , RU >> 8 - 192.254.88.0/24 15452 0.5% AS21859 -- ZNET - Zenlayer Inc, US >> 9 - 185.11.121.0/24 14957 0.5% AS202105 -- DSP-AS , SA > > Everyone of these prefixes have managed to average one update per 40 seconds during a week, or worse. How is that even possible? Yes, I know we don't generally have dampening anymore, but geez, that's a lot of updates. > In the case of Cook Islands Telecom the problem is not directly with them - its their one-up upstream Spark NZ (AS4648) who appears to be flicking this route across a number of transit upstreams (http://bgpupdates.potaroo.net/cgi-bin/per-prefix?prefix=202.65.32.0.21) Geoff From glen.kent at gmail.com Sat Jun 18 21:27:39 2016 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 19 Jun 2016 02:57:39 +0530 Subject: IP and Optical domains? Message-ID: HI, I was reading the following article: http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616 It says that "The IP layer and optical layer are run like two separate kingdoms," Wellingstein says. "Two separate kings manage the IP and optical networks. There is barely any resource alignment between them. The result of this is that the networks are heavily underutilized," or, from an alternative perspective, "they are heavily over-provisioned." Can somebody shed more light on what it means to say that the IP and optical layers are run as independent kingdoms and why do ISPs need to over-provision? Thanks, Glen From swmike at swm.pp.se Sat Jun 18 22:00:42 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 19 Jun 2016 00:00:42 +0200 (CEST) Subject: IP and Optical domains? In-Reply-To: References: Message-ID: On Sun, 19 Jun 2016, Glen Kent wrote: > Can somebody shed more light on what it means to say that the IP and > optical layers are run as independent kingdoms and why do ISPs need to > over-provision? You have a group that runs fiber+dwdm+sonet(or SDH). You have another group that runs IP. When the IP guys ask "please tell us how the optical network is designed, and can we coordinate how they're built and btw, we want to put DWDM optics in our routers", the answer from the fiber+dwdm+sonet group is "no, but we can help you with transport using our transponders, please just order circuits, just give us addresses for each end and we'll take care of things, don't you worry your little IP engineer brain how things are transported long distance". I believe this is still the case at a lot of ISPs. Not all, hopefully not even most, but I'm sure there are some. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sat Jun 18 23:07:48 2016 From: randy at psg.com (Randy Bush) Date: Sun, 19 Jun 2016 08:07:48 +0900 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: > You have a group that runs fiber+dwdm+sonet(or SDH). You have another > group that runs IP. When the IP guys ask "please tell us how the optical > network is designed, and can we coordinate how they're built and btw, we > want to put DWDM optics in our routers", the answer from the > fiber+dwdm+sonet group is "no, but we can help you with transport using > our transponders, please just order circuits, just give us addresses for > each end and we'll take care of things, don't you worry your little IP > engineer brain how things are transported long distance". > > I believe this is still the case at a lot of ISPs. Not all, hopefully not > even most, but I'm sure there are some. you underestimate the extent of the dogged determination of circuitzilla to hang on to the fiber with her/his fingernails. randy From nanog at radu-adrian.feurdean.net Fri Jun 17 20:50:02 2016 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 17 Jun 2016 22:50:02 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: <46d8fa31-0f36-5fcc-4b88-86d58343f8a0@gmail.com> Message-ID: <1466196602.2428899.641070681.780204F3@webmail.messagingengine.com> On Fri, Jun 17, 2016, at 12:43, Saku Ytti wrote: > Last I checked you can't commit/replace configuration in VRP. Has this > changed? Can you give it full new config and expect it to figure out > how to apply the new config without breaking existing? ... later... > Yeah it's best I've seen. 8-10k isn't anything special. I suppose that's the reason I didn't see the Brocade CER-RT (some time ago best-seller) listed. Probably the lack of need for full-table FIB also counts. From james.jun at towardex.com Sat Jun 18 15:37:11 2016 From: james.jun at towardex.com (James Jun) Date: Sat, 18 Jun 2016 11:37:11 -0400 Subject: 1GE L3 aggregation In-Reply-To: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> Message-ID: <20160618153711.GA26667@mis10.towardex.com> On Sat, Jun 18, 2016 at 01:04:49PM +0200, Mark Tinka wrote: > > Centralizing is just horrible, but that's just me. The goal is to make > all these unreliable boxes work together to offer a reliable service to > your customers, so making them too inter-dependent on each other has the > potential to that away in the long run. > One issue with pushing IP transit (L3-wise) with small boxes down to the metro is that if a particular customer comes under attack, any DDoS in excess of 10-30 Gbps is going to totally destroy the remote site down to the floor and then some, until NOC intervenes to restore service. A Big Expensive Router at head-end site fed with big pipes to your IP core just needs a subscriber line rate policer configured on the customer EVC off the NNI facing your metro transport network, largely protecting your metro POP during an attack. There are also issues with control-plane policing (or limited options there of) with some of these low-end platforms. > > We push IP/MPLS all the way into the Metro-E Access using a team of > Cisco ASR920's and ME3600X's. The value of being able to instantiate an > IP service or BGP session directly in the Metro-E Access simplifies > network operations a great deal for us. Needless to say, not having to > deal with eBGP Multi-Hop drama does not hurt. BGP Selective Download has its own drawbacks too--in that, it's largely meant to be used on single-tailed environment with FIB only having single point of egress. Consider a topology where an ASR920 in the metro is dual-homed to two peering sites using variably distant dark fiber (say 30km to Site A, 90km to Site B), with IGP costs configured to conform to fiber distances. How will you guarantee that the best-path that ASR920 chooses for your customer taking full table to be actually congruent with the box's real forwarding path? Your 920 may choose site A as best-path, only to see FIB-programmed default route to force it out on site B. If you're doing active-standby on your fiber uplinks, then it would not be an issue; or may be in metro environment where latency differences are minimal (<1ms), you probably don't care in practice to be bothered with that. Yes, there are some operational complexities and issues with L2vpn'ing customers to head-end router -- such as, link-state propagation needs to be properly validated; and now you're burning two ports instead of one, one at the terminus, one at the access, doubling SPOF and maintenance liabilities. At the end of the day, it's lack of full-featured ports at reasonable cost that drive centralization to head-ends. Spamming Small Expensive Routers (ASR9001/MX104) in every small metro site doesn't scale (btdt myself), but neither is hacking up BGP to work on platforms that aren't really meant to function as heavy L3 routers (e.g. ASR920, ME3600), IMHO. James From nick.crocker at gmail.com Fri Jun 17 21:44:16 2016 From: nick.crocker at gmail.com (Nick Crocker) Date: Fri, 17 Jun 2016 21:44:16 +0000 Subject: AT&T Austin multiple 10Gs hard down, anyone seeing issues as well? Message-ID: Looking at some sites and hearing chatter of a pretty wide scale AT&T outage in the Austin and surrounding areas. I have two 10Gs one fed out of Pflugerville, TX and one out of Austin, TX with PE's in Austin, TX and San Antonio, TX. Both dropped at the same time and are on diverse fiber routes and entrance facilities with power and equipment verified. Regards, Nick From glen.kent at gmail.com Sun Jun 19 01:28:58 2016 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 19 Jun 2016 06:58:58 +0530 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: Mikael, Thanks. I was looking at a technical problem. I say this because you may not have this problem when both are networks are being run by the same vendor equipment, say Alcatel-Lucent (or Nokia now). What are the technical problems because of which ISPs need to over-provision when there are IP and optical domains involved. OR rather let me rephrase my question -- what is the technical challenge involved in setting up an end to end path between two IP domains that have an optical domain in between. Thanks, Glen On Sun, Jun 19, 2016 at 3:30 AM, Mikael Abrahamsson wrote: > On Sun, 19 Jun 2016, Glen Kent wrote: > > Can somebody shed more light on what it means to say that the IP and >> optical layers are run as independent kingdoms and why do ISPs need to >> over-provision? >> > > You have a group that runs fiber+dwdm+sonet(or SDH). You have another > group that runs IP. When the IP guys ask "please tell us how the optical > network is designed, and can we coordinate how they're built and btw, we > want to put DWDM optics in our routers", the answer from the > fiber+dwdm+sonet group is "no, but we can help you with transport using our > transponders, please just order circuits, just give us addresses for each > end and we'll take care of things, don't you worry your little IP engineer > brain how things are transported long distance". > > I believe this is still the case at a lot of ISPs. Not all, hopefully not > even most, but I'm sure there are some. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From saku at ytti.fi Sun Jun 19 08:17:35 2016 From: saku at ytti.fi (Saku Ytti) Date: Sun, 19 Jun 2016 11:17:35 +0300 Subject: 1GE L3 aggregation In-Reply-To: <20160618153711.GA26667@mis10.towardex.com> References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> <20160618153711.GA26667@mis10.towardex.com> Message-ID: On 18 June 2016 at 18:37, James Jun wrote: Hey, > One issue with pushing IP transit (L3-wise) with small boxes down to the > metro is that if a particular customer comes under attack, any DDoS in > excess of 10-30 Gbps is going to totally destroy the remote site down to > the floor and then some, until NOC intervenes to restore service. > > A Big Expensive Router at head-end site fed with big pipes to your IP core > just needs a subscriber line rate policer configured on the customer EVC > off the NNI facing your metro transport network, largely protecting your > metro POP during an attack. This is weak rationale. The flip side of this rationale is that the centralised aggregation, when attacked will bring down all the 'remote sites'. Now which is more typical reason for outage, I don't know. But of course the L3 situation can be policed in many places, you can police it at network ingress, you can police it between upper level aggregation and downstream aggregation. I do understand the centralised aggregation, particularly like Baldur explained if only very few customers will have IP transit, it's silly to pay 5k-10k for full DFZ box, when you can probably get L2VPN box for hundreds of bucks. In my case almost all of the customers would have IP transit with full BGP. But I do think, that if L3 to the edge had no commercial problems, people would universally choose to do it. L2VPN is just workaround to a commercial problem. Sometimes (residential access) to a technical problem (how do I share my IPv4 space effectively). > There are also issues with control-plane policing (or limited options > there of) with some of these low-end platforms. I'm not really looking cheap pipeline box, I'm looking run-to-completion NPU box with 1GE edge. The Huawei NE20E-S2F proposal was fine, ASR9001 and MX104 are not ok (Both having less than beefy control-plane, while forwarding plane in all is fine). ALU SR would be fine, but I have specific need for configuration management not today supported by TimOS. But even higher-end kit usually have plenty of vectors to do collateral damage, particularly if attacker is one of the customers. For example in ASR9k, you can't really protect customerA from customerB doing eBGP/ICMP/ARP flood, customerB does not have to be malicious, might be just internal L2 loop causing high rate of packets at provider port. -- ++ytti From dave at temk.in Sun Jun 19 13:19:16 2016 From: dave at temk.in (Dave Temkin) Date: Sun, 19 Jun 2016 08:19:16 -0500 Subject: cross connects and their pound of flesh Message-ID: On Sat, Jun 18, 2016 at 12:54 PM, Brandon Ross wrote: > > > Value based pricing is all the rage these days, which is why they charge > you so much for cross connects. Exactly. Not that I don't like free cross connects (they're the bees knees, in fact), but at the end of the day, an existing colo operator is not going to go from paid->free cross connects without extracting that pound of flesh (read: sweet sweet 100% pure margin) from somewhere else. Your space and/or power prices will go up to backfill that lost profit. That said, those of us that buy a decent amount of colo prefer to trade in the value of the asset leased/purchased - space & power - as we have real world indexes to tie the underlying cost to for negotiation purposes. And as colo operators get freaked out over margin compression on the impending 10->100G conversion (which is happening exponentially faster than 100->1G & 1G->10G) they'll need to move those levers of spend around regardless. -Dave From nanog at ics-il.net Sun Jun 19 13:33:14 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 19 Jun 2016 08:33:14 -0500 (CDT) Subject: cross connects and their pound of flesh In-Reply-To: References: Message-ID: <288653906.62077.1466343193600.JavaMail.mhammett@ThunderFuck> I think that's where the value in a distributed IX comes into play. The more nimble networks can move to different facilities while still maintaining the connectivity. Enough of that happens and pricing pressure comes into play in other parts of the market (space and cross connects). For those of you that operate in many markets, do you see any parallels where one operator has (or had) a hold on the market (Chicago Equinix and Miami Terremark for instance) compared to more diversified markets like NYC (due to a variety of IXes) or Seattle (due to SIX)? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Dave Temkin" To: "Brandon Ross" Cc: "North American Network Operators' Group" Sent: Sunday, June 19, 2016 8:19:16 AM Subject: Re: cross connects and their pound of flesh On Sat, Jun 18, 2016 at 12:54 PM, Brandon Ross wrote: > > > Value based pricing is all the rage these days, which is why they charge > you so much for cross connects. Exactly. Not that I don't like free cross connects (they're the bees knees, in fact), but at the end of the day, an existing colo operator is not going to go from paid->free cross connects without extracting that pound of flesh (read: sweet sweet 100% pure margin) from somewhere else. Your space and/or power prices will go up to backfill that lost profit. That said, those of us that buy a decent amount of colo prefer to trade in the value of the asset leased/purchased - space & power - as we have real world indexes to tie the underlying cost to for negotiation purposes. And as colo operators get freaked out over margin compression on the impending 10->100G conversion (which is happening exponentially faster than 100->1G & 1G->10G) they'll need to move those levers of spend around regardless. -Dave From brandon at rd.bbc.co.uk Sun Jun 19 13:55:57 2016 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 19 Jun 2016 14:55:57 +0100 (BST) Subject: cross connects and their pound of flesh Message-ID: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> Dave Temkin wrote: > And as colo operators get freaked out over margin compression on the > impending 10->100G conversion (which is happening exponentially faster than > 100->1G & 1G->10G) they'll need to move those levers of spend around > regardless. If they've based their model on extracting profit proportional to technology speed then they've misunderstood Moore's law brandon From nanog at ics-il.net Sun Jun 19 14:07:27 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 19 Jun 2016 09:07:27 -0500 (CDT) Subject: cross connects and their pound of flesh In-Reply-To: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> Message-ID: <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> Before 100G, you'd need ten cross connects to move 100G. Now you'd need only one. That's a big drop in revenue. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Brandon Butterworth" To: bross at pobox.com, dave at temk.in Cc: nanog at nanog.org Sent: Sunday, June 19, 2016 8:55:57 AM Subject: Re: cross connects and their pound of flesh Dave Temkin wrote: > And as colo operators get freaked out over margin compression on the > impending 10->100G conversion (which is happening exponentially faster than > 100->1G & 1G->10G) they'll need to move those levers of spend around > regardless. If they've based their model on extracting profit proportional to technology speed then they've misunderstood Moore's law brandon From ggrammel at juniper.net Sun Jun 19 14:09:01 2016 From: ggrammel at juniper.net (Gert Grammel) Date: Sun, 19 Jun 2016 14:09:01 +0000 Subject: IP and Optical domains? Message-ID: Glen, Here's a list of technical issues for whatever it is worth: Transport networks assume a service to be a circuit with two end-points which optionally can be protected by some transport mechanisms. Each of such services is unrelated to others. In a routed network a transport service corresponds to a link adjacency between routers. To design a resilient router network it is desired that links between different pairs of routers are unrelated to each other and don't fail together (are shared-risk-link-group diverse). Hence links are related in being unrelated. Now let's start: 1) transport folks don't disclose their physical topology: no chance to design a reliably resilient network on top. Workaround: ask for protected transport links. This increased availability comes with the cost of duplicating transport resources. Actually it is often more than double since the protecting circuit is a bit longer than the protected one. 2) transport folks do disclose the physical topology including nodes. Considering those nodes as single point of failure, it requires more BW available in Routers to cover failures and tricky configuration. 3) alternatively you could ask to install more transport equipment to avoid SPOF which obviously comes with a price tag too 4) once settled, the Transport network may grow. This means that circuits once in a while get moved to other resources. Typically the result of a transport network re-planning, a protection action or simply a forgotten reversion after a maintenance event. Consequently, whatever was achieved in 2) or 3) may just become void over time. There are basically two ways to deal with the complexity: 1) create an information exchange that let networking and transport controllers take informed decisions: You may want to look at https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ 2) forget about switching anything in Transport, nail the structure down in config and move on. You may like then https://meetings.ripe.net/see3/files/Ian_Farrer-The_Terastream_Native_IPv6_Network_Architecture.pdf If you now think transport is all the same, irrespective of technology, then I suggest to take another breath: 1) since multiplexing lambdas is passive, Operators often do not count WDM or ROADM nodes as SPOF. Note: multiplexing is indeed passive but followed by Amplifiers which are not. 2) in SONET one could connect any vendor's node to everyone else's e.g. With OC48. This is not true in DWDM. While the Ethernet connecting to a wavelength is a standard, the wavelength itself is proprietary and linked to the component vendor of the transceiver. Transponders are in fact acting as adaptor plugs between standard and proprietary transport. As a result, if you find a left-over Gen-1 transponder and want to hook it up to a Gen-3 transponder of the same system vendor - it may not work because the component supplier changed. It also means you can't simply re-structure a DWDM network in an on-demand manner if such effects are present. I leave it up to you to draw your own conclusions. Gert Sent from my Apple ][) From deleskie at gmail.com Sun Jun 19 14:13:28 2016 From: deleskie at gmail.com (jim deleskie) Date: Sun, 19 Jun 2016 11:13:28 -0300 Subject: cross connects and their pound of flesh In-Reply-To: <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> Message-ID: I don't buy this. They sold you one cable before, they sell you cable now. Little difference then we moved customers from a T1 to T3 back in the 90's. If Colo's can't understand more then 20+ yrs of evolution its hardly right to blame it on the market. -jim Mimir Networks www.mimirnetworks.com On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett wrote: > Before 100G, you'd need ten cross connects to move 100G. Now you'd need > only one. That's a big drop in revenue. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Brandon Butterworth" > To: bross at pobox.com, dave at temk.in > Cc: nanog at nanog.org > Sent: Sunday, June 19, 2016 8:55:57 AM > Subject: Re: cross connects and their pound of flesh > > Dave Temkin wrote: > > And as colo operators get freaked out over margin compression on the > > impending 10->100G conversion (which is happening exponentially faster > than > > 100->1G & 1G->10G) they'll need to move those levers of spend around > > regardless. > > If they've based their model on extracting profit proportional > to technology speed then they've misunderstood Moore's law > > brandon > > From patrick at ianai.net Sun Jun 19 15:30:02 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 19 Jun 2016 11:30:02 -0400 Subject: cross connects and their pound of flesh In-Reply-To: References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> Message-ID: Actually, back in the T1/T3 days, colos frequently asked what you ran on the cable and then charged you based on the capacity of the circuit - even when it was the same exact cable. Of course, none of us would ever ask for T1 xconn then run ethernet over it. Colo providers are absolutely worried about drops in xconn revenue. Look at some large colo providers who are public and split out their numbers. You?ll see that the percentage of their profit from xconns is usually more than double the percentage of their revenue from xconns. Put another way, if xconn revenue drops by 10%, their profit drops by over 20%. How many public companies can shrug off a 20% drop in EPS? I submit: Not very many. This is not surprising. When you build your business on the ignorance of your customers, you are in a world of hurt once your customers learn even a little bit more. -- TTFN, patrick > On Jun 19, 2016, at 10:13 AM, jim deleskie wrote: > > I don't buy this. They sold you one cable before, they sell you cable now. > Little difference then we moved customers from a T1 to T3 back in the > 90's. If Colo's can't understand more then 20+ yrs of evolution its hardly > right to blame it on the market. > > > -jim > Mimir Networks > www.mimirnetworks.com > > > On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett wrote: > >> Before 100G, you'd need ten cross connects to move 100G. Now you'd need >> only one. That's a big drop in revenue. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Brandon Butterworth" >> To: bross at pobox.com, dave at temk.in >> Cc: nanog at nanog.org >> Sent: Sunday, June 19, 2016 8:55:57 AM >> Subject: Re: cross connects and their pound of flesh >> >> Dave Temkin wrote: >>> And as colo operators get freaked out over margin compression on the >>> impending 10->100G conversion (which is happening exponentially faster >> than >>> 100->1G & 1G->10G) they'll need to move those levers of spend around >>> regardless. >> >> If they've based their model on extracting profit proportional >> to technology speed then they've misunderstood Moore's law >> >> brandon >> >> From mark.tinka at seacom.mu Sun Jun 19 15:41:56 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 19 Jun 2016 17:41:56 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <15d20e1f-740c-2c53-bded-52a6a982c243@dialtelecom.cz> <20160616151719.GB9938@excession.tpb.net> <98BAD9E6-B4C7-44EA-A906-1D5466B93371@isprime.com> Message-ID: <53a6de62-3dee-822d-6779-947c184dc795@seacom.mu> On 17/Jun/16 01:06, Phil Rosenthal wrote: > 3) Remote peering -- This is mostly a question about distance for value. There is a clear benefit in providing multi-datacenter exchanges within a metro, and both FL-IX and SIX are doing this with a very good value proposition. Having the ability to join DECIX Frankfurt from NYC and vice versa -- again, this is a bizarre service to be offered, and regular users should not be expected to pay for this. If there is a market for these services at an unsubsidized price, then fine -- but regular members should not be subsidizing this service. Remote peers have to pay for ports and membership the same way native peers do. Why would you think native peers would be subsidizing remote peers? Mark. From dave at temk.in Sun Jun 19 16:21:57 2016 From: dave at temk.in (Dave Temkin) Date: Sun, 19 Jun 2016 16:21:57 +0000 (UTC) Subject: cross connects and their pound of flesh In-Reply-To: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> Message-ID: If you look at companies that have foundered due to failure to innovate, most of the time it's because they were too focused on what made them money then, not what was going to make them money 5 years from then. And networks don't track very well to Moore's law... _____________________________ From: Brandon Butterworth Sent: Sunday, June 19, 2016 9:56 AM Subject: Re: cross connects and their pound of flesh To: , Cc: If they've based their model on extracting profit proportional to technology speed then they've misunderstood Moore's law brandon From thegameiam at yahoo.com Sun Jun 19 17:02:27 2016 From: thegameiam at yahoo.com (David Barak) Date: Sun, 19 Jun 2016 10:02:27 -0700 Subject: cross connects and their pound of flesh In-Reply-To: References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> Message-ID: <63D33C31-6D05-4C96-A1B7-E9A32D3C2706@yahoo.com> Gotta watch out for specifying T1 when you want Ethernet- they could just give you 4 wires on pins 1,2,4,5 :) I see the problem as misunderstanding what "physical" actually means: 4-wire twisted pair is different from 8-wire, is different from coax, is different from SMF etc. what gets run over it is nobody's business but the person controlling the end points. David Barak Sent from mobile device, please excuse autocorrection artifacts > On Jun 19, 2016, at 8:30 AM, Patrick W. Gilmore wrote: > > Actually, back in the T1/T3 days, colos frequently asked what you ran on the cable and then charged you based on the capacity of the circuit - even when it was the same exact cable. Of course, none of us would ever ask for T1 xconn then run ethernet over it. > > Colo providers are absolutely worried about drops in xconn revenue. Look at some large colo providers who are public and split out their numbers. You?ll see that the percentage of their profit from xconns is usually more than double the percentage of their revenue from xconns. Put another way, if xconn revenue drops by 10%, their profit drops by over 20%. How many public companies can shrug off a 20% drop in EPS? I submit: Not very many. > > This is not surprising. When you build your business on the ignorance of your customers, you are in a world of hurt once your customers learn even a little bit more. > > -- > TTFN, > patrick > >> On Jun 19, 2016, at 10:13 AM, jim deleskie wrote: >> >> I don't buy this. They sold you one cable before, they sell you cable now. >> Little difference then we moved customers from a T1 to T3 back in the >> 90's. If Colo's can't understand more then 20+ yrs of evolution its hardly >> right to blame it on the market. >> >> >> -jim >> Mimir Networks >> www.mimirnetworks.com >> >> >>> On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett wrote: >>> >>> Before 100G, you'd need ten cross connects to move 100G. Now you'd need >>> only one. That's a big drop in revenue. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Brandon Butterworth" >>> To: bross at pobox.com, dave at temk.in >>> Cc: nanog at nanog.org >>> Sent: Sunday, June 19, 2016 8:55:57 AM >>> Subject: Re: cross connects and their pound of flesh >>> >>> Dave Temkin wrote: >>>> And as colo operators get freaked out over margin compression on the >>>> impending 10->100G conversion (which is happening exponentially faster >>> than >>>> 100->1G & 1G->10G) they'll need to move those levers of spend around >>>> regardless. >>> >>> If they've based their model on extracting profit proportional >>> to technology speed then they've misunderstood Moore's law >>> >>> brandon > From patrick at ianai.net Sun Jun 19 17:08:33 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 19 Jun 2016 13:08:33 -0400 Subject: cross connects and their pound of flesh In-Reply-To: <63D33C31-6D05-4C96-A1B7-E9A32D3C2706@yahoo.com> References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> <63D33C31-6D05-4C96-A1B7-E9A32D3C2706@yahoo.com> Message-ID: You assume things like "nobody's business" has something to do with "extracting money". -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Jun 19, 2016, at 13:02, David Barak wrote: > > Gotta watch out for specifying T1 when you want Ethernet- they could just give you 4 wires on pins 1,2,4,5 :) > > I see the problem as misunderstanding what "physical" actually means: 4-wire twisted pair is different from 8-wire, is different from coax, is different from SMF etc. what gets run over it is nobody's business but the person controlling the end points. > > David Barak > Sent from mobile device, please excuse autocorrection artifacts > >> On Jun 19, 2016, at 8:30 AM, Patrick W. Gilmore wrote: >> >> Actually, back in the T1/T3 days, colos frequently asked what you ran on the cable and then charged you based on the capacity of the circuit - even when it was the same exact cable. Of course, none of us would ever ask for T1 xconn then run ethernet over it. >> >> Colo providers are absolutely worried about drops in xconn revenue. Look at some large colo providers who are public and split out their numbers. You?ll see that the percentage of their profit from xconns is usually more than double the percentage of their revenue from xconns. Put another way, if xconn revenue drops by 10%, their profit drops by over 20%. How many public companies can shrug off a 20% drop in EPS? I submit: Not very many. >> >> This is not surprising. When you build your business on the ignorance of your customers, you are in a world of hurt once your customers learn even a little bit more. >> >> -- >> TTFN, >> patrick >> >>> On Jun 19, 2016, at 10:13 AM, jim deleskie wrote: >>> >>> I don't buy this. They sold you one cable before, they sell you cable now. >>> Little difference then we moved customers from a T1 to T3 back in the >>> 90's. If Colo's can't understand more then 20+ yrs of evolution its hardly >>> right to blame it on the market. >>> >>> >>> -jim >>> Mimir Networks >>> www.mimirnetworks.com >>> >>> >>>> On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett wrote: >>>> >>>> Before 100G, you'd need ten cross connects to move 100G. Now you'd need >>>> only one. That's a big drop in revenue. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> Midwest Internet Exchange >>>> http://www.midwest-ix.com >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Brandon Butterworth" >>>> To: bross at pobox.com, dave at temk.in >>>> Cc: nanog at nanog.org >>>> Sent: Sunday, June 19, 2016 8:55:57 AM >>>> Subject: Re: cross connects and their pound of flesh >>>> >>>> Dave Temkin wrote: >>>>> And as colo operators get freaked out over margin compression on the >>>>> impending 10->100G conversion (which is happening exponentially faster >>>> than >>>>> 100->1G & 1G->10G) they'll need to move those levers of spend around >>>>> regardless. >>>> >>>> If they've based their model on extracting profit proportional >>>> to technology speed then they've misunderstood Moore's law >>>> >>>> brandon >> From brandon at rd.bbc.co.uk Sun Jun 19 21:40:59 2016 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 19 Jun 2016 22:40:59 +0100 (BST) Subject: cross connects and their pound of flesh Message-ID: <201606192140.WAA12758@sunf10.rd.bbc.co.uk> > From: "Patrick W. Gilmore" > Colo providers are absolutely worried about drops in xconn revenue. > Look at some large colo providers who are public and split out their > numbers. Youll see that the percentage of their profit from xconns is > usually more than double the percentage of their revenue from xconns. Perhaps their investors should have looked closely at those figures and priced according to risk. > Put another way, if xconn revenue drops by 10%, their profit drops by > over 20%. How many public companies can shrug off a 20% drop in EPS? I > submit: Not very many. Tough, revenues can go down as well as up. If you gouge your customers they will try harder to find ways not to give you money. If I have to do an xcon I prefer to do it in Telehouse rather than Telecity as Telecity is 100% more install and 32% more annually (Telehouse also discount for extra cores). Some USA DC are way more expensive than either of these UK DC (for now, UK DC only moved to the recurring fee model after it'd been established elsewhere) They've probably been using xcon revenue to make it look like they are still growing quickly to inflate share price. A few aquisitions can hide reality for a bit longer. Capitalism is great but it does lead to unreasonable expectations such as never ending growth xcon revenue worked for Telecity to get a nice buyout, be interesting to see how their new owners handle it. brandon From mark.tinka at seacom.mu Mon Jun 20 05:38:01 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 07:38:01 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> Message-ID: <6aab37e9-8adb-ee69-7d35-c739484224e5@seacom.mu> On 17/Jun/16 19:31, Seth Mattinen wrote: > > > I would expect some kind of MRC if it has any SLA, service, or support > attached. Or someone manages it and protects the infrastructure and > enforces the rules of the facility. Or the facility uses that money to > maintain the MMR. If it's a free for all where anyone can accidentally > unplug it or cut it or rummage around in the overhead causing damage > then free is fine. What I don't accept is variable pricing depending > on what the xconnect is carrying or what it's for. I don't buy into > the thought process that an xconnect is more expensive if it's > carrying 10GbE vs. GigE when they're both SMF. You won't see this is typical carrier-neutral facilities. You're more likely to see this in telco- or consortium-owned facilities, in specific regions that exploit telecommunications requirements to milk customers. Mark. From mark.tinka at seacom.mu Mon Jun 20 05:47:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 07:47:28 +0200 Subject: RPKI implementation In-Reply-To: References: Message-ID: <5f3d8c5a-1e02-0667-028e-1d151e4da60e@seacom.mu> On 18/Jun/16 13:10, Randy Bush wrote: > i remembered wrongly > > RFC6810 > > A client SHOULD delete the data from a cache when it has been unable > to refresh from that cache for a configurable timer value. The > default for that value is twice the polling period for that cache. I suppose that is alright since, in a redundant scenario, the data from the remaining cache that (hopefully) still has a live RTR session will continue to be valid. In single cache scenarios, waiting for some time after the cache has disappeared is akin to standard BGP session keepalive protocols. However, several vendors have implemented protocol enhancements to immediately drop BGP sessions that have failed, rather than wait for the Hold timer to expire. I see value in that, and perhaps it might make sense for an RPKI implementation to support the same where it is more important for the RPKI data to be as current as possible. Mark. From mark.tinka at seacom.mu Mon Jun 20 06:22:56 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 08:22:56 +0200 Subject: 1GE L3 aggregation In-Reply-To: <20160618153711.GA26667@mis10.towardex.com> References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> <20160618153711.GA26667@mis10.towardex.com> Message-ID: <0343af07-795a-73a3-cbdd-38c7a37e64de@seacom.mu> On 18/Jun/16 17:37, James Jun wrote: > One issue with pushing IP transit (L3-wise) with small boxes down to the > metro is that if a particular customer comes under attack, any DDoS in > excess of 10-30 Gbps is going to totally destroy the remote site down to > the floor and then some, until NOC intervenes to restore service. A DoS/DDoS attack on a central IP gateway is no safer from such a scenario. In fact, given the level of aggregation on a centralized router, the level of impact is likely to be higher. Moreover, the attack would still spread from the centralized router to the end customer until the NOC intervenes. So you aren't really gaining much by centralizing the router. > > A Big Expensive Router at head-end site fed with big pipes to your IP core > just needs a subscriber line rate policer configured on the customer EVC > off the NNI facing your metro transport network, largely protecting your > metro POP during an attack. So what do you do when an attack is coming from one of your Metro-E customers to another Metro-E customer? In such a case, you've just unnecessarily involved your centralized router in something it should not be aware of. > > There are also issues with control-plane policing (or limited options > there of) with some of these low-end platforms. On the ASR920's we use, CoPP is reasonable. But as with everything else, you have to make some compromises if you want to keep your costs down without sacrificing too much in operation. Given the spread you'd get with IP/MPLS in the Access, the problem is broken down into smaller, more manageable chunks, which appeals more to me. > BGP Selective Download has its own drawbacks too--in that, it's largely > meant to be used on single-tailed environment with FIB only having single > point of egress. > > Consider a topology where an ASR920 in the metro is dual-homed to two > peering sites using variably distant dark fiber (say 30km to Site A, > 90km to Site B), with IGP costs configured to conform to fiber distances. For us, that is not a Metro-E Access ring. It's too wide and would normally be broken up by some kind of PE Aggregation. If you're building Metro-E Access rings that wide, you're going to end up in trouble sooner rather than later. We build Metro-E Access rings within 1ms, and while 1ms will give you a 100km cable radius, we'd never build a Metro-E Access ring that wide. So we're typically running the rings at between 1km - 10km. And since we do latency-based IGP cost, there is no difference whether a ring is 1km or 10km wide (or even in your example, 30km vs. 90km). > > How will you guarantee that the best-path that ASR920 chooses for your > customer taking full table to be actually congruent with the box's > real forwarding path? Your 920 may choose site A as best-path, only > to see FIB-programmed default route to force it out on site B. If you're > doing active-standby on your fiber uplinks, then it would not be an issue; > or may be in metro environment where latency differences are minimal (<1ms), > you probably don't care in practice to be bothered with that. Not sure I get your scenario. We use BGP-SD where our Metro-E devices have iBGP sessions to our RR's. We download 0/0 + ::/0 + some other routes into FIB, and keep the rest in control plane. We do not see any discrepancy in NEXT_HOP data between the control or data plane when we run BGP-SD. Have you run into the issues you describe when you've turned on BGP-SD? > > Yes, there are some operational complexities and issues with L2vpn'ing > customers to head-end router -- such as, link-state propagation needs to > be properly validated; and now you're burning two ports instead of one, > one at the terminus, one at the access, doubling SPOF and maintenance > liabilities. The only use-case we've seen for centralizing routing is in a BNG scenario. I once attempted a distributed BNG design, but the issue was load on the control plane of each router (DHCP, session management, e.t.c.). One could deploy a dedicated edge router for BNG terminations alongside an edge router for Business/Wholesale customers, but that gets pricey, quickly. But even with centralized BNG's, we are now looking at ways to distribute them further with current virtualization technologies, into smaller islands that each can handle a decent amount of aggregate bandwidth. > > At the end of the day, it's lack of full-featured ports at reasonable cost > that drive centralization to head-ends. Spamming Small Expensive Routers > (ASR9001/MX104) in every small metro site doesn't scale (btdt myself), but > neither is hacking up BGP to work on platforms that aren't really meant to > function as heavy L3 routers (e.g. ASR920, ME3600), IMHO. I disagree. Adding high-end BGP support to the ME3600X/3800X might have been an afterthought, but we are lucky that it had sufficient resources to support it. On the ASR920, that was designed in from Day One, and we've been happy running full BGP there as well (in addition to doing it on the ME3600X as well). Been doing this 2010, and it's going well. The level of simplicity we enjoy, and how quickly we can turn up a customer service, the decoupling/independence of devices and the ability to run maintenance activities in a controlled way that minimize aggregate impact are benefits I'd never trade for a centralized router approach. Mark. From mark.tinka at seacom.mu Mon Jun 20 06:50:24 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 08:50:24 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: Message-ID: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> On 18/Jun/16 21:31, Baldur Norddahl wrote: > Is the claim about fewer moving parts actually true? Yes if you are > comparing to a plain native single-stack network with IPv4 (or IPv6) > directly on the wire. But we are doing MPLS, so in our case it is L2VPN vs > L3VPN. Both will reroute using the exact same mechanism, so no difference > here. I'm talking about all services. We deliver Internet Access/IP Transit, l2vpn's, and l3vpn's on the same chassis in the Access depending on what the customer wants. We are only touching one box in this case (the Access switch), and not more than one when delivering any of these services. This is what I mean by fewer moving parts - and if a problem were to occur in the Access or the core, provided that at least one path of the fibre was fine, that problem would be masked from the Access. When you have dependence between far-end devices (such as an l2vpn from the Access terminating on a centralized IP gateway for onward services), the coupling is too tight and makes things more fragile. > > I found that I could remove large parts of the configuration on the access > edge devices when we went from L3VPN to L2VPN. Some people will find the > network easier to understand when all major configuration is in only two > devices, and those two devices are mostly a mirror of each other. While I like lean configurations as much as the next guy, you can't run away from them. Removing lines from one device means you add more on another. Standardization of configurations means you know what to expect (and what not to expect) regardless of the number of devices. 2016 being all the "automation" and "zero touch deployment" rage, it is now possible to operate the network without having to struggle with what the configuration on each device is. I'd rather invest in that than centralized routers. > > I agree that L3VPN is the better solution, at least in principle. That is > why we started by implementing L3VPN. But in practice the L2VPN solution we > have now is actually easier. We don't run l3vpn's for infrastructure requirements. We only run them if a customer wants an l3vpn service. Mark. From mark.tinka at seacom.mu Mon Jun 20 06:59:22 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 08:59:22 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> Message-ID: <8b00fd67-2388-d062-0434-2618d898094c@seacom.mu> On 18/Jun/16 21:55, Baldur Norddahl wrote: > Just want to point out that there is no eBGP multi-hop involved. These are > L2 tunnels so the devices appear to be directly connected on the layer 3 > level. Agree, but there is still a disconnect between what the network knows is the actual physical path vs. what the actual physical path is. This might not be a big of an issue for most, or in cases where the l2vpn does not have to travel very far or via several links. But for us, it adds some complexity we'd rather do without. > > The advantage of using L2VPN is that you can connect the customer to > whatever can handle the requirements. You are not limited to what your > access edge devices can do. 99% of our customers are not BGP customers, so > it would be silly to spend cash on equipment that will support full table > BGP at each PoP. In the Access, 99% of our customers are Internet Access, i.e., not IP Transit, so don't need BGP. We have come across Internet Access customers that need to do BGP for redundancy, which turns into a private ASN job with them announcing our own routes back to us. But that tends to be the exception, about 0.2% of our deliveries. That notwithstanding, touching only one box to deliver an Internet Access service is a major win for us vs. touching more than one. And we are only burning one port in lieu of more than one. And there is only one place for us to look when troubleshooting issues instead of more than one. It's simple and brain-dead, which is what we like. > > The major downside is a) hops are invisible to traceroute, b) some traffic > might travel longer than necessary. For us, both of these are major drawbacks, and a huge advantage we gain by taking IP/MPLS into the Access. > > We are a residential ISP and we find that traffic between customers is > minimal. We choose to accept that traffic between two neighbors might be > backhauled to a central location and back instead of staying local. Which I accept in Broadband/BNG scenarios. But outside of that, well, you know my views by now :-)... Mark. From marco at paesani.it Mon Jun 20 06:59:57 2016 From: marco at paesani.it (Marco Paesani) Date: Mon, 20 Jun 2016 08:59:57 +0200 Subject: NOC Contact Megafon AS31133 Message-ID: Hi, I need a contact person NOC Megafon AS31133, can you help me ? Thanks ! Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From mark.tinka at seacom.mu Mon Jun 20 07:09:14 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 09:09:14 +0200 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: <01e755ec-3be8-fc3c-8892-dba24adcf0b9@seacom.mu> On 19/Jun/16 03:28, Glen Kent wrote: > Mikael, > > Thanks. I was looking at a technical problem. I say this because you may > not have this problem when both are networks are being run by the same > vendor equipment, say Alcatel-Lucent (or Nokia now). Even then. This isn't the first time the industry has tried to collapse Transport + IP into a single system. Many of us will remember the days of IPoDWDM. That flopped. Then came GMPLS, which flopped even more. That said, the hunt should not stop, and there probably is value for networks that run both their own Transport + IP infrastructure. For networks that lease all of their transport, not sure how this will help as transport providers will not open their networks up to 3rd party IP networks. > What are the technical > problems because of which ISPs need to over-provision when there are IP and > optical domains involved. OR rather let me rephrase my question -- what is > the technical challenge involved in setting up an end to end path between > two IP domains that have an optical domain in between. It's two different expenses. If routers made good DWDM switches, this would not be much of a problem, but they don't. So you need to two teams managing two different sets of kit and opex, which is what the industry has been trying to solve for some time now. How do we collapse both of these cost centres into one manageable expense, considering that the primary reason transport networks exist and expand today is to carry IP traffic? Mark. From mark.tinka at seacom.mu Mon Jun 20 07:14:02 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 09:14:02 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: <317d843f-4dea-2b07-3cdc-a936c185cee9@seacom.mu> <20160618153711.GA26667@mis10.towardex.com> Message-ID: <4b7961f4-09a8-d4ea-2a2c-486083ef685a@seacom.mu> On 19/Jun/16 10:17, Saku Ytti wrote: > But I do think, that if L3 to the edge had no commercial problems, > people would universally choose to do it. L2VPN is just workaround to > a commercial problem. Sometimes (residential access) to a technical > problem (how do I share my IPv4 space effectively). I think we are getting there now, with the ASR920 and friends. And who knows, with Arista now playing in the IP/MPLS space, they might make a switch worth its name against the traditional routing vendors. You must also consider that there are a number of engineers that generally prefer tunnels. I know it sounds silly, but I've come across several engineers who prefer the idea of centralizing services over a tunnel to a single box where the intelligence happens. I suppose the passion is as much the same as engineers who like MPLS vs. those that don't. But because Layer 2 switches will always be cheaper than IP/MPLS switches, I don't see this problem going away, even if an IP/MPLS switch cost US$200/unit vs. a Layer 2 switch which cost US$150/unit. Mark. From swmike at swm.pp.se Mon Jun 20 07:28:12 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jun 2016 09:28:12 +0200 (CEST) Subject: IP and Optical domains? In-Reply-To: <01e755ec-3be8-fc3c-8892-dba24adcf0b9@seacom.mu> References: <01e755ec-3be8-fc3c-8892-dba24adcf0b9@seacom.mu> Message-ID: On Mon, 20 Jun 2016, Mark Tinka wrote: > Many of us will remember the days of IPoDWDM. That flopped. Errrr, it didn't flop at all. I know lots of operators that do this. > For networks that lease all of their transport, not sure how this will > help as transport providers will not open their networks up to 3rd party > IP networks. Yeah, that's harder. Doing pure photonic transport is operationally difficult without management integration between optic transport provider and customer. That part hasn't happened. > It's two different expenses. If routers made good DWDM switches, this > would not be much of a problem, but they don't. So you need to two teams > managing two different sets of kit and opex, which is what the industry > has been trying to solve for some time now. How do we collapse both of > these cost centres into one manageable expense, considering that the > primary reason transport networks exist and expand today is to carry IP > traffic? I know operators who have collapsed their "core transport group" to handle Fiber+DWDM+SDH+IP (design/planning/3rd line operations). I know others where the IP and optical teams work very closely together and plan the network together. If your main business is transporting IP/MPLS then this is obvious that you need to have the teams work closely together. If your main business is to L2 switch or bit transport lots of TDM/L2 traffic, then it's less obvious. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Mon Jun 20 07:59:03 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 09:59:03 +0200 Subject: IP and Optical domains? In-Reply-To: References: <01e755ec-3be8-fc3c-8892-dba24adcf0b9@seacom.mu> Message-ID: <8af29906-e359-bd4d-7891-fb62924bbaa6@seacom.mu> On 20/Jun/16 09:28, Mikael Abrahamsson wrote: > > > Errrr, it didn't flop at all. I know lots of operators that do this. Not the technology - I meant the goal, i.e., that IPoDWDM will merge the optical and IP domains, simplify operations, remove the need for grey-light transponders 100%, make alien wavelengths more accessible, make GMPLS the unifying protocol between departments, e.t.c. It failed from that standpoint, but I do know a lot of networks that use it successfully. We've received requests for the same from our customers for our Transport service, but when they do the math on the optics, they just end up taking a regular EoDWDM port instead. > > > Yeah, that's harder. Doing pure photonic transport is operationally > difficult without management integration between optic transport > provider and customer. That part hasn't happened. And this has always been my biggest concern. Collapsing the optical and IP domains only, then, really appeals to operators that run their own network end-to-end. This relegates the opportunity to incumbents or ISP's and content providers that invest in their own dark fibre. Then again, the incumbents are a huge market for equipment and software vendors, so this will go on anyway, and those who lease capacity on a 100% basis will have to find their feet in all the mud. > > > I know operators who have collapsed their "core transport group" to > handle Fiber+DWDM+SDH+IP (design/planning/3rd line operations). I know > others where the IP and optical teams work very closely together and > plan the network together. > > If your main business is transporting IP/MPLS then this is obvious > that you need to have the teams work closely together. If your main > business is to L2 switch or bit transport lots of TDM/L2 traffic, then > it's less obvious. Agree. I run a team that manages both Transport and IP, so it's easier for us from this perspective. But several other operators, especially the large incumbents, have Chinese walls between both teams. Mark. From thomas.mangin at exa-networks.co.uk Mon Jun 20 07:59:58 2016 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Mon, 20 Jun 2016 08:59:58 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> http://exa.net.uk/about/contact-us On 17 Jun 2016, at 17:50, Dave Temkin wrote: > And with Equinix buying Telecity, how long until we see US-style XCs > in > Europe? Telecity Manchester (UK), now Equinix Manchester, have charged MRC for internal cabling since forever (in my case, forever being 2001 when I first became customer). They normally run their cables through their switches but when the distance is short enough you can insist on a P2P. Thomas From mark.tinka at seacom.mu Mon Jun 20 08:13:08 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 10:13:08 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> Message-ID: On 20/Jun/16 09:59, Thomas Mangin wrote: > > > Telecity Manchester (UK), now Equinix Manchester, have charged MRC for > internal cabling since forever (in my case, forever being 2001 when I > first became customer). > They normally run their cables through their switches but when the > distance is short enough you can insist on a P2P. Really? The x-connect is run through active equipment operated by the data centre? Is this a specific service you purchased, or is this the way they deliver x-connects? Mark. From JJaritsch at anexia-it.com Mon Jun 20 08:17:41 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Mon, 20 Jun 2016 08:17:41 +0000 Subject: AW: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> Message-ID: <1983e4b0d9ea43ef8b0024e7bced14ee@anx-i-dag02.anx.local> > Really? The x-connect is run through active equipment operated by the data centre? Same drama in Chicago with Atlantic Metro ... you can purchase a SMF DF xcon for 800USD/month ... everything else is actively transported on an Ethernet platform with simple/stupid VLAN tagging. You're even receiving their STP packets .... best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Mark Tinka Gesendet: Montag, 20. Juni 2016 10:13 An: Thomas Mangin; North American Network Operators' Group Betreff: Re: NANOG67 - Tipping point of community and sponsor bashing? On 20/Jun/16 09:59, Thomas Mangin wrote: > > > Telecity Manchester (UK), now Equinix Manchester, have charged MRC for > internal cabling since forever (in my case, forever being 2001 when I > first became customer). > They normally run their cables through their switches but when the > distance is short enough you can insist on a P2P. Really? The x-connect is run through active equipment operated by the data centre? Is this a specific service you purchased, or is this the way they deliver x-connects? Mark. From thomas.mangin at exa-networks.co.uk Mon Jun 20 08:30:21 2016 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Mon, 20 Jun 2016 09:30:21 +0100 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> Message-ID: <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> On 20 Jun 2016, at 9:13, Mark Tinka wrote: >> Telecity Manchester (UK), now Equinix Manchester, have charged MRC for >> internal cabling since forever (in my case, forever being 2001 when I >> first became customer). >> They normally run their cables through their switches but when the >> distance is short enough you can insist on a P2P. > > Really? The x-connect is run through active equipment operated by the > data centre? > > Is this a specific service you purchased, or is this the way they > deliver x-connects? It is how they provide x-connects. Thomas From mark.tinka at seacom.mu Mon Jun 20 08:32:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 10:32:36 +0200 Subject: AW: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <1983e4b0d9ea43ef8b0024e7bced14ee@anx-i-dag02.anx.local> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> <1983e4b0d9ea43ef8b0024e7bced14ee@anx-i-dag02.anx.local> Message-ID: <555319ad-9a83-f174-88c0-dd283e75b375@seacom.mu> On 20/Jun/16 10:17, J?rgen Jaritsch wrote: > Same drama in Chicago with Atlantic Metro ... you can purchase a SMF DF xcon for 800USD/month ... everything else is actively transported on an Ethernet platform with simple/stupid VLAN tagging. You're even receiving their STP packets .... Well, now I know where I won't co-lo... Mark. From mark.tinka at seacom.mu Mon Jun 20 08:33:12 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 10:33:12 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> Message-ID: On 20/Jun/16 10:30, Thomas Mangin wrote: > It is how they provide x-connects. Which is fine, but does not work for me. So I won't be using them. Thanks for the info, wasn't aware. Mark. From swmike at swm.pp.se Mon Jun 20 08:36:33 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jun 2016 10:36:33 +0200 (CEST) Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> Message-ID: On Mon, 20 Jun 2016, Thomas Mangin wrote: >> Is this a specific service you purchased, or is this the way they >> deliver x-connects? > > It is how they provide x-connects. That's not a x-connect, that's a transport capacity service. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Mon Jun 20 08:59:45 2016 From: randy at psg.com (Randy Bush) Date: Mon, 20 Jun 2016 10:59:45 +0200 Subject: RPKI implementation In-Reply-To: <5f3d8c5a-1e02-0667-028e-1d151e4da60e@seacom.mu> References: <5f3d8c5a-1e02-0667-028e-1d151e4da60e@seacom.mu> Message-ID: > In single cache scenarios, waiting for some time after the cache has > disappeared is akin to standard BGP session keepalive protocols. > However, several vendors have implemented protocol enhancements to > immediately drop BGP sessions that have failed, rather than wait for the > Hold timer to expire. I see value in that, and perhaps it might make > sense for an RPKI implementation to support the same where it is more > important for the RPKI data to be as current as possible. 6810 A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches. A client SHOULD delete the data from a cache when it has been unable to refresh from that cache for a configurable timer value. The default for that value is twice the polling period for that cache. If a client loses connectivity to a cache it is using, or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache. From A.L.M.Buxey at lboro.ac.uk Mon Jun 20 09:02:14 2016 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 20 Jun 2016 09:02:14 +0000 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> References: <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> <83893B18-0533-4CCA-B68D-29A9D925E82C@exa-networks.co.uk> Message-ID: <20160620090214.GF11241@lboro.ac.uk> Hi, well, you an say one thing - the talk got a lot of conversation going - most of it useful and positive and informational.....isnt that the sign of a good talk? ;-) seriously, this thread has been very active/alive based on the initial trigger of his talk. as for the talk itself....everyone has their views....and people should feel free to provide their opinion when on the soapbox/presentation stage - as long as its within the law (in some doamins being offensive / testing boundaries is part of the territory - eg comedians - but I wouldnt accept that sort of boundary/officensiveness at an IT/networking presentation). theres an old adage about opinions and everyone having one....its a tru-ism for sure - but whilst he might not have had a full picture the resulting conversation on this mailing list has provided much information. Now, just need similar talk on the topic of BGP peering security ;-) alan From mohta at necom830.hpcl.titech.ac.jp Mon Jun 20 09:59:06 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 20 Jun 2016 18:59:06 +0900 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> Glen Kent wrote: > It says that "The IP layer and optical layer are run like two separate > kingdoms," Wellingstein says. "Two separate kings manage the IP and optical > networks. There is barely any resource alignment between them. > Can somebody shed more light on what it means to say that the IP and > optical layers are run as independent kingdoms The problem is not optical at all but caused by poor L3 routing protocols and operational attempts to compensate them at L2. That is, with a L3 routing protocol having 1ms of HELO intervals, all the thing to be done at L2 is to watch BER/FER above some threshold. > and why do ISPs need to over-provision? To act against failures. But, if everything is visible at L3, over-provisioned bandwidth can be used even if there is no failure. Visible at L3 means that parallel point to point links between a pair of routers have distinct pairs of IP addresses and BGP routes should flip only upon failure of all the (or almost all the) links. A remaining, but minor, inefficiency could be mismatch of metric at L1 and L3, that is, ASPATHLEN increases for transit services are not roughly proportional to geographic distances of the transit services. Masataka Ohta From mark.tinka at seacom.mu Mon Jun 20 10:14:27 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 12:14:27 +0200 Subject: IP and Optical domains? In-Reply-To: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> Message-ID: On 20/Jun/16 11:59, Masataka Ohta wrote: > > The problem is not optical at all but caused by poor L3 routing > protocols and operational attempts to compensate them at L2. Ummh, how so. Layer 2 transport is required in any scenario. Dark fibre, for example, would not have any optical kit on it, and can be fired through router-to-router optics. How is this any different from a routing perspective? > > That is, with a L3 routing protocol having 1ms of HELO > intervals, all the thing to be done at L2 is to watch BER/FER > above some threshold. Ummh, BFD works, and this can be used even in grey-light situations where the router has no DWDM visibility into the link state. > > To act against failures. Or to support growth. > > But, if everything is visible at L3, over-provisioned bandwidth > can be used even if there is no failure. We primarily over-provision to support growth. Resiliency comes as secondary benefit. If you are deploying additional bandwidth just for protection, I hope you're my competitor. > > Visible at L3 means that parallel point to point links > between a pair of routers have distinct pairs of IP addresses > and BGP routes should flip only upon failure of all the > (or almost all the) links. iBGP uptime is par for the course. The main advantage of having parallel links across the same path is to increase bandwidth (through load balancing). This is an IGP operation. > > A remaining, but minor, inefficiency could be mismatch of metric > at L1 and L3, that is, ASPATHLEN increases for transit > services are not roughly proportional to geographic distances > of the transit services. If the circuits are on-net, BGP takes the IGP metric into account when trying to get to a target NEXT_HOP. AS_PATH length is an inter-domain concept. One has to manage their eBGP routing using those protocol specific methods to manage latency. This is where a successful operator out-maneuvers their competition, so I don't see it as a protocol or transport limitation, per se. Mark. From swmike at swm.pp.se Mon Jun 20 10:45:54 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jun 2016 12:45:54 +0200 (CEST) Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, 20 Jun 2016, Mark Tinka wrote: > If you are deploying additional bandwidth just for protection, I hope > you're my competitor. So if you have a fiber break, you're not going to have enough overcapacity in your network to remain uncongested until this fiber break is fixed? -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Mon Jun 20 11:13:50 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 13:13:50 +0200 Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> Message-ID: On 20/Jun/16 12:45, Mikael Abrahamsson wrote: > > So if you have a fiber break, you're not going to have enough > overcapacity in your network to remain uncongested until this fiber > break is fixed? That was my point - we will have enough capacity on diverse routes to handle the outage. We deploy additional capacity primarily for growth. The resiliency aspect comes as an added advantage. The diverse paths are already in place. So it's just about adding more bandwidth between the paths in an equal manner. Mark. From ghenry at suretec.co.uk Mon Jun 20 12:25:21 2016 From: ghenry at suretec.co.uk (Gavin Henry) Date: Mon, 20 Jun 2016 13:25:21 +0100 Subject: Sri Lanka options Message-ID: Dear all, One of our partners[1] customers is based in Sri Lanka and we're having issues with latency creeping up to them. We're usually good via our tier 1 transits (Level3 and NTT) at around 180ms, but it's now up to 260ms and causing issues for their tunnels into the kit our partner hosts for them in one of our UK racks in Telehouse East. We've reached out directly to SLT.LK who provide their leased line out there and they adjusted routing into Telia, then into Level3 the last time this happened. We've tried again with no response. So I'm looking for options. They are on AMX-IX, but not sure about being on the RS. That may not improve anything as we'd need to get up there first. I'll contact our tier ones and companies we already have NNI's with but wanted to check if anyone can offer me anything? I know this is a US list, but hoping others have done something like this. Not many ideas from UKNOF apart from a kind email from Rod Beck, which I'm pursuing: ======== There is a surprising amount of connectivity into Sri Lanka. http://www.submarinecablemap.com/#/country/sri-lanka SeaMeWe-5 Bay of Bengal Gateway (BBG) SeaMeWe-3 SeaMeWe-4 Bharat Lanka Cable System Dhiraagu-SLT Submarine Cable Network WARF Submarine Cable ======== We need a guaranteed 5mb/s pipe with < 200ms or something similar. Ideas? Thanks for reading, Gavin. [1] http://www.surevoip.co.uk/partners/partner -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://pool.subkeys.pgp.net or http://www.suretecgroup.com/0x8CFBA8E6.gpg From baldur.norddahl at gmail.com Mon Jun 20 14:07:02 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 20 Jun 2016 16:07:02 +0200 Subject: 1GE L3 aggregation In-Reply-To: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> Message-ID: <5767F886.6020201@gmail.com> On 2016-06-20 08:50, Mark Tinka wrote: > We don't run l3vpn's for infrastructure requirements. We only run them > if a customer wants an l3vpn service. Mark. For a long time we only had one l3vpn customer: our self. It is a good way to separate the control network from the internet. So our config was "vrf default" = IGP and remote access to devices, "vrf internet" = the thing we deliver to customers. There are two reasons we are not doing l3vpn with ip termination at the access edge devices anymore: 1) We have our own GPON switches and this is our original business. We later connected to the ILEC to resell DSL service on their DSLAMs. The ILEC delivers customers as Q-in-Q with one vlan per customer. Unfortunately our access edge devices do not support layer 3 Q-in-Q termination, so we had no other choice than to backhaul the DSL customers in a l2vpn. We then reconfigured our GPON service to emulate the same Q-in-Q one VLAN per customer so we only have one way to do things. 2) IP address scarcity. We used to allocate IP addresses to the edge devices in blocks of 64 (/26 subnet). But this still creates inefficiency where one area has free address space and another area is out. Also it is much work to constantly allocate new address blocks. It is easier with the centralized solution because customers can be pooled together irrespectively of where they actually live using the supervlan feature. Also we have trouble with a bad IPv6 implementation, that made the network unstable when we did IPv6 termination at the access edge. This has since been solved. But it is a reminder that we sometimes end up with different solutions than planed due to bugs and other unforeseen trouble. Regards, Baldur From mark.tinka at seacom.mu Mon Jun 20 17:23:25 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Jun 2016 19:23:25 +0200 Subject: 1GE L3 aggregation In-Reply-To: <5767F886.6020201@gmail.com> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> Message-ID: <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> On 20/Jun/16 16:07, Baldur Norddahl wrote: > > > On 2016-06-20 08:50, Mark Tinka wrote: >> We don't run l3vpn's for infrastructure requirements. We only run >> them if a customer wants an l3vpn service. Mark. > > For a long time we only had one l3vpn customer: our self. It is a good > way to separate the control network from the internet. So our config > was "vrf default" = IGP and remote access to devices, "vrf internet" = > the thing we deliver to customers. Okay. Internally, we use l3vpn's for equipment management as well, but not for other services except customer l3vpn requirements. So we don't do Internet in the VRF, for example. > > There are two reasons we are not doing l3vpn with ip termination at > the access edge devices anymore: > > 1) We have our own GPON switches and this is our original business. We > later connected to the ILEC to resell DSL service on their DSLAMs. The > ILEC delivers customers as Q-in-Q with one vlan per customer. > Unfortunately our access edge devices do not support layer 3 Q-in-Q > termination, so we had no other choice than to backhaul the DSL > customers in a l2vpn. We then reconfigured our GPON service to emulate > the same Q-in-Q one VLAN per customer so we only have one way to do > things. > > 2) IP address scarcity. We used to allocate IP addresses to the edge > devices in blocks of 64 (/26 subnet). But this still creates > inefficiency where one area has free address space and another area is > out. Also it is much work to constantly allocate new address blocks. > It is easier with the centralized solution because customers can be > pooled together irrespectively of where they actually live using the > supervlan feature. So these sound like BNG deployments, which I'm okay to centralize for reasons I mentioned before. The issue we were talking about was general Business or IP Transit customers following the same topology. At any rate, it's your network, so you know best. I just wouldn't centralize things for these types of customers for reason I mentioned before. > > Also we have trouble with a bad IPv6 implementation, that made the > network unstable when we did IPv6 termination at the access edge. This > has since been solved. But it is a reminder that we sometimes end up > with different solutions than planed due to bugs and other unforeseen > trouble. A day in the life of a network operator. But happy to hear your IPv6 deployment has gone well. Mark. From owen at delong.com Mon Jun 20 17:30:16 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2016 10:30:16 -0700 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: > On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: > > On Tue, 14 Jun 2016, Owen DeLong wrote: >> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > >>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 traffic. >> >> Those are by definition poorly designed CPE. > > This (open by default vs closed) has been discussed before, with plenty > of people on either side. > > > /mark I?m unaware of anyone advocating open inbound by default residential CPE. I?m not saying they don?t exist, but I can?t imagine how anyone could possibly defend that position rationally. I?m pretty much in favor of open by default in most things, but for inbound traffic to residential CPE? Even I find that hard to rationalize. Owen From jared at puck.nether.net Mon Jun 20 17:38:07 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 20 Jun 2016 13:38:07 -0400 Subject: IPv6 Ingress traffic by default In-Reply-To: References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: > On Jun 20, 2016, at 1:30 PM, Owen DeLong wrote: > > >> On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: >> >> On Tue, 14 Jun 2016, Owen DeLong wrote: >>> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: >> >>>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 traffic. >>> >>> Those are by definition poorly designed CPE. >> >> This (open by default vs closed) has been discussed before, with plenty >> of people on either side. >> >> >> /mark > > I?m unaware of anyone advocating open inbound by default residential CPE. I?m sure changing the subject line will draw out the purists at heart :) > I?m not saying they don?t exist, but I can?t imagine how anyone could possibly defend that position rationally. I think certain things, eg: SSH would be ?safe-ish? to support ingress, but at the same time, you connect something like a Raspberry PI w/ global V6 and someone is doing honeypot stuff in pool.ntp.org you may get someone doing ssh pi/raspberry with automation before you can even change the passwords. > I?m pretty much in favor of open by default in most things, but for inbound traffic to residential CPE? Even I find that hard to rationalize. What I find frustrating is that my current ISP requires a managed CPE where I can disable the IPv6 firewall so I can access devices at home over IPv6, but there is no way to download/upload the config, and they don?t store it on their side either. This means when a device is swapped, it must be reprogrammed to disable this stuff, meaning I must be on-site or have something phone-home to disable their DHCP server and other elements. I also can?t triage why it keeps rebooting every few days as it doesn?t tell me anything about debug logs, if it uploaded a core file, etc. I?m guessing there is some ?exotic? L2 traffic I have that is hosing it, but haven?t gone so far as to tcpdump the entire network for the possible offending traffic. - Jared From job.witteman at ams-ix.net Sun Jun 19 12:41:24 2016 From: job.witteman at ams-ix.net (Job Witteman) Date: Sun, 19 Jun 2016 14:41:24 +0200 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> Message-ID: > Op 17 jun. 2016, om 21:58 heeft Arnold Nipper het volgende geschreven: > > On 17.06.2016 10:44, Fredrik Korsb?ck wrote: > >> Last year i added 0 new IXPs, upgraded 0 IXPs, but i added over 30 >> new PNI's. >> >> If IXPs wants more of those bits, adjusting prices much more >> aggresively is what can bring this back to their market, instead of >> the datacenter-crossconnect market. >> > > Did you ever think about *who* brought in all the networks you are able > to peer with? And did you ever think *how* successful IXP's brought in these huge amount of peers for you? Let me give you a hint: social engineering, lots of beer, one-on-one options during peering forums around the globe where WE travel far beyond our national borders to make life easy for our prospect customers because, yes, more peers for the same or, even better, lower price is what all of our peers want... > > Seems to be really easy to bash IXPs. Seems to really hard to value what > IXPs have done for the interconnection industry. + 1 > Arnold > -- > Arnold Nipper > email: arnold at nipper.de phone: +49 6224 5593407 2 > mobile: +49 172 2650958 fax: +49 6224 5593407 9 Job Witteman job.witteman at ams-ix.net http://www.ams-ix.net From joe at nethead.com Sun Jun 19 23:03:34 2016 From: joe at nethead.com (Joe Hamelin) Date: Sun, 19 Jun 2016 16:03:34 -0700 Subject: cross connects and their pound of flesh In-Reply-To: <63D33C31-6D05-4C96-A1B7-E9A32D3C2706@yahoo.com> References: <201606191355.OAA17293@sunf10.rd.bbc.co.uk> <1098899885.62095.1466345245411.JavaMail.mhammett@ThunderFuck> <63D33C31-6D05-4C96-A1B7-E9A32D3C2706@yahoo.com> Message-ID: David said:* Gotta watch out for specifying T1 when you want Ethernet- they could just give you 4 wires on pins 1,2,4,5 :)* I think Patrick was thinking back in the days when Ethernet was just two pairs. You could get away with a lot on 10BaseT, I've even used dry telco pairs between buildings when I was in a tight spot. Nice clean T1 pairs through at DSX panel was quite common before we had fancy things like fiber meet-me-rooms. SIX started with midnight cable runs in the drop ceiling. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From jackson.tim at gmail.com Mon Jun 20 20:14:32 2016 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 20 Jun 2016 15:14:32 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> <6476F54E-85DA-49FD-B078-0486048D9F27@exa-networks.co.uk> Message-ID: > > Really? The x-connect is run through active equipment operated by the > data centre? > > Is this a specific service you purchased, or is this the way they > deliver x-connects? I remember fighting with Terremark around 2005 or so on this... Connecting OC-12s through them, they insisted things go through their Lucent Lambda Unite always, it'd turn into 6 hours of finger pointing about timing slips where they would inform me that both sides (AT&T and myself) should time towards them, through attrition we'd always end up with a regular XC. Awesome times. -- Tim From mohta at necom830.hpcl.titech.ac.jp Mon Jun 20 20:38:10 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 21 Jun 2016 05:38:10 +0900 Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> Message-ID: <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> Mark Tinka wrote: > Layer 2 transport is required in any scenario. Yes, of course, as I wrote: > all the thing to be done at L2 is to watch BER/FER > above some threshold. I don't deny L2 exist, though, if L3 protocols were properly designed, L2 protection is not required. > Dark fibre, for example, > would not have any optical kit on it, and can be fired through > router-to-router optics. That's L1, which is also required to exist. > We primarily over-provision to support growth. Resiliency comes as > secondary benefit. > > If you are deploying additional bandwidth just for protection, I hope > you're my competitor. So, you deny the original point of "The result of this is that the networks are heavily underutilized". OK. Masataka Ohta From marka at isc.org Mon Jun 20 20:45:41 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2016 06:45:41 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Mon, 20 Jun 2016 10:30:16 -0700." References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: <20160620204541.4DA144BD30FE@rock.dv.isc.org> In message , Owen DeLong writes: > > > On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: > > > > On Tue, 14 Jun 2016, Owen DeLong wrote: > >> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > > > >>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 > traffic. > >> > >> Those are by definition poorly designed CPE. > > > > This (open by default vs closed) has been discussed before, with plenty > > of people on either side. > > > > > > /mark > > I???m unaware of anyone advocating open inbound by default residential CPE. > > I???m not saying they don???t exist, but I can???t imagine how anyone could > possibly defend that position rationally. > > I???m pretty much in favor of open by default in most things, but for > inbound traffic to residential CPE? Even I find that hard to rationalize. > > Owen > For a lot of homes it actually makes sense. You laptops are safe as they are designed to be connected directly to the Internet. We do this all the time. Similarly phone and tablets are designed to be directly connected to the Internet. I know that lots of us do this all the time. Think about what happens at conferences. There is no firewall there to save you but we all regularly connect our devices to the conference networks. Lots of other stuff is also designed to be directly connected to the Internet. Finding ways to successfully attack a machine from outside is actually hard and has been for many years now. There is lots of FUD being thrown around about IoT. Some machines will be compromised but as a class of devices there is no reason to assume that manufactures haven't learn from what happened to other Internet connected products. The thing you need from all manufactures is a commitment to release fixes (no necessarially feature upgrades) for the devices they ship for the real life the product and for users to upgrade the products. Software doesn't wear out. Bugs just get found and design flaws discovered. The existing warranty policies are designed around products that physically wear out. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chk at pobox.com Mon Jun 20 21:28:00 2016 From: chk at pobox.com (Harald Koch) Date: Mon, 20 Jun 2016 17:28:00 -0400 Subject: Netflix banning HE tunnels In-Reply-To: References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: My son came home from uni and complained that Netflix wasn't working - which turned out to be my HE tunnel. So I blocked a few suggested IPv6 addresses, and everything is now fine. Except that using IPv6 was connecting to some Netflix servers in the US of A, and using IPv4 connects to the local Netflix caching server hosted by my ISP here in Toronto. Much lower RTT and zero packet loss. Amusingly, Netflix's anti-HE stance has actually improved my Netflix experience... -- Harald From mlm at pixelgate.net Mon Jun 20 21:32:56 2016 From: mlm at pixelgate.net (Mark Milhollan) Date: Mon, 20 Jun 2016 14:32:56 -0700 (PDT) Subject: IPv6 Ingress traffic by default In-Reply-To: References: <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: On Mon, 20 Jun 2016, Jared Mauch wrote: >On Jun 20, 2016, at 1:30 PM, Owen DeLong wrote: >>On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: >>>This (open by default vs closed) has been discussed before, with plenty >>>of people on either side. >>I'm unaware of anyone advocating open inbound by default residential CPE. > >I'm sure changing the subject line will draw out the purists at heart :) Hopefully they'll search the archives first. Also discussed on ipv6-ops IIRC. /mark From marka at isc.org Mon Jun 20 22:09:24 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2016 08:09:24 +1000 Subject: IPv6 Ingress traffic by default In-Reply-To: Your message of "Mon, 20 Jun 2016 13:38:07 -0400." References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> Message-ID: <20160620220924.AEA6C4BD3A5C@rock.dv.isc.org> In message , Jared Mauch writes: > > > On Jun 20, 2016, at 1:30 PM, Owen DeLong wrote: > > > > > >> On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: > >> > >> On Tue, 14 Jun 2016, Owen DeLong wrote: > >>> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > >> > >>>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 > traffic. > >>> > >>> Those are by definition poorly designed CPE. > >> > >> This (open by default vs closed) has been discussed before, with > plenty > >> of people on either side. > >> > >> > >> /mark > > > > I???m unaware of anyone advocating open inbound by default residential > CPE. > > I???m sure changing the subject line will draw out the purists at heart :) > > > I???m not saying they don???t exist, but I can???t imagine how anyone could > possibly defend that position rationally. > > I think certain things, eg: SSH would be ???safe-ish??? to support ingress, > but at the same time, you connect something like a Raspberry PI w/ global > V6 and someone is doing honeypot stuff in pool.ntp.org you may get > someone doing ssh pi/raspberry with automation before you can even change > the passwords. And that is the fault of the Raspberry PI. There is zero reason for the Raspberry PI to be open to the world before it has been configured. It could have a initial configuration that is just permit /64 any port 22 deny any any port 22 That is just as safe as the CPE firewall would have been and doesn't require a external firewall. It would be nice if that could have been permit /48 any port 22 but a group of ISP's thought they knew better than the IETF and decided that they would not listen to the advice that every site gets a /48 so now there is no sensible site wide default prefix. > > I???m pretty much in favor of open by default in most things, but for > > inbound traffic to residential CPE? Even I find that hard to rationalize. > > What I find frustrating is that my current ISP requires a managed CPE > where I can disable the IPv6 firewall so I can access devices at home > over IPv6, but there is no way to download/upload the config, and they > don???t store it on their side either. This means when a device is > swapped, it must be reprogrammed to disable this stuff, meaning I must be > on-site or have something phone-home to disable their DHCP server and > other elements. > > I also can???t triage why it keeps rebooting every few days as it doesn???t > tell me anything about debug logs, if it uploaded a core file, etc. > > I???m guessing there is some ???exotic??? L2 traffic I have that is hosing it, > but haven???t gone so far as to tcpdump the entire network for the possible > offending traffic. > > - Jared -- 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 Mon Jun 20 23:03:54 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2016 16:03:54 -0700 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <1386CA32-47B7-4D7D-B78F-AE208A5C9DD4@virtualized.org> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> <1386CA32-47B7-4D7D-B78F-AE208A5C9DD4@virtualized.org> Message-ID: <9186D73F-04C9-4C00-B2E7-FD35245233AA@delong.com> > On Jun 17, 2016, at 09:03 , David Conrad wrote: > > Owen, > > On Jun 17, 2016, at 1:20 AM, Owen DeLong wrote: >>> On Jun 16, 2016, at 06:03 , Ca By wrote: >>> >>> Perhaps it is me and my sensibilities, perhaps it is my miser corp culture, but i could not even dream of asking to go to Jamaica (arin area) for the last ARIN meeting. >> >> You are entitled to your opinion. >> >> If ARIN didn?t exist, how would you go about guaranteeing unique registered GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa? > > ICANN operates in-addr.arpa and ip6.arpa. Technically you are right, sort of. ICANN takes the data supplied by the RIRs and compiles it into zone files which are then distributed to servers. AIUI, most of the servers are hosted and maintained by the RIRs. Most if not all of the zone file information is supplied to ICANN by the RIRs. I stand by my statement to the extent that it is close enough for the purposes for which it was made. Without the RIR, ICANN?s idea of what should go into ip6.arpa and in-addr.arp would get pretty stale pretty fast. Of course, that wouldn?t matter because AIUI, without the servers being supplied, hosted, maintained by the RIRs, it would also be fairly invisible as well. But keep those ICANN delusions of grandeur coming. Owen From owen at delong.com Mon Jun 20 23:28:12 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2016 16:28:12 -0700 Subject: Netflix banning HE tunnels In-Reply-To: <20160620204541.4DA144BD30FE@rock.dv.isc.org> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620204541.4DA144BD30FE@rock.dv.isc.org> Message-ID: <28657BED-E262-452D-B218-7B39B17F36FE@delong.com> > On Jun 20, 2016, at 13:45 , Mark Andrews wrote: > > > In message , Owen DeLong writes: >> >>> On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: >>> >>> On Tue, 14 Jun 2016, Owen DeLong wrote: >>>> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: >>> >>>>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 >> traffic. >>>> >>>> Those are by definition poorly designed CPE. >>> >>> This (open by default vs closed) has been discussed before, with plenty >>> of people on either side. >>> >>> >>> /mark >> >> I?m unaware of anyone advocating open inbound by default residential CPE. >> >> I?m not saying they don?t exist, but I can?t imagine how anyone could >> possibly defend that position rationally. >> >> I?m pretty much in favor of open by default in most things, but for >> inbound traffic to residential CPE? Even I find that hard to rationalize. >> >> Owen >> > > For a lot of homes it actually makes sense. You laptops are safe > as they are designed to be connected directly to the Internet. We > do this all the time. Similarly phone and tablets are designed to > be directly connected to the Internet. I know that lots of us do > this all the time. Think about what happens at conferences. There > is no firewall there to save you but we all regularly connect our > devices to the conference networks. > > Lots of other stuff is also designed to be directly connected to > the Internet. > > Finding ways to successfully attack a machine from outside is > actually hard and has been for many years now. > > There is lots of FUD being thrown around about IoT. Some machines > will be compromised but as a class of devices there is no reason > to assume that manufactures haven't learn from what happened to > other Internet connected products. I dare you to purchase a Yamaha amplifier with an ethernet interface, connect it to a good set of speakers within range to make it loud in your bedroom and provide me with your timezone and the IP address of the Yamaha in its default configuration. You can call it FUD all you want, but the average ethernet-connected printer is quite vulnerable. So are many of the smart media devices floating around out there. Same with many of the network-connected thermostats I have experimented with. For anyone who knows enough to understand the risk they are or are not taking by opening things up, it?s trivial to program in the desired exceptions or turn off the default deny. For everyone else, we should protect the internet from letting them shoot themselves in the head in such a way that we get hit with the back splatter. > The thing you need from all manufactures is a commitment to release > fixes (no necessarially feature upgrades) for the devices they ship > for the real life the product and for users to upgrade the products. Certainly that helps, but it?s a fantasy in too many cases to act like it is a foregone conclusion or fait accompli. > Software doesn't wear out. Bugs just get found and design flaws > discovered. The existing warranty policies are designed around > products that physically wear out. Sure, but until that is actually changed, a default permit policy on a home gateway remains one of the worst ideas I can imagine. Owen From owen at delong.com Mon Jun 20 23:33:46 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2016 16:33:46 -0700 Subject: IPv6 Ingress traffic by default In-Reply-To: <20160620220924.AEA6C4BD3A5C@rock.dv.isc.org> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620220924.AEA6C4BD3A5C@rock.dv.isc.org> Message-ID: > > And that is the fault of the Raspberry PI. There is zero reason for > the Raspberry PI to be open to the world before it has been configured. > It could have a initial configuration that is just > > permit /64 any port 22 > deny any any port 22 It?s very hard to configure a Raspberry PI using Cisco?s filter language. I don?t know of any case where this will work. Owen From marka at isc.org Mon Jun 20 23:56:13 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2016 09:56:13 +1000 Subject: Netflix banning HE tunnels In-Reply-To: Your message of "Mon, 20 Jun 2016 16:28:12 -0700." <28657BED-E262-452D-B218-7B39B17F36FE@delong.com> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620204541.4DA144BD30FE@rock.dv.isc.org> <28657BED-E262-452D-B218-7B39B17F36FE@delong.com> Message-ID: <20160620235613.118BA4BD56E2@rock.dv.isc.org> In message <28657BED-E262-452D-B218-7B39B17F36FE at delong.com>, Owen DeLong writes: > > > On Jun 20, 2016, at 13:45 , Mark Andrews wrote: > > > > > > In message , Owen DeLong writes: > >> > >>> On Jun 17, 2016, at 10:10 , Mark Milhollan wrote: > >>> > >>> On Tue, 14 Jun 2016, Owen DeLong wrote: > >>>> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > >>> > >>>>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 > >> traffic. > >>>> > >>>> Those are by definition poorly designed CPE. > >>> > >>> This (open by default vs closed) has been discussed before, with > >>> plenty of people on either side. > >>> > >>> > >>> /mark > >> > >> I???m unaware of anyone advocating open inbound by default residential > >> CPE. > >> > >> I???m not saying they don???t exist, but I can???t imagine how anyone could > >> possibly defend that position rationally. > >> > >> I???m pretty much in favor of open by default in most things, but for > >> inbound traffic to residential CPE? Even I find that hard to > >> rationalize. > >> > >> Owen > >> > > > > For a lot of homes it actually makes sense. You laptops are safe > > as they are designed to be connected directly to the Internet. We > > do this all the time. Similarly phone and tablets are designed to > > be directly connected to the Internet. I know that lots of us do > > this all the time. Think about what happens at conferences. There > > is no firewall there to save you but we all regularly connect our > > devices to the conference networks. > > > > Lots of other stuff is also designed to be directly connected to > > the Internet. > > > > Finding ways to successfully attack a machine from outside is > > actually hard and has been for many years now. > > > > There is lots of FUD being thrown around about IoT. Some machines > > will be compromised but as a class of devices there is no reason > > to assume that manufactures haven't learn from what happened to > > other Internet connected products. > > I dare you to purchase a Yamaha amplifier with an ethernet interface, > connect it to a good set of speakers within range to make it loud in > your bedroom and provide me with your timezone and the IP address > of the Yamaha in its default configuration. I don't want a Yamaha amplifier. If you have one and if it is not FIT FOR PURPOSE sent it back and demand your money back. You should be able to connect any equipement to a network and not have it be owned. > You can call it FUD all you want, but the average ethernet-connected > printer is quite vulnerable. So are many of the smart media devices > floating around out there. The internet printers I have contain access controls. They don't need a CPE firewall. > Same with many of the network-connected thermostats I have experimented > with. Well send them back and demand your money back saying why you are sending the back. > For anyone who knows enough to understand the risk they are or are not > taking by opening things up, it???s trivial to program in the desired > exceptions or turn off the default deny. > > For everyone else, we should protect the internet from letting them > shoot themselves in the head in such a way that we get hit with the > back splatter. And that comes with a significant future cost. Every piece of software that wants to accept connections from outside now needs to be able to not only update the devices configuration but also the firewalls configuration. > > The thing you need from all manufactures is a commitment to release > > fixes (no necessarially feature upgrades) for the devices they ship > > for the real life the product and for users to upgrade the products. > > Certainly that helps, but it???s a fantasy in too many cases to act like > it is a foregone conclusion or fait accompli. Actually if we ship CPE devices with firewalls off, IoT manufactures will tighten the security of their devices. It will lead to better products overall. > > Software doesn't wear out. Bugs just get found and design flaws > > discovered. The existing warranty policies are designed around > > products that physically wear out. > > Sure, but until that is actually changed, a default permit policy on a > home gateway remains one of the worst ideas I can imagine. Actually it is one of the best things we can do. Yes, there will be a short term cost but it comes with benefits of a less complicated network where everything works. Firewalls should be filtering out spoofed traffic (both ways) and that is about all they should be doing. > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Jun 21 00:04:07 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2016 10:04:07 +1000 Subject: IPv6 Ingress traffic by default In-Reply-To: Your message of "Mon, 20 Jun 2016 16:33:46 -0700." References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620220924.AEA6C4BD3A5C@rock.dv.isc.org> Message-ID: <20160621000407.D9AE24BD57AE@rock.dv.isc.org> In message , Owen DeLong writes: > > > > And that is the fault of the Raspberry PI. There is zero reason for > > the Raspberry PI to be open to the world before it has been configured. > > It could have a initial configuration that is just > > > > permit /64 any port 22 > > deny any any port 22 > > It???s very hard to configure a Raspberry PI using Cisco???s filter language. > > I don???t know of any case where this will work. > > Owen So you are going to argue about firewall configuration language rather than the concept which was viable in host firewalls I've used for over a decade. You can do the same thing with all firewalls even if it requires a piece of software to listen to interfaces being configured are rewriting the firewalls as they are being brought up. I develope software that does just this at the application level. It is not rocket science. Just listen to the routing interface and adjust the acls as interfaces come and go. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jason at thebaughers.com Tue Jun 21 00:35:19 2016 From: jason at thebaughers.com (Jason Baugher) Date: Mon, 20 Jun 2016 19:35:19 -0500 Subject: Netflix banning HE tunnels In-Reply-To: <20160620235613.118BA4BD56E2@rock.dv.isc.org> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620204541.4DA144BD30FE@rock.dv.isc.org> <28657BED-E262-452D-B218-7B39B17F36FE@delong.com> <20160620235613.118BA4BD56E2@rock.dv.isc.org> Message-ID: Wait, is this April Fools? The way to make device manufacturers tighten up their security holes is to stick them on the public Internet? That's a hoot. On Jun 20, 2016 6:57 PM, "Mark Andrews" wrote: > > In message <28657BED-E262-452D-B218-7B39B17F36FE at delong.com>, Owen DeLong > writes: > > > > > On Jun 20, 2016, at 13:45 , Mark Andrews wrote: > > > > > > > > > In message , Owen > DeLong writes: > > >> > > >>> On Jun 17, 2016, at 10:10 , Mark Milhollan > wrote: > > >>> > > >>> On Tue, 14 Jun 2016, Owen DeLong wrote: > > >>>> On Jun 14, 2016, at 11:57 , Ricky Beam wrote: > > >>> > > >>>>> I've seen many "IPv6 Capable" CPEs that apply ZERO security to IPv6 > > >> traffic. > > >>>> > > >>>> Those are by definition poorly designed CPE. > > >>> > > >>> This (open by default vs closed) has been discussed before, with > > >>> plenty of people on either side. > > >>> > > >>> > > >>> /mark > > >> > > >> I?m unaware of anyone advocating open inbound by default residential > > >> CPE. > > >> > > >> I?m not saying they don?t exist, but I can?t imagine how anyone could > > >> possibly defend that position rationally. > > >> > > >> I?m pretty much in favor of open by default in most things, but for > > >> inbound traffic to residential CPE? Even I find that hard to > > >> rationalize. > > >> > > >> Owen > > >> > > > > > > For a lot of homes it actually makes sense. You laptops are safe > > > as they are designed to be connected directly to the Internet. We > > > do this all the time. Similarly phone and tablets are designed to > > > be directly connected to the Internet. I know that lots of us do > > > this all the time. Think about what happens at conferences. There > > > is no firewall there to save you but we all regularly connect our > > > devices to the conference networks. > > > > > > Lots of other stuff is also designed to be directly connected to > > > the Internet. > > > > > > Finding ways to successfully attack a machine from outside is > > > actually hard and has been for many years now. > > > > > > There is lots of FUD being thrown around about IoT. Some machines > > > will be compromised but as a class of devices there is no reason > > > to assume that manufactures haven't learn from what happened to > > > other Internet connected products. > > > > I dare you to purchase a Yamaha amplifier with an ethernet interface, > > connect it to a good set of speakers within range to make it loud in > > your bedroom and provide me with your timezone and the IP address > > of the Yamaha in its default configuration. > > I don't want a Yamaha amplifier. If you have one and if it is not > FIT FOR PURPOSE sent it back and demand your money back. You should > be able to connect any equipement to a network and not have it be > owned. > > > You can call it FUD all you want, but the average ethernet-connected > > printer is quite vulnerable. So are many of the smart media devices > > floating around out there. > > The internet printers I have contain access controls. They don't need > a CPE firewall. > > > Same with many of the network-connected thermostats I have experimented > > with. > > Well send them back and demand your money back saying why you are sending > the back. > > > For anyone who knows enough to understand the risk they are or are not > > taking by opening things up, it?s trivial to program in the desired > > exceptions or turn off the default deny. > > > > For everyone else, we should protect the internet from letting them > > shoot themselves in the head in such a way that we get hit with the > > back splatter. > > And that comes with a significant future cost. Every piece of > software that wants to accept connections from outside now needs > to be able to not only update the devices configuration but also > the firewalls configuration. > > > > The thing you need from all manufactures is a commitment to release > > > fixes (no necessarially feature upgrades) for the devices they ship > > > for the real life the product and for users to upgrade the products. > > > > Certainly that helps, but it?s a fantasy in too many cases to act like > > it is a foregone conclusion or fait accompli. > > Actually if we ship CPE devices with firewalls off, IoT manufactures > will tighten the security of their devices. It will lead to better > products overall. > > > > Software doesn't wear out. Bugs just get found and design flaws > > > discovered. The existing warranty policies are designed around > > > products that physically wear out. > > > > Sure, but until that is actually changed, a default permit policy on a > > home gateway remains one of the worst ideas I can imagine. > > Actually it is one of the best things we can do. Yes, there will > be a short term cost but it comes with benefits of a less complicated > network where everything works. > > Firewalls should be filtering out spoofed traffic (both ways) and > that is about all they should be doing. > > > Owen > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From D.Lasher at f5.com Tue Jun 21 00:45:49 2016 From: D.Lasher at f5.com (Donn Lasher) Date: Tue, 21 Jun 2016 00:45:49 +0000 Subject: Netflix banning HE tunnels In-Reply-To: <20160620204541.4DA144BD30FE@rock.dv.isc.org> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620204541.4DA144BD30FE@rock.dv.isc.org> Message-ID: <121B6FC1-3AFF-4E6B-88CE-886AD71CD1B8@f5.com> On 6/20/16, 1:45 PM, "NANOG on behalf of Mark Andrews" wrote: >For a lot of homes it actually makes sense. You laptops are safe >as they are designed to be connected directly to the Internet. We >do this all the time. Similarly phone and tablets are designed to >be directly connected to the Internet. I know that lots of us do >this all the time. Think about what happens at conferences. There >is no firewall there to save you but we all regularly connect our >devices to the conference networks. > >Lots of other stuff is also designed to be directly connected to >the Internet. I?m sorry, but this just isn?t the reality of consumer devices. Expecting your off-the-shelf computer, video player, tv, fridge, etc, to be safe on public IP addresses is.. Unwise at best. Search any publicly available security list for dozens of known vulnerabilities in those devices, to say nothing of the private exploit databases. To place them there, have them be owned, crash, or better yet, stream your midnight-milk-and-cookies-run-in-your-superman-undies to the public internet, and then expect the vendors to be responsible? is not a realistic expectation. From drc at virtualized.org Tue Jun 21 03:37:05 2016 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Jun 2016 22:37:05 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: <9186D73F-04C9-4C00-B2E7-FD35245233AA@delong.com> References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> <1386CA32-47B7-4D7D-B78F-AE208A5C9DD4@virtualized.org> <9186D73F-04C9-4C00-B2E7-FD35245233AA@delong.com> Message-ID: Owen > On Jun 20, 2016, at 6:03 PM, Owen DeLong wrote: >>> If ARIN didn?t exist, how would you go about guaranteeing unique registered GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa? >> ICANN operates in-addr.arpa and ip6.arpa. > ICANN takes the data supplied by the RIRs and compiles it into zone files which are then distributed to servers. Among others, yes (hint: not all the IPv4 and IPv6 address space is managed by the RIRs). > AIUI, most of the servers are hosted and maintained by the RIRs. Most if not all of the zone file information is supplied to ICANN by the RIRs. Perhaps you should review how the DNS works. Hint: who operates the master for in-addr.arpa and ip6.arpa and what is the role of secondaries? > I stand by my statement to the extent that it is close enough for the purposes for which it was made. Your statement posited the nonexistence of ARIN. ARIN is a secondary for in-addr.arpa and ip6.arpa (like the other RIRs) and maintains a registry for the address blocks allocated to them by ICANN as the IANA Numbering Function operator. If ARIN did not exist, then the reverse delegations for which ARIN is authoritative could easily be managed by the other RIRs, the entities to which ARIN currently delegates, or the myriad of other DNS registries. This really isn't rocket science. > Without the RIR, ICANN?s idea of what should go into ip6.arpa and in-addr.arp would get pretty stale pretty fast. Or not, as long as the entities to which ARIN delegated were aware of the registry they should update. This really isn't rocket science. > Of course, that wouldn?t matter because AIUI, without the servers being supplied, hosted, maintained by the RIRs, it would also be fairly invisible as well. Again, perhaps you should review how the DNS works. Hint: where do referrals to the sub-trees of .ARPA come from? > But keep those ICANN delusions of grandeur coming. You asked a question. I answered that question accurately. I am unsure why that would cause you to assert delusions of grandeur. Regards, -drc (speaking only for myself) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Tue Jun 21 05:01:06 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2016 22:01:06 -0700 Subject: Netflix banning HE tunnels In-Reply-To: <20160620235613.118BA4BD56E2@rock.dv.isc.org> References: <1e4501d1c1c0$60376620$20a63260$@tndh.net> <77A95604-8A0D-43FA-96AA-590B5E5B140B@newslink.com> <868179CF-0DE5-4071-8662-D3CE47326F94@steffann.nl> <20160609231737.E3C074B129C6@rock.dv.isc.org> <3D30DC0D-0279-46C0-97FF-8237FB613B88@delong.com> <3FA69398-0647-47A2-8644-84C9B914F70B@delong.com> <20160620204541.4DA144BD30FE@rock.dv.isc.org> <28657BED-E262-452D-B218-7B39B17F36FE@delong.com> <20160620235613.118BA4BD56E2@rock.dv.isc.org> Message-ID: <76D50E88-909C-4FB2-86D9-F39E28B1C3CB@delong.com> >> >> I dare you to purchase a Yamaha amplifier with an ethernet interface, >> connect it to a good set of speakers within range to make it loud in >> your bedroom and provide me with your timezone and the IP address >> of the Yamaha in its default configuration. > > I don't want a Yamaha amplifier. If you have one and if it is not > FIT FOR PURPOSE sent it back and demand your money back. You should > be able to connect any equipement to a network and not have it be > owned. It?s quite FIT FOR PURPOSE. It has some things I don?t like (such as the inability to leave it unattended on the internet without something protecting it in front). It doesn?t get owned so much as it can be controlled by anyone with access. It won?t take a firmware update or something like that from a remote person, but it has no authentications on it?s web control interface because it was built with the stupid assumption that all the world is NAT. Unfortunately, it is just one example of a vast number of appliances which are built that way and are present in a variety of homes with less sophisticated users than you or I. Do you _REALLY_ think that the average consumer asks the 1d10t at the local Best Buy ?So, I know it sounds good and all, but what kind of firewall configuration capabilities does this amplifier have?? If you want to build routers for your idillic fantasy world, that?s fine. I?m talking about equipment that gets deployed in the real world as it exists today and likely will exist for several years hence. Do I agree with you about how things should be? Of course I do, but it?s nearly the definition of insanity to act as if that is how things are to the point that you allow actual harm to occur simply because so little reality matches your fantasy. > >> You can call it FUD all you want, but the average ethernet-connected >> printer is quite vulnerable. So are many of the smart media devices >> floating around out there. > > The internet printers I have contain access controls. They don't need > a CPE firewall. Good for you. You bought the correct 1.5% of the products that are out there and you payed way more than most people do for a printer in their homes. >> Same with many of the network-connected thermostats I have experimented >> with. > > Well send them back and demand your money back saying why you are sending > the back. In some cases, I did. In other cases, it wasn?t worth the effort. However, what I do has nothing to do with what happens in thousands or millions of other homes where the user wouldn?t even know how to check whether or not their thermostat has that capability and frankly doesn?t likely even know enough to know that they should check it. Step back from your fantasy of how the world should be (which I agree would be a fine world if we can get there) and face the fact that some of us have to deal with the world as it is, not as you would like it to be. >> For anyone who knows enough to understand the risk they are or are not >> taking by opening things up, it?s trivial to program in the desired >> exceptions or turn off the default deny. >> >> For everyone else, we should protect the internet from letting them >> shoot themselves in the head in such a way that we get hit with the >> back splatter. > > And that comes with a significant future cost. Every piece of > software that wants to accept connections from outside now needs > to be able to not only update the devices configuration but also > the firewalls configuration. Nope? Every user who wants to permit those accesses needs to know how to update the devices configuration at least once. If you know enough to care, you should know enough to turn off the protections. I?m just saying they should be on by default. I find it very hard to justify that the equivalent of flipping a light switch once is truly a ?significant future cost?. > >>> The thing you need from all manufactures is a commitment to release >>> fixes (no necessarially feature upgrades) for the devices they ship >>> for the real life the product and for users to upgrade the products. >> >> Certainly that helps, but it?s a fantasy in too many cases to act like >> it is a foregone conclusion or fait accompli. > > Actually if we ship CPE devices with firewalls off, IoT manufactures > will tighten the security of their devices. It will lead to better > products overall. Right? Because that strategy has clearly worked so well thus far. Please return to earth and re-evaluate your theory. >>> Software doesn't wear out. Bugs just get found and design flaws >>> discovered. The existing warranty policies are designed around >>> products that physically wear out. >> >> Sure, but until that is actually changed, a default permit policy on a >> home gateway remains one of the worst ideas I can imagine. > > Actually it is one of the best things we can do. Yes, there will > be a short term cost but it comes with benefits of a less complicated > network where everything works. No, it doesn?t. Your vision of how people should behave bears no resemblance whatsoever to how they will behave. Your vision of what device manufacturers will do in this environment is likewise delusional. > Firewalls should be filtering out spoofed traffic (both ways) and > that is about all they should be doing. In the words of Randy Bush (who I can?t believe I?m quoting here), I encourage you to try that on any network where you are responsible for the network security, but cannot control the choice of devices that users place on said network. Owen From mark.tinka at seacom.mu Tue Jun 21 06:27:13 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 21 Jun 2016 08:27:13 +0200 Subject: IP and Optical domains? In-Reply-To: <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> Message-ID: <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> On 20/Jun/16 22:38, Masataka Ohta wrote: > > > I don't deny L2 exist, though, if L3 protocols were properly > designed, L2 protection is not required. I'd like to hear your proposals on how Layer 3 protocols can be better designed to manage transport characteristics. > > > That's L1, which is also required to exist. It's Layer 1 and Layer 2. Ethernet is running over those optics, albeit with no "traditional" optical equipment in between. > > > So, you deny the original point of "The result of this is that the > networks are heavily underutilized". OK. Under- or over-utilization means different things to different people. We upgrade at 50% utilization. Others do it at 70% utilization. Others do it at 100% utilization. Heck, I know some that do it at 40% utilization. Since not all operations are the same, I can't tell another person what I think under- or over-utilization is. Mark. From jcurran at arin.net Tue Jun 21 11:59:20 2016 From: jcurran at arin.net (John Curran) Date: Tue, 21 Jun 2016 11:59:20 +0000 Subject: ARIN meeting schedule (was: Re: NANOG67 - Tipping point of community and sponsor bashing?) In-Reply-To: References: <8FFC92A9-7959-4FDC-B241-A487FACADC58@puck.nether.net> <998049971.57757.1465994239988.JavaMail.mhammett@ThunderFuck> <79b3c4e4-15d8-0441-6c4b-f59f78d3c429@rollernet.us> <96CAACEF-0A8B-433C-BE3B-45988F90CF29@pch.net> <93ED670D-AAAC-4084-ABEC-779D1764C6AF@delong.com> <22FAF9B1-0D39-47E3-8E45-60EAD0AC48B3@delong.com> <1386CA32-47B7-4D7D-B78F-AE208A5C9DD4@virtualized.org> <9186D73F-04C9-4C00-B2E7-FD35245233AA@delong.com> Message-ID: <97647DA2-B9A9-46D8-AFFE-A96387FB3A77@arin.net> On Jun 20, 2016, at 11:37 PM, David Conrad wrote: > ... > Among others, yes (hint: not all the IPv4 and IPv6 address space is managed by the RIRs). David is quite correct - IPv4 has significant portions which are administered under specification of the IETF (and this is certainly the case of the IPv6 address space, the vast majority of which is administered under the stewardship of the IETF.) > ... > Your statement posited the nonexistence of ARIN. ARIN is a secondary for in-addr.arpa and ip6.arpa (like the other RIRs) and maintains a registry for the address blocks allocated to them by ICANN as the IANA Numbering Function operator. If ARIN did not exist, then the reverse delegations for which ARIN is authoritative could easily be managed by the other RIRs, the entities to which ARIN currently delegates, or the myriad of other DNS registries. This really isn't rocket science. Also correct - the RIRs have discussed recovery scenarios necessary should one of the RIRs experience an major operational event. As David notes, this is not rocket science, although it does require a modicum of preparation, both in terms of planning and funding; e.g. However, the main thread of this discussion originated in response discussions of the meeting expenses of associations in general, including some surprise that ARIN met this spring in Jamaica. Everyone?s free to have their own opinion on that, but just for information?s sake, I?d point out that ARIN has a straightforward meeting schedule - we meet twice per year, once jointly with NANOG in the fall, and once independently in the spring. The fall meeting is at locations set by NANOG (and predominantly in the US) so we try to alternate the spring meetings between our other two sectors - Canada and Caribbean. We have more than 25 countries in ARIN?s region, and getting to the Caribbean once every other year is important for outreach to folks in that area - for example, the attendance at the Jamaica meeting showed very strong Caribbean participation (48 attendees from the Caribbean out of 125 total) compared the typical participant distribution at US and Canada-based meetings. Anyone who has suggestions or concerns about ARIN?s meeting schedule should reach out with specifics to myself or other folks on the ARIN Board. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From baptiste at bitsofnetworks.org Tue Jun 21 12:14:54 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Tue, 21 Jun 2016 14:14:54 +0200 Subject: Measuring the quality of Internet access In-Reply-To: <575F0573.1050406@netassist.ua> References: <575F0573.1050406@netassist.ua> Message-ID: <20160621121454.GA32048@lud.polynome.dn42> Hi, On Mon, Jun 13, 2016 at 10:11:47PM +0300, Max Tulyev wrote: > Hi All, > > I know there are many people from many countries. > > Do you know something about mandatory measurements of Internet access > quality from country telecom regulators? If yes, could you please share > that information with me? ARCEP, the telecom regulatory body from France, publishes regular reports on the quality of Internet access: http://arcep.fr/index.php?id=8571&L=1&tx_gsactualite_pi1[uid]=1847 The methodology is described in the PDF (unfortunately, only available in French, it seems). See also: http://arcep.fr/index.php?id=11894&L=1 > I found ETSI EG 202 057-4 standard > (http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf), > but in fact it is about measurements inside operator's network, not > Internet access itself. > > Is it possible in general to measure the quality of Internet access? And > if yes - how? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From sethm at rollernet.us Tue Jun 21 16:52:48 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 21 Jun 2016 09:52:48 -0700 Subject: Recommendations, Colo Reno, Albuquerque, Phoenix, Las Vegas In-Reply-To: <540685DD.703@satchell.net> References: <1409700944.88911.YahooMailNeo@web181601.mail.ne1.yahoo.com> <540685DD.703@satchell.net> Message-ID: On 9/2/14 20:07, Stephen Satchell wrote: > On 09/02/2014 04:35 PM, Eric A Louie wrote: >> Does anyone have recommendations for Colocation space in any of those 4 cities? >> >> thanks >> Eric >> > > Co-location in Reno is a shrinking proposition. The only place I know > about, and have toured, is: > > Roller Networks > Seth Mattinen, CTO > 3545 Airway Drive, Suite 114 > Reno NV 89511 > (775)284-0282 Ext 101 > rollernetwork.com > I hate to resurrect a years old thread but for the archives Rollernet's correct phone number is: 775-284-0383 I'm just that behind on my NANOG (9k down to 2.4k this morning). Not really reading all 9k, more like liberal use of the "n" key. ~Seth From cboyd at gizmopartners.com Tue Jun 21 18:25:07 2016 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 21 Jun 2016 13:25:07 -0500 Subject: Google Geolocation issue Message-ID: <1466533507.2680.14.camel@beagle> Dear list readers, please forgive the noise, but if there's anyone here from Google who can fix a geolocation issue I'd appreciate a reply. 208.81.245.226 is not in the UAE, it's in Austin, Texas. Yes, I have filled out the form to request a fix, but the AI or whatever that's supposed to fix it has not, and we're well into 3 months after the first report. Thanks, --Chris From mattlists at rivervalleyinternet.net Tue Jun 21 21:06:52 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 21 Jun 2016 17:06:52 -0400 Subject: Timeouts Loading Major Websites Message-ID: <5769AC6C.7060305@rivervalleyinternet.net> Is anyone else seeing sporadic timeouts trying to load major websites like Google or Facebook or SpeedTest.net? I'm seeing it come and go on both Frontier and Level3 on the east coast. From josh at imaginenetworksllc.com Tue Jun 21 21:09:49 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 21 Jun 2016 17:09:49 -0400 Subject: Timeouts Loading Major Websites In-Reply-To: <5769AC6C.7060305@rivervalleyinternet.net> References: <5769AC6C.7060305@rivervalleyinternet.net> Message-ID: No issues on Frontier from Troy OH Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Jun 21, 2016 at 5:06 PM, Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Is anyone else seeing sporadic timeouts trying to load major websites like > Google or Facebook or SpeedTest.net? I'm seeing it come and go on both > Frontier and Level3 on the east coast. > From dovid at telecurve.com Tue Jun 21 21:14:22 2016 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 21 Jun 2016 21:14:22 +0000 Subject: Timeouts Loading Major Websites In-Reply-To: References: <5769AC6C.7060305@rivervalleyinternet.net> Message-ID: <832717460-1466543662-cardhu_decombobulator_blackberry.rim.net-62483039-@b12.c1.bise6.blackberry> Major storms across the east coast. Regards, Dovid -----Original Message----- From: Josh Luthman Sender: "NANOG" Date: Tue, 21 Jun 2016 17:09:49 To: Matt Hoppes Cc: North American Network Operators' Group Subject: Re: Timeouts Loading Major Websites No issues on Frontier from Troy OH Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Jun 21, 2016 at 5:06 PM, Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Is anyone else seeing sporadic timeouts trying to load major websites like > Google or Facebook or SpeedTest.net? I'm seeing it come and go on both > Frontier and Level3 on the east coast. > From morrowc.lists at gmail.com Tue Jun 21 22:13:10 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Jun 2016 18:13:10 -0400 Subject: Timeouts Loading Major Websites In-Reply-To: <832717460-1466543662-cardhu_decombobulator_blackberry.rim.net-62483039-@b12.c1.bise6.blackberry> References: <5769AC6C.7060305@rivervalleyinternet.net> <832717460-1466543662-cardhu_decombobulator_blackberry.rim.net-62483039-@b12.c1.bise6.blackberry> Message-ID: "the internet is on fire" not as helpful a troublereport as one might want. please provide at least (so everyone else can verify/help/troubleshoot): 1) from location X 2) site Y with protocol Z (which resolves to a.b.c.d currently) 3) traceroute to siteY (address a.b.c.d) otherwise... "sure major sites are slow, I also use a 300baud coupler modem these days though...." On Tue, Jun 21, 2016 at 5:14 PM, Dovid Bender wrote: > Major storms across the east coast. > > Regards, > > Dovid > > -----Original Message----- > From: Josh Luthman > Sender: "NANOG" Date: Tue, 21 Jun 2016 17:09:49 > To: Matt Hoppes > Cc: North American Network Operators' Group > Subject: Re: Timeouts Loading Major Websites > > No issues on Frontier from Troy OH > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Tue, Jun 21, 2016 at 5:06 PM, Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > > > Is anyone else seeing sporadic timeouts trying to load major websites > like > > Google or Facebook or SpeedTest.net? I'm seeing it come and go on both > > Frontier and Level3 on the east coast. > > > From job at instituut.net Tue Jun 21 22:21:24 2016 From: job at instituut.net (Job Snijders) Date: Wed, 22 Jun 2016 00:21:24 +0200 Subject: Timeouts Loading Major Websites In-Reply-To: References: <5769AC6C.7060305@rivervalleyinternet.net> <832717460-1466543662-cardhu_decombobulator_blackberry.rim.net-62483039-@b12.c1.bise6.blackberry> Message-ID: <20160621222124.GJ71742@Vurt.cisco> On Tue, Jun 21, 2016 at 06:13:10PM -0400, Christopher Morrow wrote: > "the internet is on fire" > > not as helpful a troublereport as one might want. > > please provide at least (so everyone else can verify/help/troubleshoot): > 1) from location X > 2) site Y with protocol Z (which resolves to a.b.c.d currently) > 3) traceroute to siteY (address a.b.c.d) In addition to providing useful debug info, there are some good places to check: http://sqa.ring.nlnog.net/ (an attempt at outage correlation based on NLNOG RING data) https://puck.nether.net/pipermail/outages/ (people (self-)reporting outages) http://isitdownorjust.me/ http://www.downforeveryoneorjustme.com/ (self-test websites from various vantage points) > otherwise... "sure major sites are slow, I also use a 300baud coupler > modem these days though...." How did you know about the coupler? :) - Job From shannon at more.net Tue Jun 21 14:37:09 2016 From: shannon at more.net (Spurling, Shannon) Date: Tue, 21 Jun 2016 14:37:09 +0000 Subject: IPv4 Legacy assignment frustration Message-ID: I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet. Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them. Is there any way to raise awareness to this inconsistency so that security people will stop doing this? Shannon Spurling shannon at more.net From ops.lists at gmail.com Wed Jun 22 03:01:43 2016 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 22 Jun 2016 08:31:43 +0530 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: Message-ID: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> There is absolutely no budgeting for idiots. Beyond a long hard process that is helped by internal escalations from affected people on a corporate network - ideally as senior as you can get - ot their IT staff. ?Missouri isn?t in China, you nitwit. Fix it or I, the CFO, will go have a word with the CIO and ..? In other words, have affected people escalate up the chain to the ISP or more likely corporate IT team that?s doing this sort of stupid filteringg. > On 21-Jun-2016, at 8:07 PM, Spurling, Shannon wrote: > > I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet. > > Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them. > > Is there any way to raise awareness to this inconsistency so that security people will stop doing this? From morrowc.lists at gmail.com Wed Jun 22 03:36:02 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Jun 2016 23:36:02 -0400 Subject: IPv4 Legacy assignment frustration In-Reply-To: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: how is this a problem with the RIR ? On Tue, Jun 21, 2016 at 11:01 PM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > There is absolutely no budgeting for idiots. Beyond a long hard process > that is helped by internal escalations from affected people on a corporate > network - ideally as senior as you can get - ot their IT staff. ?Missouri > isn?t in China, you nitwit. Fix it or I, the CFO, will go have a word with > the CIO and ..? > > In other words, have affected people escalate up the chain to the ISP or > more likely corporate IT team that?s doing this sort of stupid filteringg. > > > On 21-Jun-2016, at 8:07 PM, Spurling, Shannon wrote: > > > > I am not sure how many on the list are Legacy resource holders from > before the RIR's were established, but there is an extremely short sighted > security practice that is being used across the internet. > > > > Apparently, the RIR that has been given "authority" for an IP prefix > range that was a legacy assignment is being used as a geographical locator > for those prefixes. For instance, we provide access for several /16's that > are in the 150/8 prefix that was set as APNIC. I am aware of quite a few > organizations in the US that have prefixes in that range. We have > registered our legacy resources with ARIN, but there are some people insist > that somehow the state of Missouri must be part of China because... > "APNIC!". They set firewalls and access rules based on that, and are hard > pressed to not fix them. > > > > Is there any way to raise awareness to this inconsistency so that > security people will stop doing this? > > From marka at isc.org Wed Jun 22 06:17:57 2016 From: marka at isc.org (Mark Andrews) Date: Wed, 22 Jun 2016 16:17:57 +1000 Subject: Bad firewall/nameserver behaviour causing timeouts of DNS queries. Message-ID: <20160622061757.C2CE54BF1EE7@rock.dv.isc.org> The following nameservers for Alexa top 1M names fail to respond to EDNS queries with EDNS options specified or fail to respond to consecutive EDNS queries. These have been run through the checks multiple times to reduce the probability of false positives as timeout can be the due to multiple causes. For many there are other errors that should also be addressed. This misbehaviour can cause DNSSEC validation to FAIL when the servers serve signed zones. This misbehaviour does result in significantly slower DNS resolution (multiple seconds). You can test your servers at https://ednscomp.isc.org/ This is sent here because both SOA and whois contact details are wrong too often to bother trying to send to these addresses even if whois was easy to parse. Please fix your firewalls / nameservers as they are causing operational problems. Mark lb.pagofacil.com.ar lb.pagofacil.com.ar lb.pagofacil.com.ar server.inet.edu.ar siet.inet.edu.ar ns2.pillar.com.au ns1.agric.wa.gov.au ns2.agric.wa.gov.au ns3.agric.wa.gov.au ns1.win.be ns2.win.be ns.ahlia.edu.bh lb3.ache.com.br ns2.bibliomed.com.br ns3.caixaseguros.com.br sdccd01.light.com.br ns1.poupex.com.br ns3.poupex.com.br ns1.semparar.com.br ns2.semparar.com.br creaprw12.crea-pr.org.br dns5.allstate.ca ns1.bellnhs.ca ns3.bellnhs.ca ns5.bellnhs.ca ns1.cpr.ca ns2.cpr.ca ns1.cnsc-ccsn.gc.ca ns2.cnsc-ccsn.gc.ca ns1.knowledgeone.ca ns2.knowledgeone.ca ns3.mmms.ca gemini.hrsb.ns.ca ns.city.windsor.on.ca ns2.city.windsor.on.ca ns1.thomascookgroup.ca ns2.thomascookgroup.ca ns1.bger.ch ns2.bger.ch dn2.1.cl ns.autopistacentral.cl peumo.bancoconsorcio.cl roble.bancoconsorcio.cl dns.bci.cl dns2.bci.cl ns.subtel.cl nsaut.tie.cl ns2.sina.com.cn name.srit.com.cn dns.hncj.edu.cn dns2.hncj.edu.cn dns.hut.edu.cn dns2.hut.edu.cn dns.jju.edu.cn dns.lit.edu.cn dns.by.gov.cn dns2.gxeea.cn ns1.coscologistics.sh.cn ariadne.presidencia.gov.co bdpalacio.presidencia.gov.co ns3.360safe.com ns4.360safe.com ns5.360safe.com ns2.51dns.com ns8.91989.com ns9.91989.com ns1.advisorlynx.com ns2.advisorlynx.com ns1.aegis-k.com ns2.aegis-k.com ns1.affinity-petcare.com ns01.airliquide.com ns03.airliquide.com ns1.alidns.com ns1.alidns.com ns2.alidns.com ns2.alidns.com ns2.alidns.com vip1.alidns.com vip1.alidns.com vip1.alidns.com vip1.alidns.com vip1.alidns.com vip1.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com vip2.alidns.com ns1.amaes.com ns2.amaes.com ns1.amatteroffax.com ns3.amvescap.com ns5.amvescap.com ns1.arcatapet.com office.arcatapet.com pridns.ascendas.com ns01.avanade.com ns02.avanade.com ns2.avastkorea.com det.dns.bbdo.com ns1.bcbsmn.com ns2.bcbsmn.com harris-ns.bcharrispub.com harris-ns2.bcharrispub.com bor-cp01.borouge.com bvdns.broadviewnet.com bvdns2.broadviewnet.com ns5.carbonlogic.com ns2.ccmnyc.com ns1.cmsbiztech.com ns1.corsicaferries.com ns3.corsicaferries.com ns4.corsicaferries.com ns1.credibanco.com ns2.credibanco.com cscdnscph002d.csc.com cscdnshyd002d.csc.com cscdnsklm002d.csc.com cscdnsmds002d.csc.com cscdnsnoi002d.csc.com cscdnssng002d.csc.com palladium.csc.com wserver.cyberdental.com webmail.dbfsindia.com ns1.deseretdigital.com ns2.deseretdigital.com huey.disney.com huey11.disney.com a.dnspod.com a.dnspod.com c.dnspod.com c.dnspod.com ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com ns1.dnsv2.com ns2.dnsv2.com ns2.dnsv2.com ns2.dnsv2.com ns2.dnsv2.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns1.dnsv3.com ns2.dnsv3.com ns2.dnsv3.com ns1.dnsv4.com ns1.dnsv4.com ns1.dnsv4.com ns1.dnsv4.com ns1.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns2.dnsv4.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns1.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns2.dnsv5.com ns03.dominos.com ns04.dominos.com ns05.dominos.com ns1.dynalifedx.com ns1.dynamex.com ns2.dynamex.com name1.eidebailly.com name2.eidebailly.com ns1.evaair.com ns2.evaair.com ns3.evaair.com ns4.evaair.com ns.excodaegu.com ns.fanforum.com ns1.fanforum.com leo.generator.com ns1.gesnetwork.com ns01.globalexchangetechnology.com ns02.globalexchangetechnology.com gtmgrin.gmrc.com gtmnew.gmrc.com ns3.gmrc.com ns4.gmrc.com ns2.greensburgdailynews.com dns.heffel.com dns1.hichina.com dns1.hichina.com dns1.hichina.com dns10.hichina.com dns10.hichina.com dns10.hichina.com dns11.hichina.com dns11.hichina.com dns11.hichina.com dns13.hichina.com dns13.hichina.com dns13.hichina.com dns14.hichina.com dns14.hichina.com dns14.hichina.com dns17.hichina.com dns17.hichina.com dns18.hichina.com dns18.hichina.com dns2.hichina.com dns2.hichina.com dns21.hichina.com dns21.hichina.com dns21.hichina.com dns22.hichina.com dns22.hichina.com dns22.hichina.com dns25.hichina.com dns25.hichina.com dns25.hichina.com dns26.hichina.com dns26.hichina.com dns26.hichina.com dns29.hichina.com dns29.hichina.com dns29.hichina.com dns30.hichina.com dns30.hichina.com dns30.hichina.com expirens3.hichina.com expirens4.hichina.com ns1.hichina.com ns1.hichina.com ns1.hichina.com ns2.hichina.com ns2.hichina.com ns2.hichina.com dns-na-1.hill-rom.com dns-na-2.hill-rom.com dns-na-3.hill-rom.com dns5.hkinventory.com ns2.webhost.hm-software.com ns1.hotelbb.com ns10.huntington.com ns11.huntington.com ns12.huntington.com ns13.huntington.com ns.ied.com dns3.ifrontiers.com ns2.illumen.com ns1.inet-svcs.com ns2.inet-svcs.com ns4a.inet-web.com ukdns.integralis.com dns3.integramed.com ns2.jaxsheriff.com dns1.k-line.com ns1.kds.com ns2.kds.com dns2.kline.com ns.krunis.com ns.kumkang.com labattdns2.labattfood.com ns3.lallemand.com ns4.lallemand.com ns5.lfg.com ns6.lfg.com gltb-ns1.srv.lukoil.com gltb-ns2.srv.lukoil.com mbsii2.mbsii.com fox2.mightyautoparts.com ftp.munichreamerica.com dns2.mysteel.com ns1.nameaction.com ns2.nameaction.com ns2.namesv.com dns.neovi.com ns3.nextsite.com ns1.nhimidwest.com oss.oss.com ns1.page-az.com capital1.pantavanij.com slmns1.paymentech.com tamns1.paymentech.com webserver.pcgitaly.com ah-ns.plex.com dv-ns.plex.com mail.ppe.com w5.ppe.com ns.procuebynet.com ns2.project-la.com ns4.regalhotel.com ns1lo6.reutersmedia.reuters.com ns1nj.reutersmedia.reuters.com ns2lo6.reutersmedia.reuters.com ns2nj.reutersmedia.reuters.com ns1.samudera.com southern1.scsnet.com southern2.scsnet.com ns4.seacomnet.com lp1000r-10194.admin.sfhs.com dns1.shift4.com dns2.shift4.com gtm.shlegal.com skyserver.skycode.com smans1.smaportal.com vm01.splendidlive.com ns1.sterling-intl.com ns2.sterling-intl.com ns1.techdev.com ns2.techdev.com dns1.teldat.com dnsserver.teldat.com mx1.telmar.com ns1.thronecomputer.com ns03.toolwire.com ns04.toolwire.com ns0.topgayblacksites.com ns1.tranguard.com ns3.tranguard.com ns2.travelbrands.com cloud3.triara.com ns1.twglobalmall.com jinx.ucbiz.com ns1.urix.com ns2.urix.com nschs.virgin-atlantic.com nsrhl.virgin-atlantic.com ns2.welcodns.com bri-ns01.wiley.com ns1.williams.com ns2.williams.com ns1.wiredviews.com web.wlio.com ns1.yourmortgageonline.com ns2.yourmortgageonline.com dns3.zeleris.com ns3.bccr.fi.cr ns4.bccr.fi.cr ns1.network.cr ns2.network.cr aragorn.autocont.cz ns.forpsi.cz ns.profireal.cz ns2.profireal.cz ns1.euv-frankfurt-o.de ns2.euv-frankfurt-o.de dns.ipsos.de ns1.suedkurier.de ns2.suedkurier-medienhaus.de dns.webtop.de dnskm.univ-km.dz lomanegra.jardinazuayo.fin.ec ns1.amberton.edu ns1.contracosta.edu ns1.gptc.edu ns1.malone.edu ns2.malone.edu ns5.regent.edu ns.sabanciuniv.edu ns2.sabanciuniv.edu muser252.scciowa.edu ns2.sidwell.edu dns.dpz.es ns2.interdigital.es crea.rae.es ns9.rae.es dns.registromercantilbcn.es ns2.tko.fi nimi1.website.fi nimi2.website.fi antares.c-strasbourg.fr erlwbi.interflora.fr proxy1-rech.univ-valenciennes.fr pulsar.univ-valenciennes.fr titan.univ-valenciennes.fr ns1.hamiltontn.gov rembrandt.masoutis.gr gslb1.tigo.com.gt gslb2.tigo.com.gt ns2.adsale.com.hk ns1.skhsslmc.edu.hk dns.matica.hr dns.plavalaguna.hr dante.univet.hu ns1.dnk.net.id ns1.lgcsb.ie ns2.lgcsb.ie ns1.modata.ie ns1.nethost.co.il ns2.nethost.co.il jbs.ac.in pdns.sit.ac.in ns1.axisbank.co.in ns1.tmc.gov.in ns2.tmc.gov.in ns1.teri.res.in ns2.teri.res.in ns1.idro.ir ns2.idro.ir ns1.isipo.ir ns1.audit.org.ir ns1.imo.org.ir dns.biesse.it dns.careca.it sct2.carontetourist.it dns.cpsoftware.it ns2.invisiblesite.it alfaterna.nuceria.it ns.sevenlab.it dns.gtt.torino.it cap.tuins.ac.jp dns-x.sinet.ad.jp dns2.aoshima-bk.co.jp ns.kew.co.jp juno.ntt-itn.co.jp vesta.ntt-itn.co.jp ns.santec.co.jp ns.toshiba-carrier.co.jp dns.mcinc.jp ns.hkr.ne.jp dns1.jcc.ne.jp ns01.netcoms.ne.jp ns.netsjapan.jp ns2.awa.or.jp lbdn.occto.or.jp lbdn2.occto.or.jp july.river.sun-inet.or.jp sakura.unep.or.jp pbant2.pba.jp pbant2.pba.jp dns2.ysu.ac.kr ns.carz.co.kr astra02.coreana.co.kr ns.kcm.co.kr ns.zakon.kz ns1.customs.gov.lk ns1.sliit.lk relay.cail.lu dns3.bkam.ma smtp-dns.douane.gov.ma dns1.onssa.gov.ma dns.dicj.gov.mo dns0.anahuac.mx dns1.anahuac.mx ns1.atento.com.mx dns1.hdi.com.mx ns2.hdi.com.mx dns.segurosatlas.com.mx ns1.tvsa.com.mx dca.cu.uabjo.mx ns.uabjo.mx aldebaran.2m-equation.net ns2.a-o-b.net ns.access-accounts.net ns2.autodata.net mail.brtk.net ns2.cengage.net dnssdc.dagangnet.net ns1.digitalimpact.net ns2.digitalimpact.net bizcn1.dnspod.net bizcn1.dnspod.net bizcn1.dnspod.net bizcn1.dnspod.net bizcn2.dnspod.net bizcn2.dnspod.net dns12.duckwood.net dns20.duckwood.net ns1.ecolon.net ns1.ecsd.net cobra.endless.net cebudns.epldt.net enyo2.ez2.net ns.forpsi.net pro2.gfdns.net dns1.hemsida.net ns1.host-web.net dns2.hostingsolutions.net ns1.knibs.net dev.labellum.net dns01.mathbox.net ns1.netlinksys.net ns30.netsupport.net ns2.oxi.net ns3.pasporte.net ns4.pasporte.net ns01.reyrey.net ns02.reyrey.net ns2.rj2t.net ns1.safetyhost.net dns1.sge.net dns2.sge.net dns3.sge.net dns4.sge.net ns.telanet.net ns-amers-1.thomsonreuters.net ns-amers-2.thomsonreuters.net ns-apac-1.thomsonreuters.net ns-apac-2.thomsonreuters.net ns-emea-1.thomsonreuters.net ns-emea-2.thomsonreuters.net ns4.traddns.net ns1.vologic.net ns2.vologic.net ns6.wgn.net ns3.xodeportal.net ns4.xodeportal.net ss-ns02.infocare.no ns01.prioritytelecom.no ns1.spsor.no ns2.spsor.no ns.freightways.co.nz dns1.clear.net.nz dns2.clear.net.nz kirsty.paradise.net.nz rachel.paradise.net.nz ns1.abp.org mc-dc-gtm1.act.org mc-dc-gtm2.act.org ns1.ecusd7.org ns1.jaxsheriff.org ns2.jcboe.org dc1gtm01.mercywny.org dc2gtm01.mercywny.org dns1.mkcl.org ns1.mozilla.org trl-dns1.tricore.org reinberger.wrhs.org dns1.dge.gob.pe ns1.asiaunited.com.ph ns1.asiaunited.com.ph ns2.asiaunited.com.ph ns2.aub.com.ph ns1.cityschoolnetwork.edu.pk ns0.bdm.com.pl ns2.am.szczecin.pl ns.aip.pt anje01.anje.pt ns2.drealentejo.pt ns3.drealentejo.pt ns1.ipad.mne.gov.pt farolim.min-edu.pt ns1.qiib.com.qa ns2.qiib.com.qa ns1.mfinante.ro ns2.mfinante.ro ns2.550550.ru ns2.croc.ru ns1.izh.ru ns2.izh.ru ns01.nakolesah.ru ns1.primbank.ru ns2.primbank.ru santa.veb.ru ns.securityservice.se pridns.dlink.com.sg pridns.stee.com.sg secdns.stee.com.sg merlion.iseas.edu.sg merlion2.iseas.edu.sg ns.aktifbank.com.tr ns.mngturizm.com.tr ns1.sarar.com.tr ns2.sarar.com.tr ns.kepez-bld.gov.tr inter-dns.mfa.gov.tr inter2-dns.mfa.gov.tr ns10.is.net.tr ns3.is.net.tr istasr.isbank.net.tr alfa.atso.org.tr beta.atso.org.tr cmgcdns.china-motor.com.tw ns1.clco.com.tw dnsc.credit.com.tw dns2.fullon-hotels.com.tw dns1.gigatms.com.tw dns1.him.com.tw dns1.himax.com.tw dns2.himax.com.tw sunntb.infiniti.com.tw dns.investor.com.tw dns1.krtco.com.tw dns2.krtco.com.tw ns1.luxgen-motor.com.tw ns2.luxgen-motor.com.tw idc-dns1.megasec.com.tw dns.scsb.com.tw dns1.tkbtv.com.tw ymtadc01.yamaha-motor.com.tw ymtadc02.yamaha-motor.com.tw acts.pct.org.tw lcotextdns.leeds-lcot.ac.uk unixa.nerc-swindon.ac.uk muppet.s-cheshire.ac.uk ns2.uxbridge.ac.uk ns1.skipton.co.uk ns2.skipton.co.uk ns2.smartkonect.co.uk ns-f5-01.spicerhaart.co.uk ns-f5-02.spicerhaart.co.uk smodns01.hackney.gov.uk ns.forpsi.us dl9rv21.ldol.state.la.us ns1.mcps.k12.md.us ns2.mcps.k12.md.us ns1.pacourts.us ns2.pacourts.us dns1.pittcounty.us dns2.pittcounty.us cronos.scotiabank.com.uy hestia.scotiabank.com.uy cedns.corteelectoral.gub.uy lancelot.dgr.gub.uy ingenio03.latu.org.uy dns1.hnue.edu.vn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org ------- End of Forwarded Message From mohta at necom830.hpcl.titech.ac.jp Wed Jun 22 08:20:33 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 22 Jun 2016 17:20:33 +0900 Subject: IP and Optical domains? In-Reply-To: <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> Message-ID: Mark Tinka wrote: > I'd like to hear your proposals on how Layer 3 protocols can be better > designed to manage transport characteristics. By not managing transport characteristics at all except that links are on or off (or, if you want to guarantee QoS, a little more than that). L3 protocols know links are off if L2 operators actively turn them off or if the protocols detect consecutive lack of L3 HELO generated frequently enough. L2 operators turns links off for maintenance and BER degradations need unscheduled maintenance. >> That's L1, which is also required to exist. > > It's Layer 1 and Layer 2. Ethernet is running over those optics, albeit > with no "traditional" optical equipment in between. So, no disagreement, here. >> So, you deny the original point of "The result of this is that the >> networks are heavily underutilized". OK. > We upgrade at 50% utilization. Others do it at 70% utilization. Others > do it at 100% utilization. Heck, I know some that do it at 40% utilization. I'm afraid "heavily" implies a lot less utilization. Masataka Ohta From mark.tinka at seacom.mu Wed Jun 22 08:29:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 22 Jun 2016 10:29:36 +0200 Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> Message-ID: On 22/Jun/16 10:20, Masataka Ohta wrote: > > By not managing transport characteristics at all except > that links are on or off (or, if you want to guarantee QoS, > a little more than that). But how do Layer 3 protocols manage transport characteristics today? Unless I misunderstand your statement. > > L3 protocols know links are off if L2 operators actively > turn them off or if the protocols detect consecutive lack > of L3 HELO generated frequently enough. > > L2 operators turns links off for maintenance and > BER degradations need unscheduled maintenance. Again, this does not seem too removed from what happens already today. Unless I misunderstand what you are saying. > > > I'm afraid "heavily" implies a lot less utilization. I don't disagree with what you imply by "heavily". What I am saying is "a lot less" or "a lot more" is not a universal measure. It means different things to different people, as business operations (which largely drive this kind of thing) differ widely. Mark. From Jeroen.Wunnink at hibernianetworks.com Wed Jun 22 09:08:53 2016 From: Jeroen.Wunnink at hibernianetworks.com (Jeroen Wunnink) Date: Wed, 22 Jun 2016 09:08:53 +0000 Subject: Google Geolocation issue In-Reply-To: <1466533507.2680.14.camel@beagle> References: <1466533507.2680.14.camel@beagle> Message-ID: Email their NOC directly. I?ve had some success with that: ggc at google.com / noc at google.com Also, sign up at https://isp.google.com/, there?s an option there to provide a self-published geo-feed for your IP space: http://tools.ietf.org/id/draft-google-self-published-geofeeds-02.html Which may or may not be taken into consideration for geo-locating your IP space ;-) I quote: "Google can process self-published IP geolocation data for your network. This information will be used as an additional signal to help improve the location accuracy Google products." ? Jeroen Wunnink IP Engineering Manager Hibernia Networks - Amsterdam Office Main numbers (Ext: 1011): USA +1.908.516.4200 | Canada +1.902.442.1780 Ireland +353.1.867.3600 | UK +44.1704.322.300 | Netherlands +31.208.200.622 24/7/365 IP NOC Phone: +31.20.82.00.623 Jeroen.Wunnink at hibernianetworks.com www.hibernianetworks.com On 21/06/16 20:25, "NANOG on behalf of Chris Boyd" wrote: >Dear list readers, please forgive the noise, but if there's anyone here >from Google who can fix a geolocation issue I'd appreciate a reply. > >208.81.245.226 is not in the UAE, it's in Austin, Texas. Yes, I have >filled out the form to request a fix, but the AI or whatever that's >supposed to fix it has not, and we're well into 3 months after the first >report. > >Thanks, > >--Chris > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From mohta at necom830.hpcl.titech.ac.jp Wed Jun 22 09:58:51 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 22 Jun 2016 18:58:51 +0900 Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> Message-ID: <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> Mark Tinka wrote: >> By not managing transport characteristics at all except >> that links are on or off (or, if you want to guarantee QoS, >> a little more than that). > > But how do Layer 3 protocols manage transport characteristics today? Today??? You asked "can be better designed", didn't you? And, don't miss the following assumption: > L3 HELO generated frequently enough. > Again, this does not seem too removed from what happens already today. The problem, if any, is that doing much more than that results in "heavily underutilized" network. > I don't disagree with what you imply by "heavily". The implication is not mine. Masataka Ohta From mark.tinka at seacom.mu Wed Jun 22 10:07:49 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 22 Jun 2016 12:07:49 +0200 Subject: IP and Optical domains? In-Reply-To: <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> Message-ID: On 22/Jun/16 11:58, Masataka Ohta wrote: > > Today??? You asked "can be better designed", didn't you? But IP does not manage transport characteristics. If packets can't get through, they are dropped. Fairly simple. Typical awareness about the transport layer is not normally privy to IP. Yes, IPoDWDM means the visbility is there, but really, all it's doing is cutting off a link just before the thresholds are met, to avoid packet loss. Yes, BFD does provide IP some awareness, but this is not inherent in IP itself. > > The problem, if any, is that doing much more than that > results in "heavily underutilized" network. Sorry, I'm just not getting your angle - could be something getting lost in translation. Not sure how frequent Hello messages exchanged by routing protocols leads to a heavily under-utilized network. Mark. From mattlists at rivervalleyinternet.net Wed Jun 22 11:09:51 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 22 Jun 2016 07:09:51 -0400 Subject: Issues reaching major websites Message-ID: I know I had very sparse information. Apparently frontier was having some sort of transport issue in Pennsylvania. This from their NOC. From mohta at necom830.hpcl.titech.ac.jp Wed Jun 22 11:17:35 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 22 Jun 2016 20:17:35 +0900 Subject: IP and Optical domains? In-Reply-To: References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> Message-ID: <52ae3495-4838-cba0-15b0-568950052ced@necom830.hpcl.titech.ac.jp> Mark Tinka wrote: > Typical awareness about the transport layer is not normally privy to IP. > Yes, IPoDWDM means the visbility is there, but really, all it's doing is > cutting off a link just before the thresholds are met, to avoid packet loss. What? "the visibility is there"? I think you mean IPoDWDM something so much different from usual ways to have IP over something. Do you have any reference to it? For my definition of IPoDWDM, see, for example: "Standardization of optical packet switching with many-wavelength packets" http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4542288 or my newest paper in HPSR2016. Masataka Ohta From marka at isc.org Wed Jun 22 11:36:35 2016 From: marka at isc.org (Mark Andrews) Date: Wed, 22 Jun 2016 21:36:35 +1000 Subject: The following nameservers incorrectly return BADVERS Message-ID: <20160622113635.131734BF344C@rock.dv.isc.org> The following servers for Alexa top 1M names incorrectly return BADVERS to a DNS query with a EDNS option. BADVERS is supposed to be used for EDNS version negotiation not because you see a EDNS option. Please contact your nameserver vendor for a fix. This error will result in DNS validation failures if you are serving signed zones. This error will also result in slower DNS resolution. Mark a.myradns.at b.myradns.at ns1.careerhub.com.au ns2.careerhub.com.au ns3.careerhub.com.au lyra.caixa.gov.br mira.caixa.gov.br ns1.divio.ch ns2.divio.ch ns4.divio.ch ns2.ec.com.cn sns.ec.com.cn ns1.sina.com.cn mecca.dlnu.edu.cn ns2.brainydns.com ns1.commonmx.com ns2.commonmx.com ns1.derbycon.com ns2.derbycon.com ns3.derbycon.com ns4.derbycon.com ns1.dnsnuts.com ns2.dnsnuts.com ns1.dockyard.com ns3.dockyard.com ns2.domainmx.com ns1.energeticsource.com ns2.energeticsource.com dev2.hastydns.com ns1.hastydns.com ns2.hastydns.com ns.inboxinc.com ns3.inboxinc.com ns1.kirklanddc.com ns2.kirklanddc.com ns1.nawebu.com ns2.nawebu.com ns3.nawebu.com ns1.pebblecode.com ns2.pebblecode.com ns3.pebblecode.com ns1.pro-websolutions.com ns4.pro-websolutions.com ns1.redmonddc.com ns2.redmonddc.com ns1.rentondc.com ns2.rentondc.com ns1.smtmdns.com ns2.smtmdns.com ns1.torresdns.com ns2.torresdns.com ns1.usecanvas.com ns2.usecanvas.com ns4.weddingful.com ns1.worlize.com ns2.worlize.com a.myradns.de b.myradns.de ns3.zenjoy.eu ns1.tsp.gov ns2.tsp.gov ns1.360dns.net ns2.360dns.net uns1.bhn.net uns2.bhn.net ns1.bindhost.net ns2.bindhost.net itchy.earthlink.net scratchy.earthlink.net a.myradns.net b.myradns.net c.myradns.net resolver1.qwest.net resolver2.qwest.net sauthns1.qwest.net sauthns2.qwest.net ns1-asia.sprintlink.net ns1-auth.sprintlink.net ns2-asia.sprintlink.net ns2-auth.sprintlink.net ns3-asia.sprintlink.net dns4.websolvers.net ns2.panmedia.co.nz ns1.collegiateschool.org ns4.collegiateschool.org ns.min-financas.pt dns.ntu.edu.tw ntust.edu.tw dns.ntust.edu.tw ns2.grade.us -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Wed Jun 22 11:49:47 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 22 Jun 2016 13:49:47 +0200 Subject: IP and Optical domains? In-Reply-To: <52ae3495-4838-cba0-15b0-568950052ced@necom830.hpcl.titech.ac.jp> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> <52ae3495-4838-cba0-15b0-568950052ced@necom830.hpcl.titech.ac.jp> Message-ID: <4e8a44d8-1a8e-1f34-76af-bf581153751d@seacom.mu> On 22/Jun/16 13:17, Masataka Ohta wrote: > > What? "the visibility is there"? > > I think you mean IPoDWDM something so much different from > usual ways to have IP over something. > > Do you have any reference to it? I said "visbility" due to what IPoDWDM can offer. But I also said IP has no real "awareness" about the physical infrastructure. It just knows it can't send/receive packets anymore. With IPoDWDM, one could infer that the IP layer will quickly re-route due to DWDM characteristics (related to fibre conditions). However, in actual fact, what IP really sees is the link going away, and thus, triggering an IGP reconvergence. It does not really know that the degraded optical signal quality on the fibre was the cause, it just knows that the link disappeared. There is no difference if IP is running directly over fibre (in Ethernet). The difference with IPoDWDM is that the re-routing is done before the fibre actually loses link, because the line card is monitoring the optical signal and deciding whether to keep the port up or not. This is to minimize (or avoid) packet loss incurred by failing only after link failure (which would be the case with generic IP running directly over fibre (again, in Ethernet). Whatever the case, IP is not aware about the state of the physical link. It just sees the link going away. But something tells me you know all this already, so... > > For my definition of IPoDWDM, see, for example: > > "Standardization of optical packet switching with > many-wavelength packets" > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4542288 > > or my newest paper in HPSR2016. Interesting. Do you know of any implementations? Mark. From shannon at more.net Wed Jun 22 13:36:56 2016 From: shannon at more.net (Spurling, Shannon) Date: Wed, 22 Jun 2016 13:36:56 +0000 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: It?s a problem with the miss-use of the RIR delegation of a legacy block. The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR?s territory, without actually running a query against that RIR?s Whois database. From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, June 21, 2016 10:36 PM To: Suresh Ramasubramanian Cc: Spurling, Shannon ; nanog at nanog.org Subject: Re: IPv4 Legacy assignment frustration how is this a problem with the RIR ? On Tue, Jun 21, 2016 at 11:01 PM, Suresh Ramasubramanian > wrote: There is absolutely no budgeting for idiots. Beyond a long hard process that is helped by internal escalations from affected people on a corporate network - ideally as senior as you can get - ot their IT staff. ?Missouri isn?t in China, you nitwit. Fix it or I, the CFO, will go have a word with the CIO and ..? In other words, have affected people escalate up the chain to the ISP or more likely corporate IT team that?s doing this sort of stupid filteringg. > On 21-Jun-2016, at 8:07 PM, Spurling, Shannon > wrote: > > I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet. > > Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them. > > Is there any way to raise awareness to this inconsistency so that security people will stop doing this? From aj at sneep.net Wed Jun 22 13:44:34 2016 From: aj at sneep.net (Alastair Johnson) Date: Wed, 22 Jun 2016 06:44:34 -0700 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: <2b655440-3280-9ab0-58b0-f252d2c4565e@sneep.net> On 6/22/16 6:36 AM, Spurling, Shannon wrote: > It?s a problem with the miss-use of the RIR delegation of a legacy > block. > > The assumption that because a block is assigned to a particular RIR, > all users in that block have to be in that RIR?s territory, without > actually running a query against that RIR?s Whois database. I don't think it's an RIR / RIR-related problem, just - as you said - a short-sighted security practice. Operators that connect to the Internet and then decide "OMG, Asia is evil" are fairly frustrating. This has caused me a number of problems for decades, as AU/NZ are fairly frequent trading partners of USA and I have frequently run into this attitude. From jcurran at arin.net Wed Jun 22 13:59:14 2016 From: jcurran at arin.net (John Curran) Date: Wed, 22 Jun 2016 13:59:14 +0000 Subject: Questions asked of potential candidates for ARIN Board of Trustees / ARIN AC / NRO NC References: <576174AB.60404@arin.net> Message-ID: <93519EF2-4AAF-40FF-BEE1-8F020BF49BC5@corp.arin.net> NANOGers - Each year, the ARIN community asks the potential nominees to the Board and ARIN Advisory Council to complete a questionnaire of biographic information as well as other questions that might help folks better understand their qualifications and perspective. For example, the 2015 nominee questions included (among others) "How do you foresee ARIN's function, scale, or role changing in the wake of IPv4 exhaustion?? and "What are your thoughts on the rights and responsibilities of legacy IP address holders?? The cutoff for submission of questions to the Nominations Committee for consideration for inclusion in the 2016 questionnaire is next Wednesday (29 June 2016) - please see the attached announcement for additional details and submission information. Thanks! /John John Curran President and CEO ARIN === Begin forwarded message: From: ARIN > Subject: [arin-announce] Community Input Sought for 2016 Nominee Questionnaires Date: June 15, 2016 at 11:30:51 AM EDT To: > Each fall, ARIN's membership elects individuals to the ARIN Board of Trustees and Advisory Council (AC), including selecting one ARIN representative to the Number Resource Organization Number Council (NRO NC). To run, a nominee must submit an online questionnaire that is designed to elicit details of their relevant experience. In preparation, ARIN is opening the floor to the community for input in this year's nominee questionnaires. If you have questions that are relevant to policy issues or challenges facing ARIN that you'd like candidates to answer, send them to members at arin.net no later than 29 June 2016. Please mark whether your question is directed to candidates for the Board of Trustees, AC, or the NRO NC, or any combination of the three. The Nomination Committee (NomCom) will review all submissions and then determine the final list and phrasing of all candidate questions. ARIN will publish candidate bios, including their questionnaire responses, when the slate of candidates is announced on 15 September. Questionnaire responses will also appear in the 2016 Voter Guide that will be mailed to all member organizations this fall prior to elections. To learn more about the Board of Trustees and AC election procedures and to view the 2015 nominee questions, please visit: https://www.arin.net/participate/elections/elec_procedures.html To learn more about the NRO NC election/appointment procedures and to view the 2015 nominee questions, please visit: https://www.arin.net/participate/elections/nronumbercouncil.html To learn more about ARIN Elections and upcoming key dates, please visit: https://www.arin.net/participate/elections/index.html As always, ARIN values community participation and input. We look forward to receiving your questions! Regards, Wendy Leedy Member Engagement Coordinator American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From dot at dotat.at Wed Jun 22 14:37:11 2016 From: dot at dotat.at (Tony Finch) Date: Wed, 22 Jun 2016 15:37:11 +0100 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: Spurling, Shannon wrote: > It?s a problem with the miss-use of the RIR delegation of a legacy > block. > > The assumption that because a block is assigned to a particular RIR, all > users in that block have to be in that RIR?s territory, without actually > running a query against that RIR?s Whois database. Actually, a simple whois query often isn't enough to solve this problem. Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that are registered in other RIRs. ARIN, however, does. (However, if the geoip people are using whois data, I can't believe they aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.) If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length): % IANA WHOIS server refer: whois.apnic.net inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY % [whois.apnic.net] inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases: (It then unhelpfully lists all the other RIRs.) FreeBSD's whois client spots this failure then retries the query at ARIN. There's a similar problem with RIPE, for instance if you query for 141.211.0.0: % IANA WHOIS server refer: whois.ripe.net inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY % This is the RIPE Database query service. inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at: (It then unhelpfully lists all the other RIRs.) Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE. BUT NOTE! The APNIC and RIPE databases do in fact contain the referral information - you can get it via RDAP but not whois. Repeating the examples, $ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0 $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor. From jason.iannone at gmail.com Wed Jun 22 15:56:56 2016 From: jason.iannone at gmail.com (Jason Iannone) Date: Wed, 22 Jun 2016 09:56:56 -0600 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: The IP and Transport groups are customers of each other. When I need a wire, I ask the Transport group to deliver a wire. This is pretty simple division of labor stuff. Transport has the intimate knowledge of the layer 1 infrastructure and IP has intimate knowledge of services. Sure there is information share, but I don't need to assign wavelengths or protection groups or channels. I don't need to know if I'm getting an OTU or some other lit service (except when I do need to know). We use clear jargon to order services from each other. "Please deliver two diverse, unprotected circuits between cilli1 and cilli2." If I want LACP or spanning-tree, I want OTU or another means of ensuring L2 tunneling, so I either predefine these requirements before we start our relationship or I explicitly order it. When I think of converging IP and Transport, I think of combining the extraordinary depth of knowledge required by each group's individual contributors. You just turned your 100k employee into a 175k employee. On top of that, add that we're all becoming software developers and you've got a three horned unicorn. In the end I guess this is the cycle of convergence to distribution and back writ HR. On Sat, Jun 18, 2016 at 3:27 PM, Glen Kent wrote: > HI, > > I was reading the following article: > http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616 > > It says that "The IP layer and optical layer are run like two separate > kingdoms," Wellingstein says. "Two separate kings manage the IP and optical > networks. There is barely any resource alignment between them. The result > of this is that the networks are heavily underutilized," or, from an > alternative perspective, "they are heavily over-provisioned." > > Can somebody shed more light on what it means to say that the IP and > optical layers are run as independent kingdoms and why do ISPs need to > over-provision? > > Thanks, Glen From kraig at enguity.com Wed Jun 22 16:06:18 2016 From: kraig at enguity.com (Kraig Beahn) Date: Wed, 22 Jun 2016 12:06:18 -0400 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: The following might add some clarity, depending upon how you look at it: We, as "core" engineers know better than to use some of the sources listed below, tho, my suspicion is that when an engineer or local IT person, on an edge network starts to see various types of attacks, they play wack-a-mole, based upon outdated or incomplete data, and never think twice about revisiting such, as, from their perspective, everything is working just fine. In a networking psychology test, earlier this morning, I wrote to ten well-known colleagues that I was fairly confident didn't regularly follow the nanog lists. Such individuals comprised of IP and IT engineers for which manage various network sizes and enterprises, ultimately posing the question of "Where in the world is 150.201.15.7, as we were researching some unique traffic patterns". *Seven out of ten came back with overseas*. Two came back with more questions "as the address space appeared to be assigned to APNIC", but was routed domestically. *One came back with the correct response.* (MORENET) Two of the queried parties were representative of major networks, one for an entire state governmental network with hundreds of thousands of actual users and tens of thousands of routers, the other from another major university. (Names left out, in the event they see this message later in the day or week) After probing the origin of their responses, I found the following methods or data-sources were used: -Search Engines - by far, the worst offender. Not necessarily "the engines" at fault, but a result of indexed sites containing inaccurate or outdated CIDR lists. -User generated forums, such as "Block non-North American Traffic for Dummies Like Me " (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. Member) -Static (or aged) CIDR web-page based lists, usually placed for advertorial generation purposes and rarely up to date or accurate. (usually via SE's or forum referrals) -APNIC themselves - A basic SE search resulted in an APNIC page that, on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the current APNIC range. -GitHub BGP Ranking tools: CIRCL / bgp-ranging example (last updated on May 16th, 2011, tho an RT lookup via the CIRCL tool does shows the appropriate redirect/org) -Several routing oriented books and Cisco examples list such range, for example, FR/ISBN 2-212-09238-5. -And even established ISPs, that are publically announcing their "block list ", such as Albury's Local ISP in Australia The simple answer is to point IT directors, IP engineers or "the receptionists that manages the network" to the appropriate registry data-source, which should convince them that corrective action is necessary, i.e. fix your routing table or firewall. The complexity begins in trying to locate all of these people and directing them to the appropriate data-source, which I think is an unrealistic task, even for the largest of operators. Maybe a nanog-edge group is in order. If the issue was beyond just a nuisance and If I were in your shoes, i'd renumber or use an alternate range for the types of traffic affected by such blocks, i.e. administrative web traffic trying to reach major insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 address, over about 43 ranges with only some potentially affected) Realizing that renumbering is also extremely unrealistic, if you haven't already reached the IPv6 bandwagon, that's an option or, if none of the above seem reasonable, you could always put together a one-page PDF that points these administrators to the appropriate resource to validate that you, are in fact, part of the domestic United States. I agree that a more accurate tool probably needs to be created for the "general population to consume," but then again, even that solution, is "just another tool" for the search-engines to index, and you're back at square one. As much as I think most of us would like to help fix this issue, I don't know that a decent, non-invasive solution exists, at least based upon the few hours we threw at this issue today... On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch wrote: > Spurling, Shannon wrote: > > > It?s a problem with the miss-use of the RIR delegation of a legacy > > block. > > > > The assumption that because a block is assigned to a particular RIR, all > > users in that block have to be in that RIR?s territory, without actually > > running a query against that RIR?s Whois database. > > Actually, a simple whois query often isn't enough to solve this problem. > Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that > are registered in other RIRs. ARIN, however, does. > > (However, if the geoip people are using whois data, I can't believe they > aren't handling cases like this properly, because it's blatantly obvious > if you scan IPv4 address space for referrals.) > > > If you use FreeBSD-CURRENT's whois client, it tries to work mostly by > following referrals, rather than using a built-in database mapping query > strings to whois servers. If you query for 150.199.0.0 (for example) you > get the following (which I have brutally trimmed for length): > > % IANA WHOIS server > > refer: whois.apnic.net > > inetnum: 150.0.0.0 - 150.255.255.255 > organisation: Administered by APNIC > status: LEGACY > > % [whois.apnic.net] > > inetnum: 150.0.0.0 - 150.255.255.255 > netname: ERX-NETBLOCK > descr: Early registration addresses > > remarks: Address ranges from this historical space have now > remarks: been transferred to the appropriate RIR database.remarks: > remarks: If your search has returned this record, it means the > remarks: address range is not administered by APNIC. > remarks: > remarks: Instead, please search one of the following databases: > > (It then unhelpfully lists all the other RIRs.) > > FreeBSD's whois client spots this failure then retries the query at ARIN. > > > There's a similar problem with RIPE, for instance if you query for > 141.211.0.0: > > % IANA WHOIS server > > refer: whois.ripe.net > > inetnum: 141.0.0.0 - 141.255.255.255 > organisation: Administered by RIPE NCC > status: LEGACY > > % This is the RIPE Database query service. > > inetnum: 141.209.0.0 - 141.225.255.255 > netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK > descr: IPv4 address block not managed by the RIPE NCC > > remarks: You can find the whois server to query, or the > remarks: IANA registry to query on this web page: > remarks: http://www.iana.org/assignments/ipv4-address-space > remarks: > remarks: You can access databases of other RIRs at: > > (It then unhelpfully lists all the other RIRs.) > > Actually RIPE is even worse than APNIC because it implicitly has a > referral loop between IANA and RIPE. > > > BUT NOTE! > > The APNIC and RIPE databases do in fact contain the referral information - > you can get it via RDAP but not whois. Repeating the examples, > > $ curl -i https://rdap.apnic.net/ip/150.199.0.0 > HTTP/1.1 301 Moved Permanently > Location: https://rdap.arin.net/registry/ip/150.199.0.0 > > $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 > HTTP/1.1 301 Moved Permanently > Location: https://rdap.arin.net/registry/ip/141.211.0.0 > > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > punycode > Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, > thundery showers. Moderate, occasionally very poor. > -- From tomas at okmanas.lt Wed Jun 22 05:52:34 2016 From: tomas at okmanas.lt (Tom Okman) Date: Wed, 22 Jun 2016 08:52:34 +0300 Subject: Google Geolocation issue In-Reply-To: <1466533507.2680.14.camel@beagle> References: <1466533507.2680.14.camel@beagle> Message-ID: I see your maxmind DB points to a right location as well as traceroute goes to Austin. Are you a member of their peering project? What you can see there? Anyway, I still think that there are guys from google here that can be a better help than me :) Good luck. Tom 2016-06-21 21:25 GMT+03:00 Chris Boyd : > Dear list readers, please forgive the noise, but if there's anyone here > from Google who can fix a geolocation issue I'd appreciate a reply. > > 208.81.245.226 is not in the UAE, it's in Austin, Texas. Yes, I have > filled out the form to request a fix, but the AI or whatever that's > supposed to fix it has not, and we're well into 3 months after the first > report. > > Thanks, > > --Chris > > -- Tomas Okmanas From mohta at necom830.hpcl.titech.ac.jp Wed Jun 22 22:23:30 2016 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 23 Jun 2016 07:23:30 +0900 Subject: IP and Optical domains? In-Reply-To: <4e8a44d8-1a8e-1f34-76af-bf581153751d@seacom.mu> References: <8bb886df-6365-9402-ff72-20d0df46bbd1@necom830.hpcl.titech.ac.jp> <01b8eae3-3be0-8ddc-873b-c4c62123d100@necom830.hpcl.titech.ac.jp> <16502d38-5ba9-4608-103d-be1667fcf5d4@seacom.mu> <425b7e37-df36-426d-f5aa-9ee50e9648d3@necom830.hpcl.titech.ac.jp> <52ae3495-4838-cba0-15b0-568950052ced@necom830.hpcl.titech.ac.jp> <4e8a44d8-1a8e-1f34-76af-bf581153751d@seacom.mu> Message-ID: Mark Tinka wrote: >> I think you mean IPoDWDM something so much different from >> usual ways to have IP over something. >> >> Do you have any reference to it? > > I said "visbility" due to what IPoDWDM can offer. > > But I also said IP has no real "awareness" about the physical > infrastructure. It just knows it can't send/receive packets anymore. > > With IPoDWDM, one could infer that the IP layer will quickly re-route > due to DWDM characteristics (related to fibre conditions). Wrong. There is no room for such reroute with IP just over DWDM. You are saying something IP over sublayer1 over sublayer2 over sublayer3 over sublayer4 over sublayer5 over DWDM IPoDWDM. Of course, each sublayer has additional inefficiency and obscurity. That you call it IPoDWDM means that you accept the obscurities and though you think IPoDWDM 60% efficient, it is actually that IP over sulayer1 is 60% efficient and if efficiencies between other layers are 60%, actual efficiency of IPoDWDM is 4.7%, which is "heavily underutilized". > However, in > actual fact, what IP really sees is the link going away, and thus, > triggering an IGP reconvergence. And, with properly designed IGP, that's fine. > There is no difference if IP is running directly over fibre (in > Ethernet). Ethernet is already too complex to be "directly over fiber". Point to point Ethernet may barely be. > The difference with IPoDWDM Never call something a lot more complicated than Ethernet between IP and DWDM IPoDWDM. Masataka Ohta From LudendorffR at rferl.org Wed Jun 22 08:27:27 2016 From: LudendorffR at rferl.org (Ray Ludendorff) Date: Wed, 22 Jun 2016 08:27:27 +0000 Subject: Cisco 2 factor authentication Message-ID: Has anyone setup two factor VPN using a Cisco ASA VPN solution? What sort of soft client based dual factor authentication options were used for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, RSA, etc.) I am trying to find what infrastructure is needed to come up with the solution. Please contact me of list Regards Ray Ludendorff From dcharlebois at gmail.com Wed Jun 22 20:04:31 2016 From: dcharlebois at gmail.com (David Charlebois) Date: Wed, 22 Jun 2016 16:04:31 -0400 Subject: 1GE L3 aggregation In-Reply-To: <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> Message-ID: Hello I'm curious about the overall recommendation when selecting a small class BGP router for IPv6 (with 1gig ports). We can see the current IPv4 routing table is around 615k routes and the IPv6 routing table is sitting around ~31k routes. In our case, we advertise a single /24 from our head office to 2 upstream providers. The routing is %100 for redundancy. Somebody mentioned that the Brocade CER-RT was once a best seller. Brocade are now offering the CER 4X-RT version at 256K IPv6 routes supported (1.5M IPv4 routes). We don't have immediate plans for IPv6, but I do foresee this in a few year. Question is - is 256k IPv6 routes suitable? Thanks Dave From bedard.phil at gmail.com Thu Jun 23 03:40:43 2016 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 22 Jun 2016 23:40:43 -0400 Subject: IP and Optical domains? In-Reply-To: References: Message-ID: We have a single IP and optical group, but that?s not common at most larger carriers. We have a fairly complex national dark fiber backbone as well as complicated metro networks. You see a lot of vendors tout IP/optical integration around optimization of resources, but the starting point is usually a carrier who provisions both L3 protection and L1 circuit protection at the same time. It?s obvious to most that isn?t efficient, but there are carriers out there who do that because the groups are so disjoint. I would say that does not represent the majority of carriers today however. Optical vendors will tout optical restoration as a means to reduce excess L3 capacity and they are right, with modern CDC ROADMs and coherent optics you can plan a network around optical restoration and gain a lot of cost reduction by reducing L3 capacity. The tradeoff is in restoration times, as the photonic layer can?t restore very fast right now, so there is a middle ground for most networks of carrying either fully protected capacity at L3 or L1, and restoring other capacity dynamically. Typically for a subset of traffic like high priority traffic. I read the bulk of this thread and IPoDWDM is interesting from a collapsing of boxes perspective if the network is simple enough it?s easy to operate and it makes financial sense. All the major router vendors are being forced by content providers to integrate them into their boxes. At OFC MS announced they had been working with InPhi to develop a shorter reach (80km) tunable QSFP28. If it does not need to integrate into an optical control plane (like one doing optical restoration) then it?s a very valid solution and I think you?ll continue to see growth with it. I call SDN the get out of jail free card for optical vendors because they no longer have to even pretend they will interoperate via standard protocols like GMPLS. They expose REST APIs and people are willing to take it because it?s fairly easy to deal with. Phil -----Original Message----- From: NANOG on behalf of Glen Kent Date: Saturday, June 18, 2016 at 17:27 To: "nanog at nanog.org" Subject: IP and Optical domains? HI, I was reading the following article: http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616 It says that "The IP layer and optical layer are run like two separate kingdoms," Wellingstein says. "Two separate kings manage the IP and optical networks. There is barely any resource alignment between them. The result of this is that the networks are heavily underutilized," or, from an alternative perspective, "they are heavily over-provisioned." Can somebody shed more light on what it means to say that the IP and optical layers are run as independent kingdoms and why do ISPs need to over-provision? Thanks, Glen From mark.tinka at seacom.mu Thu Jun 23 05:54:24 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 23 Jun 2016 07:54:24 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> Message-ID: On 22/Jun/16 22:04, David Charlebois wrote: > Hello > I'm curious about the overall recommendation when selecting a small class > BGP router for IPv6 (with 1gig ports). We can see the current IPv4 routing > table is around 615k routes and the IPv6 routing table is sitting around > ~31k routes. > > In our case, we advertise a single /24 from our head office to 2 upstream > providers. The routing is %100 for redundancy. > > Somebody mentioned that the Brocade CER-RT was once a best seller. Brocade > are now offering the CER 4X-RT version at 256K IPv6 routes supported (1.5M > IPv4 routes). We don't have immediate plans for IPv6, but I do foresee this > in a few year. Question is - is 256k IPv6 routes suitable? The CER/CES NetIron boxes from Brocade are reasonable. That said, BGP-SD implementations apply both to IPv4 and IPv6. So in a Metro-E Access deployment scenario, the number of IPv6 routes would not matter, as we only download into FIB the minimum necessary to keep the box alive. Mark. From owen at delong.com Thu Jun 23 06:07:10 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Jun 2016 23:07:10 -0700 Subject: 1GE L3 aggregation In-Reply-To: References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> Message-ID: <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> If it?s 100% for redundancy, why not just ECMP defaults and not take a full table? That will allow you to use a MUCH cheaper router with a much simpler configuration. Owen > On Jun 22, 2016, at 13:04 , David Charlebois wrote: > > Hello > I'm curious about the overall recommendation when selecting a small class > BGP router for IPv6 (with 1gig ports). We can see the current IPv4 routing > table is around 615k routes and the IPv6 routing table is sitting around > ~31k routes. > > In our case, we advertise a single /24 from our head office to 2 upstream > providers. The routing is %100 for redundancy. > > Somebody mentioned that the Brocade CER-RT was once a best seller. Brocade > are now offering the CER 4X-RT version at 256K IPv6 routes supported (1.5M > IPv4 routes). We don't have immediate plans for IPv6, but I do foresee this > in a few year. Question is - is 256k IPv6 routes suitable? > > Thanks > Dave From mark.tinka at seacom.mu Thu Jun 23 06:17:31 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 23 Jun 2016 08:17:31 +0200 Subject: 1GE L3 aggregation In-Reply-To: <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> Message-ID: On 23/Jun/16 08:07, Owen DeLong wrote: > If it?s 100% for redundancy, why not just ECMP defaults and not take a full table? Well, firstly, ring length may be different on either end. So you can't always guarantee ECMP of traffic to/from the device (without much difficulty such as MPLS-TE). You also can't do hop-by-hop routing based on 0/0 or ::/0 when the ring contains multiple devices also doing the same thing. You'll just create a loop. MPLS-based forwarding is your friend here. But yes, if your device is not in a ring, then your suggestion is fine. Mark. From owen at delong.com Thu Jun 23 06:22:19 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Jun 2016 23:22:19 -0700 Subject: 1GE L3 aggregation In-Reply-To: References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> Message-ID: <05945B43-C4D5-435E-ABB3-CCAA6BEB8DE6@delong.com> > On Jun 22, 2016, at 23:17 , Mark Tinka wrote: > > > > On 23/Jun/16 08:07, Owen DeLong wrote: > >> If it?s 100% for redundancy, why not just ECMP defaults and not take a full table? > > Well, firstly, ring length may be different on either end. So you can't > always guarantee ECMP of traffic to/from the device (without much > difficulty such as MPLS-TE). Unless the difference is HUGE, you usually don?t really care. > You also can't do hop-by-hop routing based on 0/0 or ::/0 when the ring > contains multiple devices also doing the same thing. You'll just create > a loop. MPLS-based forwarding is your friend here. Who said anything about a ring. He is advertising a /24 to 2 upstream providers. Likely these are two separate transit circuits. > But yes, if your device is not in a ring, then your suggestion is fine. Even if you?re in a ring if you?ve got two transit providers at some random point on the ring, it still probably doesn?t make a meaningful difference between full feeds from each vs. ECMP, because it?s pretty unlikely that the AS PATH length is affected by the ring length. Owen From mark.tinka at seacom.mu Thu Jun 23 06:32:41 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 23 Jun 2016 08:32:41 +0200 Subject: 1GE L3 aggregation In-Reply-To: <05945B43-C4D5-435E-ABB3-CCAA6BEB8DE6@delong.com> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> <05945B43-C4D5-435E-ABB3-CCAA6BEB8DE6@delong.com> Message-ID: <99747e5c-c07f-cfc2-e759-9a4f6767ef50@seacom.mu> On 23/Jun/16 08:22, Owen DeLong wrote: > Unless the difference is HUGE, you usually don?t really care. Agree. We are in that scenario, and mostly don't care as well. There is enough link capacity > Who said anything about a ring. He is advertising a /24 to 2 upstream providers. Which is what I said at the end of my reply to you. The ring angle came up as part of a wider discussion earlier in this thread, where protecting the FIB makes sense. > Even if you?re in a ring if you?ve got two transit providers at some random point on the ring, it still probably doesn?t make a meaningful difference between full feeds from each vs. ECMP, because it?s pretty unlikely that the AS PATH length is affected by the ring length. In my experience, rings are normally on-net backbones (Metro-E, e.t.c.). The terminating devices on the core side at each end of the ring will be your own equipment, and not another AS. Two links to your upstream won't matter whether it's in a ring or just plain point-to-point circuits, as there is no IGP relevance on such tails. Mark. From owen at delong.com Thu Jun 23 06:43:15 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Jun 2016 23:43:15 -0700 Subject: 1GE L3 aggregation In-Reply-To: <99747e5c-c07f-cfc2-e759-9a4f6767ef50@seacom.mu> References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> <536F8E9D-7E3B-429F-8FD1-2D9F66299E54@delong.com> <05945B43-C4D5-435E-ABB3-CCAA6BEB8DE6@delong.com> <99747e5c-c07f-cfc2-e759-9a4f6767ef50@seacom.mu> Message-ID: <687BFFEC-ED9D-4DA2-9E8F-4D451CD4EFDC@delong.com> > On Jun 22, 2016, at 23:32 , Mark Tinka wrote: > > > > On 23/Jun/16 08:22, Owen DeLong wrote: > >> Unless the difference is HUGE, you usually don?t really care. > > Agree. > > We are in that scenario, and mostly don't care as well. There is enough > link capacity > > >> Who said anything about a ring. He is advertising a /24 to 2 upstream providers. > > Which is what I said at the end of my reply to you. > > The ring angle came up as part of a wider discussion earlier in this > thread, where protecting the FIB makes sense. > > >> Even if you?re in a ring if you?ve got two transit providers at some random point on the ring, it still probably doesn?t make a meaningful difference between full feeds from each vs. ECMP, because it?s pretty unlikely that the AS PATH length is affected by the ring length. > > In my experience, rings are normally on-net backbones (Metro-E, e.t.c.). > The terminating devices on the core side at each end of the ring will be > your own equipment, and not another AS. > > Two links to your upstream won't matter whether it's in a ring or just > plain point-to-point circuits, as there is no IGP relevance on such tails. > > Mark. > Hence my confusion about your ring comments in the context of the message I was replying to. Owen From baldur.norddahl at gmail.com Thu Jun 23 08:32:54 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 23 Jun 2016 10:32:54 +0200 Subject: 1GE L3 aggregation In-Reply-To: References: <181df101-58e3-90e2-860e-0c2c3c85ae7a@seacom.mu> <5767F886.6020201@gmail.com> <67f9874e-3194-fad2-e39b-af9c67aa875f@seacom.mu> Message-ID: On 22 June 2016 at 22:04, David Charlebois wrote: > In our case, we advertise a single /24 from our head office to 2 upstream > providers. The routing is %100 for redundancy. > The full table is in many cases overrated. If both your transits are good service providers, you do not gain much by trying to get even better routing compared to what the single homed customers of each provider is getting. And that is basically what you are trying by taking in full tables. The only thing to be beware of is some so called Tier 1 providers that have bad interconnectivity to other Tier 1 providers. For example, neither Cogent nor HE will give you a full view of the IPv6 network because these two guys are in a peering war, so they miss the routes from the other network. Taking in full tables allows you to select the correct provider for the (relatively few) trouble routes, but note that you will still have a problem if one link is down. The fix is to use smaller regional transit providers, with each provider having multiple transits of his own. For a feed with default route you can use the most basic BGP speaking switch. Those are available for 1k USD or less. The ZTE switches we use are in that range with copper ports and no 10G. Or you can get a Mikrotik RB2011 for $99. Or you can keep the full feed and use a Linux/BSD server for routing with BIRD og Quagga. At 1G speed a server is going to do the job trivially. If you want to be advanced, get two servers, one for each transit. Redundancy on the LAN side can be provided by VRRP. Regards, Baldur From rps at maine.edu Thu Jun 23 15:09:59 2016 From: rps at maine.edu (Ray Soucy) Date: Thu, 23 Jun 2016 11:09:59 -0400 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: Regardless of whether or not people "should" do this, I think the horse has already left the barn on this one. I don't see any way of getting people who decided to filter all of APNIC to make changes. Most of them are static configurations that they'll never look to update. On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn wrote: > The following might add some clarity, depending upon how you look at it: > > We, as "core" engineers know better than to use some of the sources listed > below, tho, my suspicion is that when an engineer or local IT person, on an > edge network starts to see various types of attacks, they play wack-a-mole, > based upon outdated or incomplete data, and never think twice about > revisiting such, as, from their perspective, everything is working just > fine. > > In a networking psychology test, earlier this morning, I wrote to ten > well-known colleagues that I was fairly confident didn't regularly follow > the nanog lists. Such individuals comprised of IP and IT engineers for > which manage various network sizes and enterprises, ultimately posing the > question of "Where in the world is 150.201.15.7, as we were researching > some unique traffic patterns". > > *Seven out of ten came back with overseas*. Two came back with more > questions "as the address space appeared to be assigned to APNIC", but was > routed domestically. > > *One came back with the correct response.* (MORENET) > > Two of the queried parties were representative of major networks, one for > an entire state governmental network with hundreds of thousands of actual > users and tens of thousands of routers, the other from another major > university. (Names left out, in the event they see this message later in > the day or week) > > After probing the origin of their responses, I found the following methods > or data-sources were used: > > -Search Engines - by far, the worst offender. Not necessarily "the engines" > at fault, but a result of indexed sites containing inaccurate or outdated > CIDR lists. > -User generated forums, such as "Block non-North American Traffic for > Dummies Like Me > " > (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. > Member) > -Static (or aged) CIDR web-page based lists, usually placed for advertorial > generation purposes and rarely up to date or accurate. (usually via SE's or > forum referrals) > -APNIC themselves - A basic SE search resulted in an APNIC page > < > https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges > > > that, > on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the > current APNIC range. > -GitHub BGP Ranking tools: CIRCL / bgp-ranging example > > (last > updated on May 16th, 2011, tho an RT lookup > via the CIRCL tool > does shows the appropriate redirect/org) > -Several routing oriented books and Cisco examples > < > http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf > > > list > such range, for example, FR/ISBN 2-212-09238-5. > -And even established ISPs, that are publically announcing their "block > list > ", such as Albury's > Local > ISP in Australia > > The simple answer is to point IT directors, IP engineers or "the > receptionists that manages the network" to the appropriate registry > data-source, which should convince them that corrective action is > necessary, i.e. fix your routing table or firewall. The complexity begins > in trying to locate all of these people and directing them to the > appropriate data-source, which I think is an unrealistic task, even for the > largest of operators. Maybe a nanog-edge group is in order. > > If the issue was beyond just a nuisance and If I were in your shoes, i'd > renumber or use an alternate range for the types of traffic affected by > such blocks, i.e. administrative web traffic trying to reach major > insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 > address, over about 43 ranges with only some potentially affected) > > Realizing that renumbering is also extremely unrealistic, if you haven't > already reached the IPv6 bandwagon, that's an option or, if none of the > above seem reasonable, you could always put together a one-page PDF that > points these administrators to the appropriate resource to validate that > you, are in fact, part of the domestic United States. > > I agree that a more accurate tool probably needs to be created for the > "general population to consume," but then again, even that solution, is > "just another tool" for the search-engines to index, and you're back at > square one. > > As much as I think most of us would like to help fix this issue, I don't > know that a decent, non-invasive solution exists, at least based upon the > few hours we threw at this issue today... > > On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch wrote: > > > Spurling, Shannon wrote: > > > > > It?s a problem with the miss-use of the RIR delegation of a legacy > > > block. > > > > > > The assumption that because a block is assigned to a particular RIR, > all > > > users in that block have to be in that RIR?s territory, without > actually > > > running a query against that RIR?s Whois database. > > > > Actually, a simple whois query often isn't enough to solve this problem. > > Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that > > are registered in other RIRs. ARIN, however, does. > > > > (However, if the geoip people are using whois data, I can't believe they > > aren't handling cases like this properly, because it's blatantly obvious > > if you scan IPv4 address space for referrals.) > > > > > > If you use FreeBSD-CURRENT's whois client, it tries to work mostly by > > following referrals, rather than using a built-in database mapping query > > strings to whois servers. If you query for 150.199.0.0 (for example) you > > get the following (which I have brutally trimmed for length): > > > > % IANA WHOIS server > > > > refer: whois.apnic.net > > > > inetnum: 150.0.0.0 - 150.255.255.255 > > organisation: Administered by APNIC > > status: LEGACY > > > > % [whois.apnic.net] > > > > inetnum: 150.0.0.0 - 150.255.255.255 > > netname: ERX-NETBLOCK > > descr: Early registration addresses > > > > remarks: Address ranges from this historical space have now > > remarks: been transferred to the appropriate RIR database.remarks: > > remarks: If your search has returned this record, it means the > > remarks: address range is not administered by APNIC. > > remarks: > > remarks: Instead, please search one of the following databases: > > > > (It then unhelpfully lists all the other RIRs.) > > > > FreeBSD's whois client spots this failure then retries the query at ARIN. > > > > > > There's a similar problem with RIPE, for instance if you query for > > 141.211.0.0: > > > > % IANA WHOIS server > > > > refer: whois.ripe.net > > > > inetnum: 141.0.0.0 - 141.255.255.255 > > organisation: Administered by RIPE NCC > > status: LEGACY > > > > % This is the RIPE Database query service. > > > > inetnum: 141.209.0.0 - 141.225.255.255 > > netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK > > descr: IPv4 address block not managed by the RIPE NCC > > > > remarks: You can find the whois server to query, or the > > remarks: IANA registry to query on this web page: > > remarks: http://www.iana.org/assignments/ipv4-address-space > > remarks: > > remarks: You can access databases of other RIRs at: > > > > (It then unhelpfully lists all the other RIRs.) > > > > Actually RIPE is even worse than APNIC because it implicitly has a > > referral loop between IANA and RIPE. > > > > > > BUT NOTE! > > > > The APNIC and RIPE databases do in fact contain the referral information > - > > you can get it via RDAP but not whois. Repeating the examples, > > > > $ curl -i https://rdap.apnic.net/ip/150.199.0.0 > > HTTP/1.1 301 Moved Permanently > > Location: https://rdap.arin.net/registry/ip/150.199.0.0 > > > > $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 > > HTTP/1.1 301 Moved Permanently > > Location: https://rdap.arin.net/registry/ip/141.211.0.0 > > > > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > > punycode > > Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog > patches, > > thundery showers. Moderate, occasionally very poor. > > > > > > -- > -- Ray Patrick Soucy Senior Cyber Security Engineer Networkmaine, University of Maine System US:IT 207-561-3526 From copraphage at gmail.com Thu Jun 23 15:22:30 2016 From: copraphage at gmail.com (Chris McDonald) Date: Thu, 23 Jun 2016 16:22:30 +0100 Subject: 60 hudson - insurance? Message-ID: are others being told that their remote hands / installers , etc now need to show proof of insurance? thanks From tom.smyth at wirelessconnect.eu Thu Jun 23 15:23:39 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Thu, 23 Jun 2016 16:23:39 +0100 Subject: IPv4 Legacy assignment frustration In-Reply-To: References: <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com> Message-ID: Hi Ray, Kraig I think people affected just have to try to put pressure on their isps in the path between the afffected ips and hope for the best... public pressure is probably the only way to get around what I think most of us would agree is a terrible practice... I really hope that we can get rid of this practice as the last crumbs of IPv4 are carved up and re-distributed amongst new and growing isps. perhaps a name and shame project to highlight those isps that block ip ranges constantly and indiscriminately, needless to say the impact such practice has on peoples freedom to communicate, Thanks Tom Smyth On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy wrote: > Regardless of whether or not people "should" do this, I think the horse has > already left the barn on this one. I don't see any way of getting people > who decided to filter all of APNIC to make changes. Most of them are > static configurations that they'll never look to update. > > On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn wrote: > > > The following might add some clarity, depending upon how you look at it: > > > > We, as "core" engineers know better than to use some of the sources > listed > > below, tho, my suspicion is that when an engineer or local IT person, on > an > > edge network starts to see various types of attacks, they play > wack-a-mole, > > based upon outdated or incomplete data, and never think twice about > > revisiting such, as, from their perspective, everything is working just > > fine. > > > > In a networking psychology test, earlier this morning, I wrote to ten > > well-known colleagues that I was fairly confident didn't regularly follow > > the nanog lists. Such individuals comprised of IP and IT engineers for > > which manage various network sizes and enterprises, ultimately posing the > > question of "Where in the world is 150.201.15.7, as we were researching > > some unique traffic patterns". > > > > *Seven out of ten came back with overseas*. Two came back with more > > questions "as the address space appeared to be assigned to APNIC", but > was > > routed domestically. > > > > *One came back with the correct response.* (MORENET) > > > > Two of the queried parties were representative of major networks, one for > > an entire state governmental network with hundreds of thousands of actual > > users and tens of thousands of routers, the other from another major > > university. (Names left out, in the event they see this message later in > > the day or week) > > > > After probing the origin of their responses, I found the following > methods > > or data-sources were used: > > > > -Search Engines - by far, the worst offender. Not necessarily "the > engines" > > at fault, but a result of indexed sites containing inaccurate or outdated > > CIDR lists. > > -User generated forums, such as "Block non-North American Traffic for > > Dummies Like Me > > " > > (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. > > Member) > > -Static (or aged) CIDR web-page based lists, usually placed for > advertorial > > generation purposes and rarely up to date or accurate. (usually via SE's > or > > forum referrals) > > -APNIC themselves - A basic SE search resulted in an APNIC page > > < > > > https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges > > > > > that, > > on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the > > current APNIC range. > > -GitHub BGP Ranking tools: CIRCL / bgp-ranging example > > < > https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> > > (last > > updated on May 16th, 2011, tho an RT lookup > > via the CIRCL > tool > > does shows the appropriate redirect/org) > > -Several routing oriented books and Cisco examples > > < > > > http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf > > > > > list > > such range, for example, FR/ISBN 2-212-09238-5. > > -And even established ISPs, that are publically announcing their "block > > list > > ", such as Albury's > > Local > > ISP in Australia > > > > The simple answer is to point IT directors, IP engineers or "the > > receptionists that manages the network" to the appropriate registry > > data-source, which should convince them that corrective action is > > necessary, i.e. fix your routing table or firewall. The complexity begins > > in trying to locate all of these people and directing them to the > > appropriate data-source, which I think is an unrealistic task, even for > the > > largest of operators. Maybe a nanog-edge group is in order. > > > > If the issue was beyond just a nuisance and If I were in your shoes, i'd > > renumber or use an alternate range for the types of traffic affected by > > such blocks, i.e. administrative web traffic trying to reach major > > insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 > > address, over about 43 ranges with only some potentially affected) > > > > Realizing that renumbering is also extremely unrealistic, if you haven't > > already reached the IPv6 bandwagon, that's an option or, if none of the > > above seem reasonable, you could always put together a one-page PDF that > > points these administrators to the appropriate resource to validate that > > you, are in fact, part of the domestic United States. > > > > I agree that a more accurate tool probably needs to be created for the > > "general population to consume," but then again, even that solution, is > > "just another tool" for the search-engines to index, and you're back at > > square one. > > > > As much as I think most of us would like to help fix this issue, I don't > > know that a decent, non-invasive solution exists, at least based upon the > > few hours we threw at this issue today... > > > > On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch wrote: > > > > > Spurling, Shannon wrote: > > > > > > > It?s a problem with the miss-use of the RIR delegation of a legacy > > > > block. > > > > > > > > The assumption that because a block is assigned to a particular RIR, > > all > > > > users in that block have to be in that RIR?s territory, without > > actually > > > > running a query against that RIR?s Whois database. > > > > > > Actually, a simple whois query often isn't enough to solve this > problem. > > > Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses > that > > > are registered in other RIRs. ARIN, however, does. > > > > > > (However, if the geoip people are using whois data, I can't believe > they > > > aren't handling cases like this properly, because it's blatantly > obvious > > > if you scan IPv4 address space for referrals.) > > > > > > > > > If you use FreeBSD-CURRENT's whois client, it tries to work mostly by > > > following referrals, rather than using a built-in database mapping > query > > > strings to whois servers. If you query for 150.199.0.0 (for example) > you > > > get the following (which I have brutally trimmed for length): > > > > > > % IANA WHOIS server > > > > > > refer: whois.apnic.net > > > > > > inetnum: 150.0.0.0 - 150.255.255.255 > > > organisation: Administered by APNIC > > > status: LEGACY > > > > > > % [whois.apnic.net] > > > > > > inetnum: 150.0.0.0 - 150.255.255.255 > > > netname: ERX-NETBLOCK > > > descr: Early registration addresses > > > > > > remarks: Address ranges from this historical space have now > > > remarks: been transferred to the appropriate RIR > database.remarks: > > > remarks: If your search has returned this record, it means the > > > remarks: address range is not administered by APNIC. > > > remarks: > > > remarks: Instead, please search one of the following databases: > > > > > > (It then unhelpfully lists all the other RIRs.) > > > > > > FreeBSD's whois client spots this failure then retries the query at > ARIN. > > > > > > > > > There's a similar problem with RIPE, for instance if you query for > > > 141.211.0.0: > > > > > > % IANA WHOIS server > > > > > > refer: whois.ripe.net > > > > > > inetnum: 141.0.0.0 - 141.255.255.255 > > > organisation: Administered by RIPE NCC > > > status: LEGACY > > > > > > % This is the RIPE Database query service. > > > > > > inetnum: 141.209.0.0 - 141.225.255.255 > > > netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK > > > descr: IPv4 address block not managed by the RIPE NCC > > > > > > remarks: You can find the whois server to query, or the > > > remarks: IANA registry to query on this web page: > > > remarks: http://www.iana.org/assignments/ipv4-address-space > > > remarks: > > > remarks: You can access databases of other RIRs at: > > > > > > (It then unhelpfully lists all the other RIRs.) > > > > > > Actually RIPE is even worse than APNIC because it implicitly has a > > > referral loop between IANA and RIPE. > > > > > > > > > BUT NOTE! > > > > > > The APNIC and RIPE databases do in fact contain the referral > information > > - > > > you can get it via RDAP but not whois. Repeating the examples, > > > > > > $ curl -i https://rdap.apnic.net/ip/150.199.0.0 > > > HTTP/1.1 301 Moved Permanently > > > Location: https://rdap.arin.net/registry/ip/150.199.0.0 > > > > > > $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 > > > HTTP/1.1 301 Moved Permanently > > > Location: https://rdap.arin.net/registry/ip/141.211.0.0 > > > > > > > > > Tony. > > > -- > > > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > > > punycode > > > Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog > > patches, > > > thundery showers. Moderate, occasionally very poor. > > > > > > > > > > > -- > > > > > > -- > Ray Patrick Soucy > Senior Cyber Security Engineer > Networkmaine, University of Maine System US:IT > > 207-561-3526 > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. From dovid at telecurve.com Thu Jun 23 15:52:40 2016 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 23 Jun 2016 15:52:40 +0000 Subject: 60 hudson - insurance? In-Reply-To: References: Message-ID: <1655955953-1466697160-cardhu_decombobulator_blackberry.rim.net-429972041-@b12.c1.bise6.blackberry> Chris, We were told this a long time ago. You can always just say they work for you ;) Regards, Dovid -----Original Message----- From: Chris McDonald Sender: "NANOG" Date: Thu, 23 Jun 2016 16:22:30 To: nanog list Subject: 60 hudson - insurance? are others being told that their remote hands / installers , etc now need to show proof of insurance? thanks From jmilko at gmail.com Thu Jun 23 16:24:30 2016 From: jmilko at gmail.com (James Milko) Date: Thu, 23 Jun 2016 12:24:30 -0400 Subject: 60 hudson - insurance? In-Reply-To: <1655955953-1466697160-cardhu_decombobulator_blackberry.rim.net-429972041-@b12.c1.bise6.blackberry> References: <1655955953-1466697160-cardhu_decombobulator_blackberry.rim.net-429972041-@b12.c1.bise6.blackberry> Message-ID: We got this from them a few years ago. Same story to pull up the dock as well. On Thu, Jun 23, 2016 at 11:52 AM, Dovid Bender wrote: > Chris, > > We were told this a long time ago. You can always just say they work for > you ;) > > > Regards, > > Dovid > > -----Original Message----- > From: Chris McDonald > Sender: "NANOG" Date: Thu, 23 Jun 2016 16:22:30 > To: nanog list > Subject: 60 hudson - insurance? > > are others being told that their remote hands / installers , etc now need > to show proof of insurance? > > thanks > From theodore at ciscodude.net Thu Jun 23 16:42:02 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 23 Jun 2016 11:42:02 -0500 Subject: Looking for a Level 3 Routing Registry contact In-Reply-To: <398B250423578A4E97AFE1B8B67C686C4C3DC969@PDDCWMBXEX503.ctl.intranet> References: <398B250423578A4E97AFE1B8B67C686C4C3DC969@PDDCWMBXEX503.ctl.intranet> Message-ID: Curious if you had any luck with this task, I've tried via several avenues and had very little luck getting old cruft removed. :-( Theodore On Fri, Jun 17, 2016 at 4:16 PM, Delacruz, Anthony B < Anthony.DeLaCruz at centurylink.com> wrote: > Please contact me off list if you can help me get in touch with an actual > person that can clear out old entries in the Level 3 routing registry. I > can't do jack with the automated and the contacts that put them in are non > responsive for clearing out their years old mess. Thanks. > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > From fred at web2objects.com Thu Jun 23 16:55:26 2016 From: fred at web2objects.com (Fred Hollis) Date: Thu, 23 Jun 2016 18:55:26 +0200 Subject: Looking for a Level 3 Routing Registry contact In-Reply-To: References: <398B250423578A4E97AFE1B8B67C686C4C3DC969@PDDCWMBXEX503.ctl.intranet> Message-ID: same... On 23.06.2016 at 18:42 Theodore Baschak wrote: > Curious if you had any luck with this task, I've tried via several avenues > and had very little luck getting old cruft removed. :-( > > Theodore > > > On Fri, Jun 17, 2016 at 4:16 PM, Delacruz, Anthony B < > Anthony.DeLaCruz at centurylink.com> wrote: > >> Please contact me off list if you can help me get in touch with an actual >> person that can clear out old entries in the Level 3 routing registry. I >> can't do jack with the automated and the contacts that put them in are non >> responsive for clearing out their years old mess. Thanks. >> >> This communication is the property of CenturyLink and may contain >> confidential or privileged information. Unauthorized use of this >> communication is strictly prohibited and may be unlawful. If you have >> received this communication in error, please immediately notify the sender >> by reply e-mail and destroy all copies of the communication and any >> attachments. >> From clawrence at dovefire.co.uk Thu Jun 23 02:38:05 2016 From: clawrence at dovefire.co.uk (Chris Lawrence) Date: Thu, 23 Jun 2016 02:38:05 +0000 Subject: Cisco 2 factor authentication In-Reply-To: References: Message-ID: <62B62BB0-17F5-41C5-8689-9D98D838FBF8@dovefire.co.uk> Any radius based auth works well I've used a solution by secure envoy I the past which seems to work well they also have soft token apps, hard tokens plus SMS based. Sent from my iPhone > On 23 Jun 2016, at 01:51, Ray Ludendorff wrote: > > Has anyone setup two factor VPN using a Cisco ASA VPN solution? > What sort of soft client based dual factor authentication options were used for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, RSA, etc.) > I am trying to find what infrastructure is needed to come up with the solution. > > Please contact me of list > > Regards > Ray Ludendorff > > > DISCLAIMER: The information contained in this communication from clawrence at dovefire.co.uk is confidential and may be legally privileged. It is intended solely for use by the recipient and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. WARNING: Although the company has taken reasonable precautions to insure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Registered in England and Wales No 09745479 as Dovefire Technology Solutions Limited Registered Address Clifton Mill, Pickup Street, Accrington, Lancashire, BB5 0EY Please consider the environment before printing this e-mail. www.dovefire.co.uk From peterl at standingwave.org Thu Jun 23 18:25:10 2016 From: peterl at standingwave.org (Peter Loron) Date: Thu, 23 Jun 2016 11:25:10 -0700 Subject: Cisco 2 factor authentication Message-ID: We are in the process of rolling out Okta, including using a second factor for AnyConnect VPN. Works well. -Pete On 6/22/16, 01:27, "NANOG on behalf of Ray Ludendorff" wrote: Has anyone setup two factor VPN using a Cisco ASA VPN solution? What sort of soft client based dual factor authentication options were used for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, RSA, etc.) I am trying to find what infrastructure is needed to come up with the solution. Please contact me of list Regards Ray Ludendorff From kmedcalf at dessus.com Fri Jun 24 03:55:49 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 23 Jun 2016 21:55:49 -0600 Subject: 60 hudson - insurance? In-Reply-To: Message-ID: How do you show proof of self-insurance? Or is this an extortion racket? > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris McDonald > Sent: Thursday, 23 June, 2016 09:23 > To: nanog list > Subject: 60 hudson - insurance? > > are others being told that their remote hands / installers , etc now need > to show proof of insurance? > > thanks From dovid at telecurve.com Fri Jun 24 10:34:43 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 24 Jun 2016 10:34:43 +0000 Subject: 60 hudson - insurance? In-Reply-To: References: Message-ID: <1712463780-1466764483-cardhu_decombobulator_blackberry.rim.net-691033259-@b12.c1.bise6.blackberry> You show them proof from your insurance provider. Regards, Dovid -----Original Message----- From: "Keith Medcalf" Sender: "NANOG" Date: Thu, 23 Jun 2016 21:55:49 To: nanog list Subject: RE: 60 hudson - insurance? How do you show proof of self-insurance? Or is this an extortion racket? > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris McDonald > Sent: Thursday, 23 June, 2016 09:23 > To: nanog list > Subject: 60 hudson - insurance? > > are others being told that their remote hands / installers , etc now need > to show proof of insurance? > > thanks From bob at FiberInternetCenter.com Fri Jun 24 16:27:02 2016 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 24 Jun 2016 09:27:02 -0700 Subject: Quick question regarding: Problematic IPv6 Multicast traffic within an IX. Message-ID: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> Is it true that managed Layer2 switches used by IX's can not block IPv6 multicast ingress port traffic from broadcasting to all ports ? ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast is blocked. ___No , All should be able to bock IPv6 multicast. ___Only a few specific managed switch manufacturers have this issue with IPv6 multicast broadcasting. You're knowledge on this problem would be helpful. Thank You in advance. Bob Evans CTO From baldur.norddahl at gmail.com Fri Jun 24 17:00:28 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 24 Jun 2016 19:00:28 +0200 Subject: Quick question regarding: Problematic IPv6 Multicast traffic within an IX. In-Reply-To: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> References: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> Message-ID: IPv6 NDP is multicast so you can not block multicast with a layer 2 ACL. You need L3 ACL to block all multicast except NDP packets. Of course any switch in use at a major transition point in the internet should have that capability. Regards, Baldur On 24 June 2016 at 18:27, Bob Evans wrote: > > Is it true that managed Layer2 switches used by IX's can not block IPv6 > multicast ingress port traffic from broadcasting to all ports ? > > ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast > is blocked. > > ___No , All should be able to bock IPv6 multicast. > > ___Only a few specific managed switch manufacturers have this issue with > IPv6 multicast broadcasting. > > You're knowledge on this problem would be helpful. > > Thank You in advance. > > Bob Evans > CTO > > > > > > > From sean at donelan.com Fri Jun 24 17:23:44 2016 From: sean at donelan.com (Sean Donelan) Date: Fri, 24 Jun 2016 13:23:44 -0400 (EDT) Subject: FCC adopts order requiring submarine cable outage reporting Message-ID: In the past, over 75% of submarine cable operators did not voluntarily report outages of submarine cables with US landing points to the FCC. In other words, less than 25% of submarine cable operators reported outages. The FCC would learn about the submarine cable failures, sometimes days later, from news reports or calls from the public. Since the FCC treats outage reports as confidential information, that still means the public will not necessarily be informed. https://www.fcc.gov/document/fcc-adopts-rules-reliable-submarine-cable-infrastructure The rules require submarine cable licensees to report major outages to the agency?s Network Outage Reporting System (NORS). Other communications providers ? including wireline, wireless, and satellite ? already report outages to NORS. From joelja at bogus.com Fri Jun 24 17:31:06 2016 From: joelja at bogus.com (joel jaeggli) Date: Fri, 24 Jun 2016 10:31:06 -0700 Subject: Quick question regarding: Problematic IPv6 Multicast traffic within an IX. In-Reply-To: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> References: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> Message-ID: On 6/24/16 9:27 AM, Bob Evans wrote: > > Is it true that managed Layer2 switches used by IX's can not block IPv6 > multicast ingress port traffic from broadcasting to all ports ? you can filter multicast destination addresses by acl. NDP you kinda need since it replaces ARP RA's you can and should filter (icmp6 type 134) > ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast > is blocked. > > ___No , All should be able to bock IPv6 multicast. > > ___Only a few specific managed switch manufacturers have this issue with > IPv6 multicast broadcasting. > > You're knowledge on this problem would be helpful. > > Thank You in advance. > > Bob Evans > CTO > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From sean.watkins at gmail.com Fri Jun 24 15:37:52 2016 From: sean.watkins at gmail.com (Sean Watkins) Date: Fri, 24 Jun 2016 09:37:52 -0600 Subject: colo at 111 8th ave NY? Message-ID: Hi, I'm looking for a rack or half rack at 111 8th ave NYC. I've tried going via sales at Equinix etc and few other carriers, it seems to never go anywhere... Can anyone who is there, and wants to sell some space contact me off list? thanks Sean -- -- Sean Watkins 403-629-6152 From todd.crane at n5tech.com Sat Jun 25 10:11:19 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Sat, 25 Jun 2016 03:11:19 -0700 Subject: colo at 111 8th ave NY? In-Reply-To: References: Message-ID: <5E626FAA-55EC-48E3-8A1D-ECDA11622564@n5tech.com> Ditto > On Jun 24, 2016, at 8:37 AM, Sean Watkins wrote: > > Hi, > > I'm looking for a rack or half rack at 111 8th ave NYC. > > I've tried going via sales at Equinix etc and few other carriers, it seems > to never go anywhere... > > Can anyone who is there, and wants to sell some space contact me off list? > thanks > > > Sean > > > -- > -- > Sean Watkins > 403-629-6152 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bms at fastmail.net Sat Jun 25 10:29:07 2016 From: bms at fastmail.net (Bruce Simpson) Date: Sat, 25 Jun 2016 11:29:07 +0100 Subject: Quick question regarding: Problematic IPv6 Multicast traffic within an IX. In-Reply-To: References: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> Message-ID: <576E5CF3.8070209@fastmail.net> On 24/06/16 18:31, joel jaeggli wrote: > you can filter multicast destination addresses by acl. > > NDP you kinda need since it replaces ARP > > RA's you can and should filter (icmp6 type 134) Data point, although the chances of you using this kit in an IX are slim to none: The HPE-badged H3C workgroup switches are problematic to configure this for. 1) The web GUI is woefully unable to do it right, and HP do not officially sanction the use of the CLI. 2) IPv6 packet ACLs only appear to be supported per-port on *ingress*. From v.bajpai at jacobs-university.de Sat Jun 25 16:55:52 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Sat, 25 Jun 2016 16:55:52 +0000 Subject: measuring effects of happy eyeballs Message-ID: <787BAD39-36A0-48E8-8D6E-0F10AACFCEF1@jacobs-university.de> Dear NANOG, A paper on measuring the effects of happy eyeballs [RFC 6555] just got accepted last week. This uses a 3-years long ('13 - '16) dataset of TCP connect times towards ALEXA top 10K websites collected from 80 dual-stacked SamKnows probes. We just released [a] the paper. Thought to share it along: [a] http://goo.gl/JmKEax Feedback most welcome! You may recall preliminary versions of this work at RIPE 66 [b] and IETF 87 [c]. [b] https://ripe66.ripe.net/archives/video/1208 [c] https://vimeo.com/71407427 Measuring the Effects of Happy Eyeballs --------------------------------------- The IETF has developed protocols that promote a healthy IPv4 and IPv6 co-existence. The Happy Eyeballs (HE) algorithm, for instance, prevents bad user experience in situations where IPv6 connectivity is broken. Using an active test (happy) that measures TCP connection establishment times, we evaluate the effects of the HE algorithm. The happy test measures against ALEXA top 10K websites from 80 SamKnows probes connected to dual-stacked networks representing 58 different ASes. Using a 3-years long (2013 - 2016) dataset, we show that TCP connect times to popular websites over IPv6 have considerably improved over time. As of May 2016, 18% of these websites are faster over IPv6 with 91% of the rest at most 1 ms slower. The historical trend shows that only around 1% of the TCP connect times over IPv6 were ever above the HE timer value (300 ms), which leaves around 2% chance for IPv4 to win a HE race towards these websites. As such, 99% of these websites prefer IPv6 connections more than 98% of the time. We show that although absolute TCP connect times (in ms) are not that far apart in both address families, HE with a 300 ms timer value tends to prefer slower IPv6 connections in around 90% of the cases. We show that lowering the HE timer value to 150 ms gives us a margin benefit of 10% while retaining same preference levels over IPv6. Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Sun Jun 26 01:54:54 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 25 Jun 2016 21:54:54 -0400 Subject: Quick question regarding: Problematic IPv6 Multicast traffic within an IX. In-Reply-To: <576E5CF3.8070209@fastmail.net> References: <90f40c0a2e1c274032f10a66281d4dc5.squirrel@66.201.44.180> <576E5CF3.8070209@fastmail.net> Message-ID: On Sat, Jun 25, 2016 at 6:29 AM, Bruce Simpson wrote: > On 24/06/16 18:31, joel jaeggli wrote: > >> you can filter multicast destination addresses by acl. >> >> NDP you kinda need since it replaces ARP >> >> RA's you can and should filter (icmp6 type 134) >> > > Data point, although the chances of you using this kit in an IX are slim > to none: The HPE-badged H3C workgroup switches are problematic to configure > this for. > > 1) The web GUI is woefully unable to do it right, and HP do not officially > sanction the use of the CLI. > ?haha! you said gui and switch configuration... Errm, 'do not officially sanction the use of the CLI' ? Did you promptly 'not officially sanction their use in your nettwork?' If not, I think I see your problem...? > > 2) IPv6 packet ACLs only appear to be supported per-port on *ingress*. > > ?I think this might actually be the case for quite a few devices/manufacturers actually. It's nice that for mcast on v6 you actually mostly care about that on ingress though :)? From mysidia at gmail.com Sun Jun 26 02:46:22 2016 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 Jun 2016 21:46:22 -0500 Subject: Cisco 2 factor authentication In-Reply-To: <62B62BB0-17F5-41C5-8689-9D98D838FBF8@dovefire.co.uk> References: <62B62BB0-17F5-41C5-8689-9D98D838FBF8@dovefire.co.uk> Message-ID: On Wed, Jun 22, 2016 at 9:38 PM, Chris Lawrence wrote: > Any radius based auth works well I've used a solution by secure envoy I the past which seems to work well they also have soft token apps, hard tokens plus SMS based. However, a cautionary note there is that RADIUS protocol itself uses only weak cryptography and is not secure on the wire. That is, in the absence of AES Keywrap proprietary extension Or when the method of credential used is not authentication using a Client-side Certificate (PKI) as in *EAP. Specifically: if RADIUS is used for the Authentication stage of AAA with a code sent by SMS or OATH token [User types Normal password + One Time Password], then when traffic between RADIUS server and VPN device is captured: The user credentials may be exposed with the extremely weak crypto protection RADIUS or NTLM provides for the user password. If a user re-uses their same password somewhere else on a device not requiring 2FA, then capturing RADIUS traffic could be an effective privilege escalation By copying victim's password from a sniffed RADIUS exchange. -- -JH From A.L.M.Buxey at lboro.ac.uk Sun Jun 26 17:23:49 2016 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Sun, 26 Jun 2016 18:23:49 +0100 Subject: Cisco 2 factor authentication In-Reply-To: References: <62B62BB0-17F5-41C5-8689-9D98D838FBF8@dovefire.co.uk> Message-ID: <3F04C056-5BE5-4D33-9B32-B3A52B401627@lboro.ac.uk> As per other statements of such seen elsewhere online, do you have examples or code which will allow the recovery of passwords in a radius exchange? Yes, the shared secret mechanism is widely stated as 'weak' but actively attacked? alan From stephen at sprunk.org Sun Jun 26 20:59:47 2016 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 26 Jun 2016 15:59:47 -0500 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <57603722.4000609@bryanfields.net> <0DA9FCB4-32B9-4271-A79B-BFD1EABD5CEA@steffann.nl> <514735F7-FFA8-4B41-BC51-B80AB4D8C2C6@harg.net> <20160617134835.GA55732@ussenterprise.ufp.org> <7563F9F7-1D93-4F7F-BB70-1E02EA6ED7E0@cloudflare.com> <20160617145954.GA58135@ussenterprise.ufp.org> <57641755.5030300@foobar.org> Message-ID: <3d0748c0b03c6efc4196592f280e3e57@japh.net> On 2016-06-18 12:54, Brandon Ross wrote: > On Fri, 17 Jun 2016, Eric Kuhnke wrote: > >> What Randy just wrote is exactly the point I was trying to make in my >> last >> email. Some real estate facility owners/managers have got into the >> mistaken >> mindset that they can get the greatest value and the most monthly >> revenue >> from the square-footage of their building by charging additional MRC >> XC >> fees to the tenants of the building. > > There are some VERY sucessful companies that would strongly disagree > with you. > >> When in fact the opposite is true, and we need a concerted community >> effort >> to lobby every IX real estate owner with this fact: Your real estate >> will >> be MORE valuable and will attract a greater critical mass of carriers, >> eyeball networks, CDNs, huge hosting providers/colo/VM, etc if you >> make the >> crossconnects free. > > But then why would we want to do that? If you are correct and doing > so would raise the value of the real esatate, doesn't that mean that > the building managers would be able to charge operators a whole lot > more than they are able to today, in aggregate? If the price of XC drops to ~zero, then tenants are going to do a lot more of it and thereby get more value from the IX, which means people will be _willing_ to pay more for that real estate, rather than complaining about XC price-gouging. It's as much perception as it is math. OTOH, if prices climb to unreasonable levels, then more space will (eventually) be made available, e.g. by pushing non-IX tenants out of the building, by laying ample dark fiber to a nearby building for expansion (but still ~free XC) or by a competitor appearing. The problems come with expansion that is _not_ nearby, i.e. XC can no longer be ~free, yet the operator still tries to pretend it's a single facility. There are plenty of folks in the business of transporting bits over long distances; IMHO, an IX shouldn't be one of them. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From tom.smyth at wirelessconnect.eu Mon Jun 27 01:36:10 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Mon, 27 Jun 2016 02:36:10 +0100 Subject: Cisco 2 factor authentication In-Reply-To: References: <62B62BB0-17F5-41C5-8689-9D98D838FBF8@dovefire.co.uk> Message-ID: The radius protocol traffic can be encrypted with ipsec policies...if confidentiality of the radius traffic is a concern ( particularly if traversing untrusted networks) On 26 Jun 2016 3:48 a.m., "Jimmy Hess" wrote: > On Wed, Jun 22, 2016 at 9:38 PM, Chris Lawrence > wrote: > > Any radius based auth works well I've used a solution by secure envoy I > the past which seems to work well they also have soft token apps, hard > tokens plus SMS based. > > However, a cautionary note there is that RADIUS protocol itself uses > only weak cryptography and is not secure on the wire. > > That is, in the absence of AES Keywrap proprietary extension Or when > the method of credential used is not authentication using a > Client-side Certificate (PKI) as in *EAP. > > Specifically: if RADIUS is used for the Authentication stage of AAA > with a code sent by SMS or OATH token [User types Normal password + > One Time Password], then when traffic between RADIUS server and VPN > device is captured: The user credentials may be exposed with the > extremely weak crypto protection RADIUS or NTLM provides for the > user password. > > If a user re-uses their same password somewhere else on a device not > requiring 2FA, then capturing RADIUS traffic could be an effective > privilege escalation By copying victim's password from a sniffed > RADIUS exchange. > > -- > -JH > From ryan.g at atwgpc.net Mon Jun 27 18:42:09 2016 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Mon, 27 Jun 2016 13:42:09 -0500 Subject: Cisco 2 factor authentication In-Reply-To: References: Message-ID: We use Phonefactor (now azure authenticator) with anyconnect vpn. It sits in front of LDAP/AD and integrates with it. It an be a PITA but it works. On Wed, Jun 22, 2016 at 3:27 AM, Ray Ludendorff wrote: > Has anyone setup two factor VPN using a Cisco ASA VPN solution? > What sort of soft client based dual factor authentication options were > used for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure > authenticator, RSA, etc.) > I am trying to find what infrastructure is needed to come up with the > solution. > > Please contact me of list > > Regards > Ray Ludendorff > > > > From sh.vahabzadeh at gmail.com Mon Jun 27 11:05:41 2016 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 27 Jun 2016 15:35:41 +0430 Subject: IX in Iran by TIC Message-ID: Hello Everybody, I am here to announce that TIC in Iran launched Neutral Internet Exchange Points. Right now we have four in: - Tehran (tehran-ix.ir) - Shiraz (shiraz-ix.ir) - Tabriz (tabriz-ix.ir) - Mashhad (mashhad-ix.ir) Currently we have near 45Gbps traffic on it but it will increase to 100Gbps within two months. Content Providers activating their BGP peering with members one by one. Also I have something interesting for you around the world, TIC is launching a International IX in Chabahar called Chabahar IX (chabahar-ix.ir) which can be interesting for T1 ISPs or Content Providers like Akamai, Amazon, Google, Limelight, Cloudflare and etc. We are able to give anyone colocation space or ground for building their own Datacenter. As you know Iran is cheapest country in Middle East for Energy and Electricity reasons so we are the best opportunity for having a node there. Cables we have there right now are POI, FALCON and GCX. Please share this with your friends or your Business Development departments. If anyone have question regard this you can contact me via this email or peering at tic.ir. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 From bz_siege_01 at hotmail.com Mon Jun 27 20:08:24 2016 From: bz_siege_01 at hotmail.com (c b) Date: Mon, 27 Jun 2016 13:08:24 -0700 Subject: automated site to site vpn recommendations Message-ID: Situation: We have salespeople/engineers holding temporary seminars/training/demonstrations in hotel meeting rooms. Requirements: field people need a very plug-n-play, simple, reliable vpn back to corporate offices to present videos/slides/demonstrations. The materials are not accessible via the internet directly, they are in a contained environment at corporate HQ locations but not necessarily on the corp network.the solution should be able to provide wireless to attendees. In some cases, guest login will be fine but in some cases the attendees will have registered and provided login creds prior to the event, and these creds will need to be checked before providing accessthe solution should have the option to split tunnel internet traffic out, but in some cases they need all traffic tunneled and internet will be via our corporate offices (NDA/legal, don't ask, it's just a requirement provided) Nice-to-have: field person should be able to not only access the presentation materials (in their contained network) but also the corporate network. Some early attempts required a user-vpn connection by the field person over the S2S VPN, but it made it clunky to switch back and forth. This isn't mandatory, but it would be nice to provide one solution providing dual-level access: restricted to attendees, less-restricted to field people Tried this in the past with basic router/switch/wireless and captive portals because we had some inventory available... it was workable but not quick or easy. We really could use a simple solution that you just flip on, it calls home, and works... or as close to that as possible. Have been looking at Meraki and a couple other low-touch solutions and they may do the trick, but we are hoping there are lower cost options that people have used successfully? We don't mind dealing with some off brands and even some custom coding (within reason) as long as the end result is a low-touch, reliable solution. Thanks in advance. From shawnl at up.net Mon Jun 27 20:17:41 2016 From: shawnl at up.net (Shawn L) Date: Mon, 27 Jun 2016 16:17:41 -0400 (EDT) Subject: automated site to site vpn recommendations In-Reply-To: References: Message-ID: <1467058661.64471723@upnet.mymailsrvr.com> We use the Meraki series -- MX @ the main office, and Z1 for the remote, or just 2 Z1 units if it's a small network and they work great. We've even gone so far as to utilize Avaya ip phones over the link so the teleworker's extension works wherever they are. I have to say, compared to a PIX or ASA, etc. they are about the simplest VPN setup you'll ever come across. We've even had cases where the Z1 was behind a fairly restrictive NAT, and it was able to establish a session and work great. Definitely not the cheapest, but if you can get by with just a couple of Z1s the cost isn't too bad. Shawn -----Original Message----- From: "c b" Sent: Monday, June 27, 2016 4:08pm To: "nanog at nanog.org" Subject: automated site to site vpn recommendations Situation: We have salespeople/engineers holding temporary seminars/training/demonstrations in hotel meeting rooms. Requirements: field people need a very plug-n-play, simple, reliable vpn back to corporate offices to present videos/slides/demonstrations. The materials are not accessible via the internet directly, they are in a contained environment at corporate HQ locations but not necessarily on the corp network.the solution should be able to provide wireless to attendees. In some cases, guest login will be fine but in some cases the attendees will have registered and provided login creds prior to the event, and these creds will need to be checked before providing accessthe solution should have the option to split tunnel internet traffic out, but in some cases they need all traffic tunneled and internet will be via our corporate offices (NDA/legal, don't ask, it's just a requirement provided) Nice-to-have: field person should be able to not only access the presentation materials (in their contained network) but also the corporate network. Some early attempts required a user-vpn connection by the field person over the S2S VPN, but it made it clunky to switch back and forth. This isn't mandatory, but it would be nice to provide one solution providing dual-level access: restricted to attendees, less-restricted to field people Tried this in the past with basic router/switch/wireless and captive portals because we had some inventory available... it was workable but not quick or easy. We really could use a simple solution that you just flip on, it calls home, and works... or as close to that as possible. Have been looking at Meraki and a couple other low-touch solutions and they may do the trick, but we are hoping there are lower cost options that people have used successfully? We don't mind dealing with some off brands and even some custom coding (within reason) as long as the end result is a low-touch, reliable solution. Thanks in advance. From kauer at biplane.com.au Mon Jun 27 21:59:22 2016 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 28 Jun 2016 07:59:22 +1000 Subject: automated site to site vpn recommendations In-Reply-To: References: Message-ID: <1467064762.2148.41.camel@biplane.com.au> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > In some cases... The words "in some cases" are a problem with any supposedly plug and play solution. > We really could use a simple solution that you > just flip on, it calls home, and works... ...but still requiring someone to enter credentials of some sort, right? Otherwise you have a device wandering about that provides look -mum-no-hands access to your corporate network. MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB for a wireless dongle or storage, and has a highly-scriptable operating system. Not a bad platform. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 From mikeal.clark at gmail.com Mon Jun 27 22:39:35 2016 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 27 Jun 2016 17:39:35 -0500 Subject: automated site to site vpn recommendations In-Reply-To: <1467064762.2148.41.camel@biplane.com.au> References: <1467064762.2148.41.camel@biplane.com.au> Message-ID: Fortinet has stuff that does this that is non-IT friendly. On Mon, Jun 27, 2016 at 4:59 PM, Karl Auer wrote: > On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > In some cases... > > The words "in some cases" are a problem with any supposedly plug and > play solution. > > > We really could use a simple solution that you > > just flip on, it calls home, and works... > > ...but still requiring someone to enter credentials of some sort, > right? Otherwise you have a device wandering about that provides look > -mum-no-hands access to your corporate network. > > MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > for a wireless dongle or storage, and has a highly-scriptable operating > system. Not a bad platform. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > > > > From eric.kuhnke at gmail.com Mon Jun 27 23:26:16 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 27 Jun 2016 16:26:16 -0700 Subject: Real world power consumption of a 7604-S or 7606-S Message-ID: I'm finding that the spec sheet for an RSP720-3CXL says 310W for the supervisor itself. Assuming a dual supervisor configuration in a 7604 or 7606, has anyone put one on a watt meter and measured its actual power consumption? Example: 7604S chassis with dual 2700W DC power - chassis and fans use how much power? 2 x RSP720-3CXL at 310W each WS-X6704 with DFC4 - ???W each From tom at ninjabadger.net Tue Jun 28 00:26:14 2016 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 28 Jun 2016 01:26:14 +0100 Subject: Real world power consumption of a 7604-S or 7606-S In-Reply-To: References: Message-ID: <5771C426.2030700@ninjabadger.net> On 28/06/16 00:26, Eric Kuhnke wrote: > Example: > 7604S chassis with dual 2700W DC power - chassis and fans use how much > power? > 2 x RSP720-3CXL at 310W each > WS-X6704 with DFC4 - ???W each Way too much, is the simple answer. I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW. It's not healthy, please consider how much you'll spend in electricity vs. something else. For example, the ASR9001 uses a 5th of the power. Cisco do also have a power calculator, too. It's conservative but not overly so: http://cpc.cloudapps.cisco.com/cpc/launch.jsp -- Tom From eric.kuhnke at gmail.com Tue Jun 28 00:35:05 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 27 Jun 2016 17:35:05 -0700 Subject: Real world power consumption of a 7604-S or 7606-S In-Reply-To: <5771C426.2030700@ninjabadger.net> References: <5771C426.2030700@ninjabadger.net> Message-ID: Yes, very much agreed, part of the reason why I'm looking to do the watts per linecard calculation is to illustrate how it's not healthy except in certain places. As an edge aggregation device in a very small city in a rural western US state where the electricity is 6 cents/kWh, the 24x7 load from a 7604 that eats 950W with supervisors and a 6724SFP linecard is not so terrible. In this case the colo space for a 42U rack is sometimes literally free. In a IX point/datacenter/colocation environment where rack and power costs real money, not so much. On Mon, Jun 27, 2016 at 5:26 PM, Tom Hill wrote: > On 28/06/16 00:26, Eric Kuhnke wrote: > > Example: > > 7604S chassis with dual 2700W DC power - chassis and fans use how much > > power? > > 2 x RSP720-3CXL at 310W each > > WS-X6704 with DFC4 - ???W each > > Way too much, is the simple answer. > > I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x > WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW. > > It's not healthy, please consider how much you'll spend in electricity > vs. something else. For example, the ASR9001 uses a 5th of the power. > > > Cisco do also have a power calculator, too. It's conservative but not > overly so: > > http://cpc.cloudapps.cisco.com/cpc/launch.jsp > > -- > Tom > From hannigan at gmail.com Tue Jun 28 01:16:46 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 27 Jun 2016 21:16:46 -0400 Subject: IX in Iran by TIC In-Reply-To: References: Message-ID: On Mon, Jun 27, 2016 at 7:05 AM, Shahab Vahabzadeh wrote: > Hello Everybody, > I am here to announce that TIC in Iran launched Neutral Internet Exchange > Points. > Right now we have four in: > > - Tehran (tehran-ix.ir) > - Shiraz (shiraz-ix.ir) > - Tabriz (tabriz-ix.ir) > - Mashhad (mashhad-ix.ir) > > Currently we have near 45Gbps traffic on it but it will increase to 100Gbps > within two months. Content Providers activating their BGP peering with > members one by one. > > Also I have something interesting for you around the world, TIC is > launching a International IX in Chabahar called Chabahar IX (chabahar-ix.ir) > which can be interesting for T1 ISPs or Content Providers like Akamai, > Amazon, Google, Limelight, Cloudflare and etc. > Thanks, I'll get this to the right people internally (AKAMAI). In the meantime, there are a number of peering groups on Facebook (global peering forum, peering forum, peeringDB) that you may want to join to discuss this as well. Don't forget to register in peeringDB: https://www.peeringdb.com/search?q=IRAN And finally, great pictures! http://www.tehran-ix.ir/fa/news/ixp-workshop Good luck! Best, Martin From joelja at bogus.com Tue Jun 28 05:37:20 2016 From: joelja at bogus.com (joel jaeggli) Date: Mon, 27 Jun 2016 22:37:20 -0700 Subject: Real world power consumption of a 7604-S or 7606-S In-Reply-To: References: <5771C426.2030700@ninjabadger.net> Message-ID: <5d3995f9-e77b-d4dc-3912-c62ff90d9469@bogus.com> On 6/27/16 5:35 PM, Eric Kuhnke wrote: > Yes, very much agreed, part of the reason why I'm looking to do the > watts per linecard calculation is to illustrate how it's not healthy > except in certain places. As an edge aggregation device in a very > small city in a rural western US state where the electricity is 6 > cents/kWh, the 24x7 load from a 7604 that eats 950W with supervisors > and a 6724SFP linecard is not so terrible. In this case the colo > space for a 42U rack is sometimes literally free. > > In a IX point/datacenter/colocation environment where rack and power > costs real money, not so much. 2 x ( 4 x 10Gig) linecards is really as fast as it goes no over-subscribed. It's been rather a long time or possibly never since that platform was cutting edge on a PPS/Watt basis. Today at roughly double the power consumpution per slot you can have between 16 and 36 hundred gig ports or 48 x 10gig at half the power consumption. > > On Mon, Jun 27, 2016 at 5:26 PM, Tom Hill > wrote: > >> On 28/06/16 00:26, Eric Kuhnke wrote: >>> Example: 7604S chassis with dual 2700W DC power - chassis and >>> fans use how much power? 2 x RSP720-3CXL at 310W each WS-X6704 >>> with DFC4 - ???W each >> >> Way too much, is the simple answer. >> >> I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x >> WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW. >> >> It's not healthy, please consider how much you'll spend in >> electricity vs. something else. For example, the ASR9001 uses a 5th >> of the power. >> >> >> Cisco do also have a power calculator, too. It's conservative but >> not overly so: >> >> http://cpc.cloudapps.cisco.com/cpc/launch.jsp >> >> -- Tom >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jwbensley at gmail.com Tue Jun 28 08:12:16 2016 From: jwbensley at gmail.com (James Bensley) Date: Tue, 28 Jun 2016 09:12:16 +0100 Subject: Real world power consumption of a 7604-S or 7606-S In-Reply-To: <5771C426.2030700@ninjabadger.net> References: <5771C426.2030700@ninjabadger.net> Message-ID: On 28 June 2016 at 01:26, Tom Hill wrote: > On 28/06/16 00:26, Eric Kuhnke wrote: >> Example: >> 7604S chassis with dual 2700W DC power - chassis and fans use how much >> power? >> 2 x RSP720-3CXL at 310W each >> WS-X6704 with DFC4 - ???W each > > Way too much, is the simple answer. > > I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x > WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW. > > It's not healthy, please consider how much you'll spend in electricity > vs. something else. For example, the ASR9001 uses a 5th of the power. +1 for the asr9001 route. For the record though see below, I've tried to supply you figures from different model 7600s but we mostly hvae 7606-S's. These are all single SUP/RSPsystems. Cheers, James. 7606-S#show power system power redundancy mode = redundant system power total = 2669.10 Watts (63.55 Amps @ 42V) system power used = 1620.78 Watts (38.59 Amps @ 42V) system power available = 1048.32 Watts (24.96 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State ---- ------------------ ------- ------ ------ ------ ----- 1 PWR-2700-AC 2669.10 63.55 OK OK on 2 PWR-2700-AC 2669.10 63.55 OK OK on Pwr-Allocated Oper Fan Type Watts A @42V State ---- ------------------ ------- ------ ----- 1 FAN-MOD-6SHS 180.18 4.29 OK Pwr-Requested Pwr-Allocated Admin Oper Slot Card-Type Watts A @42V Watts A @42V State State ---- ------------------ ------- ------ ------- ------ ----- ----- 1 WS-X6748-SFP 322.14 7.67 322.14 7.67 on on 2 WS-X6704-10GE 362.46 8.63 362.46 8.63 on on 5 RSP720-3CXL-10GE 378.00 9.00 378.00 9.00 on on 6 (Redundant Sup) - - 378.00 9.00 - - 7606-S#show power system power redundancy mode = redundant system power total = 2669.10 Watts (63.55 Amps @ 42V) system power used = 2137.38 Watts (50.89 Amps @ 42V) system power available = 531.72 Watts (12.66 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State ---- ------------------ ------- ------ ------ ------ ----- 1 PWR-2700-AC 2669.10 63.55 OK OK on 2 PWR-2700-AC 2669.10 63.55 OK OK on Pwr-Allocated Oper Fan Type Watts A @42V State ---- ------------------ ------- ------ ----- 1 FAN-MOD-6SHS 180.18 4.29 OK Pwr-Requested Pwr-Allocated Admin Oper Slot Card-Type Watts A @42V Watts A @42V State State ---- ------------------ ------- ------ ------- ------ ----- ----- 1 WS-X6748-GE-TX 325.50 7.75 325.50 7.75 on on 2 WS-X6748-SFP 254.94 6.07 254.94 6.07 on on 3 WS-X6704-10GE 295.26 7.03 295.26 7.03 on on 4 WS-X6748-GE-TX 325.50 7.75 325.50 7.75 on on 5 (Redundant Sup) - - 378.00 9.00 - - 6 RSP720-3CXL-10GE 378.00 9.00 378.00 9.00 on on 7604(non -S)#show power system power redundancy mode = redundant system power total = 2669.10 Watts (63.55 Amps @ 42V) system power used = 760.20 Watts (18.10 Amps @ 42V) system power available = 1908.90 Watts (45.45 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State ---- ------------------ ------- ------ ------ ------ ----- 1 PWR-2700-AC/4 2669.10 63.55 OK OK on 2 PWR-2700-AC/4 2669.10 63.55 OK OK on Pwr-Allocated Oper Fan Type Watts A @42V State ---- ------------------ ------- ------ ----- 1 FAN-MOD-4HS 57.54 1.37 OK Pwr-Requested Pwr-Allocated Admin Oper Slot Card-Type Watts A @42V Watts A @42V State State ---- ------------------ ------- ------ ------- ------ ----- ----- 1 WS-SUP720-3B 282.24 6.72 282.24 6.72 on on 2 WS-X6704-10GE 295.26 7.03 295.26 7.03 on on 3 WS-X6548-GE-TX 125.16 2.98 125.16 2.98 on on From marty at cloudflare.com Tue Jun 28 08:49:40 2016 From: marty at cloudflare.com (Marty Strong) Date: Tue, 28 Jun 2016 09:49:40 +0100 Subject: IX in Iran by TIC In-Reply-To: References: Message-ID: <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com> Can?t agree more about putting your IXPs on PeeringDB, it?s my first port of call when looking at locations to expand to. Also, I would say to add the data centres too, to give a better idea of where the IXPs are physically located. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 28 Jun 2016, at 02:16, Martin Hannigan wrote: > > On Mon, Jun 27, 2016 at 7:05 AM, Shahab Vahabzadeh > wrote: >> Hello Everybody, >> I am here to announce that TIC in Iran launched Neutral Internet Exchange >> Points. >> Right now we have four in: >> >> - Tehran (tehran-ix.ir) >> - Shiraz (shiraz-ix.ir) >> - Tabriz (tabriz-ix.ir) >> - Mashhad (mashhad-ix.ir) >> >> Currently we have near 45Gbps traffic on it but it will increase to 100Gbps >> within two months. Content Providers activating their BGP peering with >> members one by one. >> >> Also I have something interesting for you around the world, TIC is >> launching a International IX in Chabahar called Chabahar IX (chabahar-ix.ir) >> which can be interesting for T1 ISPs or Content Providers like Akamai, >> Amazon, Google, Limelight, Cloudflare and etc. >> > > Thanks, I'll get this to the right people internally (AKAMAI). In the > meantime, there are a number of peering groups on Facebook (global > peering forum, peering forum, peeringDB) that you may want to join to > discuss this as well. > > Don't forget to register in peeringDB: > > https://www.peeringdb.com/search?q=IRAN > > And finally, great pictures! http://www.tehran-ix.ir/fa/news/ixp-workshop > > Good luck! > > Best, > > Martin From mrsyeltzin at gmail.com Mon Jun 27 22:28:02 2016 From: mrsyeltzin at gmail.com (Dan Stralka) Date: Mon, 27 Jun 2016 18:28:02 -0400 Subject: automated site to site vpn recommendations In-Reply-To: <1467064762.2148.41.camel@biplane.com.au> References: <1467064762.2148.41.camel@biplane.com.au> Message-ID: I would second Meraki for the situation you describe. I don't feel that they are the most capable platform, they're expensive, and don't always present you with all the information you'd need for troubleshooting. However, the VPN offers great dynamic tunneling, instant-on performance, and are by far the simplest platform to offer a field person. They're also tenacious - I've had them connect to the cloud management platform and build a VPN under some trying circumstances. >From a security standpoint, they will offer features that will impress for the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN tunnel control), and we've found they punch above their weight and their APs perform fantastically. We deploy them worldwide many times per year in similar use cases, sometimes with 150 users on the LAN. If your routing is simple, you can define your security policies, and don't need crazy throughput on your VPN, Meraki is the way to go. Be careful though: they have to be continually licensed to work and can get pretty expensive if you go for the higher end gear. Thus far, we've been able to stick to the cheaper stuff and accomplish our goals. Dan (end) On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > In some cases... > > The words "in some cases" are a problem with any supposedly plug and > play solution. > > > We really could use a simple solution that you > > just flip on, it calls home, and works... > > ...but still requiring someone to enter credentials of some sort, > right? Otherwise you have a device wandering about that provides look > -mum-no-hands access to your corporate network. > > MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > for a wireless dongle or storage, and has a highly-scriptable operating > system. Not a bad platform. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > > > > From fgont at si6networks.com Tue Jun 28 14:13:21 2016 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 28 Jun 2016 16:13:21 +0200 Subject: Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World In-Reply-To: <20160621235735.BDFFDB80D0B@rfc-editor.org> References: <20160621235735.BDFFDB80D0B@rfc-editor.org> Message-ID: <57728601.6020503@si6networks.com> FYI -------- Forwarded Message -------- Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: v6ops at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox: fgont at si6networks.com, furry at google.com, tim.chown at jisc.ac.uk, liushucheng at huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL: https://www.rfc-editor.org/info/rfc7872 DOI: http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From david.nelson at cityofhenderson.com Tue Jun 28 13:26:04 2016 From: david.nelson at cityofhenderson.com (David Nelson) Date: Tue, 28 Jun 2016 13:26:04 +0000 Subject: Level 3 Technical Contact Message-ID: Please contact me off list if you have a contact at Level 3 that can help. I have performance issues coming out of Las Vegas and ditching routes to Level 3 seems to fix the problem. Has anyone else seen/heard about problems in US Southwest? From greasley at superfund.net Tue Jun 28 16:21:50 2016 From: greasley at superfund.net (Richard Greasley) Date: Tue, 28 Jun 2016 12:21:50 -0400 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> Message-ID: <039601d1d159$2d5ae080$8810a180$@superfund.net> Another option is Checkpoint Edge devices. We use them worldwide with little to no problems. They're centrally managed and support central logging which is a plus when trying to diagnose issues. They support dynamic IP addresses as well, so just plug it in and you should be good to go. Not the cheapest solution, but for sure they get the job done. Regards, Richard. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan Stralka Sent: Monday, June 27, 2016 6:28 PM To: Karl Auer Cc: nanog at nanog.org Subject: Re: automated site to site vpn recommendations I would second Meraki for the situation you describe. I don't feel that they are the most capable platform, they're expensive, and don't always present you with all the information you'd need for troubleshooting. However, the VPN offers great dynamic tunneling, instant-on performance, and are by far the simplest platform to offer a field person. They're also tenacious - I've had them connect to the cloud management platform and build a VPN under some trying circumstances. >From a security standpoint, they will offer features that will impress for the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN tunnel control), and we've found they punch above their weight and their APs perform fantastically. We deploy them worldwide many times per year in similar use cases, sometimes with 150 users on the LAN. If your routing is simple, you can define your security policies, and don't need crazy throughput on your VPN, Meraki is the way to go. Be careful though: they have to be continually licensed to work and can get pretty expensive if you go for the higher end gear. Thus far, we've been able to stick to the cheaper stuff and accomplish our goals. Dan (end) On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > In some cases... > > The words "in some cases" are a problem with any supposedly plug and > play solution. > > > We really could use a simple solution that you > > just flip on, it calls home, and works... > > ...but still requiring someone to enter credentials of some sort, > right? Otherwise you have a device wandering about that provides look > -mum-no-hands access to your corporate network. > > MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > for a wireless dongle or storage, and has a highly-scriptable operating > system. Not a bad platform. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 From morgan.miskell at caro.net Tue Jun 28 16:47:17 2016 From: morgan.miskell at caro.net (Morgan A. Miskell) Date: Tue, 28 Jun 2016 12:47:17 -0400 Subject: AT&T/Bellsouth Fiber Gear Message-ID: <5772AA15.5000102@caro.net> Anyone on this list that can put me in touch with a contact in the division within AT&T that manages their fiber equipment deployed in the field? I need to speak with someone regarding some AT&T gear in our data center that is on old Bellsouth Sonet rings...... thanks! You can contact me off list via e-mail please! -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From carlos at race.com Tue Jun 28 21:58:10 2016 From: carlos at race.com (Carlos Alcantar) Date: Tue, 28 Jun 2016 21:58:10 +0000 Subject: AT&T/Bellsouth Fiber Gear In-Reply-To: <5772AA15.5000102@caro.net> References: <5772AA15.5000102@caro.net> Message-ID: We had a similar situation a couple years ago we went around for weeks trying to find someone that could help us with the equipment. We ended up pulling the power on the gear someone showed up 2 hours later. That finally got us someone we could actually talk with about re locating the equipment in the building. ? Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com ________________________________________ From: NANOG on behalf of Morgan A. Miskell Sent: Tuesday, June 28, 2016 9:47:17 AM To: nanog at nanog.org Subject: AT&T/Bellsouth Fiber Gear Anyone on this list that can put me in touch with a contact in the division within AT&T that manages their fiber equipment deployed in the field? I need to speak with someone regarding some AT&T gear in our data center that is on old Bellsouth Sonet rings...... thanks! You can contact me off list via e-mail please! -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From paul at nashnetworks.ca Wed Jun 29 12:55:40 2016 From: paul at nashnetworks.ca (Paul Nash) Date: Wed, 29 Jun 2016 08:55:40 -0400 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> Message-ID: <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> My biggest issue with Meraki is that their tech staff can run tcpdump on the wired or wireless interface of your Meraki box without having to leave their desk. I have no reason to believe that they are malicious, or in the pay of the NSA, but I am too paranoid to allow their equipment anywhere near me. Yes, they work well and the cloud control panel makes remote support a breeze; you have to decide how you feel about the insecurity. paul > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > I would second Meraki for the situation you describe. I don't feel that > they are the most capable platform, they're expensive, and don't always > present you with all the information you'd need for troubleshooting. > However, the VPN offers great dynamic tunneling, instant-on performance, > and are by far the simplest platform to offer a field person. They're also > tenacious - I've had them connect to the cloud management platform and > build a VPN under some trying circumstances. > > From a security standpoint, they will offer features that will impress for > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > tunnel control), and we've found they punch above their weight and their > APs perform fantastically. > > We deploy them worldwide many times per year in similar use cases, > sometimes with 150 users on the LAN. If your routing is simple, you can > define your security policies, and don't need crazy throughput on your VPN, > Meraki is the way to go. Be careful though: they have to be continually > licensed to work and can get pretty expensive if you go for the higher end > gear. Thus far, we've been able to stick to the cheaper stuff and > accomplish our goals. > > Dan > > (end) > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: >>> In some cases... >> >> The words "in some cases" are a problem with any supposedly plug and >> play solution. >> >>> We really could use a simple solution that you >>> just flip on, it calls home, and works... >> >> ...but still requiring someone to enter credentials of some sort, >> right? Otherwise you have a device wandering about that provides look >> -mum-no-hands access to your corporate network. >> >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB >> for a wireless dongle or storage, and has a highly-scriptable operating >> system. Not a bad platform. >> >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer at biplane.com.au) >> http://www.biplane.com.au/kauer >> http://twitter.com/kauer389 >> >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 >> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1974 bytes Desc: not available URL: From shawnl at up.net Wed Jun 29 13:32:06 2016 From: shawnl at up.net (Shawn L) Date: Wed, 29 Jun 2016 09:32:06 -0400 (EDT) Subject: automated site to site vpn recommendations In-Reply-To: <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: <1467207126.27749727@upnet.mymailsrvr.com> I believe they fixed this -- when I've spoken to tech support recently, I had to give them a tech support key so that they could access the devices I had questions about. -----Original Message----- From: "Paul Nash" Sent: Wednesday, June 29, 2016 8:55am To: "Untitled 3" Subject: Re: automated site to site vpn recommendations My biggest issue with Meraki is that their tech staff can run tcpdump on the wired or wireless interface of your Meraki box without having to leave their desk. I have no reason to believe that they are malicious, or in the pay of the NSA, but I am too paranoid to allow their equipment anywhere near me. Yes, they work well and the cloud control panel makes remote support a breeze; you have to decide how you feel about the insecurity. paul > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > I would second Meraki for the situation you describe. I don't feel that > they are the most capable platform, they're expensive, and don't always > present you with all the information you'd need for troubleshooting. > However, the VPN offers great dynamic tunneling, instant-on performance, > and are by far the simplest platform to offer a field person. They're also > tenacious - I've had them connect to the cloud management platform and > build a VPN under some trying circumstances. > > From a security standpoint, they will offer features that will impress for > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > tunnel control), and we've found they punch above their weight and their > APs perform fantastically. > > We deploy them worldwide many times per year in similar use cases, > sometimes with 150 users on the LAN. If your routing is simple, you can > define your security policies, and don't need crazy throughput on your VPN, > Meraki is the way to go. Be careful though: they have to be continually > licensed to work and can get pretty expensive if you go for the higher end > gear. Thus far, we've been able to stick to the cheaper stuff and > accomplish our goals. > > Dan > > (end) > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: >>> In some cases... >> >> The words "in some cases" are a problem with any supposedly plug and >> play solution. >> >>> We really could use a simple solution that you >>> just flip on, it calls home, and works... >> >> ...but still requiring someone to enter credentials of some sort, >> right? Otherwise you have a device wandering about that provides look >> -mum-no-hands access to your corporate network. >> >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB >> for a wireless dongle or storage, and has a highly-scriptable operating >> system. Not a bad platform. >> >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer at biplane.com.au) >> http://www.biplane.com.au/kauer >> http://twitter.com/kauer389 >> >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 >> >> >> >> From rich at tehorange.com Wed Jun 29 13:03:06 2016 From: rich at tehorange.com (Rich Testani) Date: Wed, 29 Jun 2016 09:03:06 -0400 Subject: automated site to site vpn recommendations In-Reply-To: <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: For several of our clients, we use Sophos UTMs coupled with their RED units. Once registered with the UTM, the RED unit auto creates an SSL based VPN back to the UTM. The RED unit is managed from the UTM and pulls it's config when it boots. It's similar to the function of Meraki without the direct cloud management portion, though the config profile does get pushed to a section of Sophos' cloud. -Rich On Wed, Jun 29, 2016 at 8:55 AM, Paul Nash wrote: > My biggest issue with Meraki is that their tech staff can run tcpdump on > the wired or wireless interface of your Meraki box without having to leave > their desk. I have no reason to believe that they are malicious, or in the > pay of the NSA, but I am too paranoid to allow their equipment anywhere > near me. > > Yes, they work well and the cloud control panel makes remote support a > breeze; you have to decide how you feel about the insecurity. > > paul > > > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > > > I would second Meraki for the situation you describe. I don't feel that > > they are the most capable platform, they're expensive, and don't always > > present you with all the information you'd need for troubleshooting. > > However, the VPN offers great dynamic tunneling, instant-on performance, > > and are by far the simplest platform to offer a field person. They're > also > > tenacious - I've had them connect to the cloud management platform and > > build a VPN under some trying circumstances. > > > > From a security standpoint, they will offer features that will impress > for > > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > > tunnel control), and we've found they punch above their weight and their > > APs perform fantastically. > > > > We deploy them worldwide many times per year in similar use cases, > > sometimes with 150 users on the LAN. If your routing is simple, you can > > define your security policies, and don't need crazy throughput on your > VPN, > > Meraki is the way to go. Be careful though: they have to be continually > > licensed to work and can get pretty expensive if you go for the higher > end > > gear. Thus far, we've been able to stick to the cheaper stuff and > > accomplish our goals. > > > > Dan > > > > (end) > > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > > > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > >>> In some cases... > >> > >> The words "in some cases" are a problem with any supposedly plug and > >> play solution. > >> > >>> We really could use a simple solution that you > >>> just flip on, it calls home, and works... > >> > >> ...but still requiring someone to enter credentials of some sort, > >> right? Otherwise you have a device wandering about that provides look > >> -mum-no-hands access to your corporate network. > >> > >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > >> for a wireless dongle or storage, and has a highly-scriptable operating > >> system. Not a bad platform. > >> > >> Regards, K. > >> > >> -- > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> Karl Auer (kauer at biplane.com.au) > >> http://www.biplane.com.au/kauer > >> http://twitter.com/kauer389 > >> > >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > >> > >> > >> > >> > > From bz_siege_01 at hotmail.com Wed Jun 29 18:40:06 2016 From: bz_siege_01 at hotmail.com (c b) Date: Wed, 29 Jun 2016 11:40:06 -0700 Subject: automated site to site vpn recommendations In-Reply-To: References: , <1467064762.2148.41.camel@biplane.com.au>, , <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca>, Message-ID: Guys, thanks for all the responses. Thanks to everyone's feedback, we have a number of options that were not on the original list and that is what I was hoping for. Now it's a matter of comparing cost/learning-curve/support-challenge/compatibility with tools/monitoring, etc... Thanks again. > From: rich at tehorange.com > Date: Wed, 29 Jun 2016 09:03:06 -0400 > Subject: Re: automated site to site vpn recommendations > To: paul at nashnetworks.ca > CC: nanog at nanog.org > > For several of our clients, we use Sophos UTMs coupled with their RED > units. Once registered with the UTM, the RED unit auto creates an SSL > based VPN back to the UTM. The RED unit is managed from the UTM and pulls > it's config when it boots. It's similar to the function of Meraki without > the direct cloud management portion, though the config profile does get > pushed to a section of Sophos' cloud. > > -Rich > > On Wed, Jun 29, 2016 at 8:55 AM, Paul Nash wrote: > > > My biggest issue with Meraki is that their tech staff can run tcpdump on > > the wired or wireless interface of your Meraki box without having to leave > > their desk. I have no reason to believe that they are malicious, or in the > > pay of the NSA, but I am too paranoid to allow their equipment anywhere > > near me. > > > > Yes, they work well and the cloud control panel makes remote support a > > breeze; you have to decide how you feel about the insecurity. > > > > paul > > > > > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > > > > > I would second Meraki for the situation you describe. I don't feel that > > > they are the most capable platform, they're expensive, and don't always > > > present you with all the information you'd need for troubleshooting. > > > However, the VPN offers great dynamic tunneling, instant-on performance, > > > and are by far the simplest platform to offer a field person. They're > > also > > > tenacious - I've had them connect to the cloud management platform and > > > build a VPN under some trying circumstances. > > > > > > From a security standpoint, they will offer features that will impress > > for > > > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > > > tunnel control), and we've found they punch above their weight and their > > > APs perform fantastically. > > > > > > We deploy them worldwide many times per year in similar use cases, > > > sometimes with 150 users on the LAN. If your routing is simple, you can > > > define your security policies, and don't need crazy throughput on your > > VPN, > > > Meraki is the way to go. Be careful though: they have to be continually > > > licensed to work and can get pretty expensive if you go for the higher > > end > > > gear. Thus far, we've been able to stick to the cheaper stuff and > > > accomplish our goals. > > > > > > Dan > > > > > > (end) > > > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > > > > > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > >>> In some cases... > > >> > > >> The words "in some cases" are a problem with any supposedly plug and > > >> play solution. > > >> > > >>> We really could use a simple solution that you > > >>> just flip on, it calls home, and works... > > >> > > >> ...but still requiring someone to enter credentials of some sort, > > >> right? Otherwise you have a device wandering about that provides look > > >> -mum-no-hands access to your corporate network. > > >> > > >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > > >> for a wireless dongle or storage, and has a highly-scriptable operating > > >> system. Not a bad platform. > > >> > > >> Regards, K. > > >> > > >> -- > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> Karl Auer (kauer at biplane.com.au) > > >> http://www.biplane.com.au/kauer > > >> http://twitter.com/kauer389 > > >> > > >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > > >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > > >> > > >> > > >> > > >> > > > > From greg at gregsowell.com Tue Jun 28 19:53:24 2016 From: greg at gregsowell.com (Greg Sowell) Date: Tue, 28 Jun 2016 14:53:24 -0500 Subject: automated site to site vpn recommendations In-Reply-To: <039601d1d159$2d5ae080$8810a180$@superfund.net> References: <1467064762.2148.41.camel@biplane.com.au> <039601d1d159$2d5ae080$8810a180$@superfund.net> Message-ID: Lorenzo did a MUM presentation(https://www.youtube.com/watch?v=VeZetH9uX_Y) on how road warriors can can connect with a Mikrotik to automatically configure VPN. Pretty novel idea using inexpensive hardware. It may not be as user friendly as you need, though. On Tue, Jun 28, 2016 at 11:21 AM, Richard Greasley wrote: > Another option is Checkpoint Edge devices. > We use them worldwide with little to no problems. > They're centrally managed and support central logging which is a plus when > trying to diagnose issues. > They support dynamic IP addresses as well, so just plug it in and you > should be good to go. > Not the cheapest solution, but for sure they get the job done. > > Regards, > Richard. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan Stralka > Sent: Monday, June 27, 2016 6:28 PM > To: Karl Auer > Cc: nanog at nanog.org > Subject: Re: automated site to site vpn recommendations > > I would second Meraki for the situation you describe. I don't feel that > they are the most capable platform, they're expensive, and don't always > present you with all the information you'd need for troubleshooting. > However, the VPN offers great dynamic tunneling, instant-on performance, > and are by far the simplest platform to offer a field person. They're also > tenacious - I've had them connect to the cloud management platform and > build a VPN under some trying circumstances. > > From a security standpoint, they will offer features that will impress for > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > tunnel control), and we've found they punch above their weight and their > APs perform fantastically. > > We deploy them worldwide many times per year in similar use cases, > sometimes with 150 users on the LAN. If your routing is simple, you can > define your security policies, and don't need crazy throughput on your VPN, > Meraki is the way to go. Be careful though: they have to be continually > licensed to work and can get pretty expensive if you go for the higher end > gear. Thus far, we've been able to stick to the cheaper stuff and > accomplish our goals. > > Dan > > (end) > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > > > On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > > In some cases... > > > > The words "in some cases" are a problem with any supposedly plug and > > play solution. > > > > > We really could use a simple solution that you > > > just flip on, it calls home, and works... > > > > ...but still requiring someone to enter credentials of some sort, > > right? Otherwise you have a device wandering about that provides look > > -mum-no-hands access to your corporate network. > > > > MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > > for a wireless dongle or storage, and has a highly-scriptable operating > > system. Not a bad platform. > > > > Regards, K. > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Karl Auer (kauer at biplane.com.au) > > http://www.biplane.com.au/kauer > > http://twitter.com/kauer389 > > > > GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > > Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > > > > -- GregSowell.com TheBrothersWISP.com From eric.kuhnke at gmail.com Wed Jun 29 22:33:10 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 29 Jun 2016 15:33:10 -0700 Subject: automated site to site vpn recommendations In-Reply-To: <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: My biggest issue with Meraki is the fundamentally flawed business model, biased in favor of vendor lock in and endlessly recurring payments to the equipment vendor rather than the ISP or enterprise end user. You should not have to pay a yearly subscription fee to keep your in-house 802.11(abgn/ac) wifi access points operating. The very idea that the equipment you purchased which worked flawlessly on day one will stop working not because it's broken, or obsolete, but because your *subscription* expired... If you want wifi with a centralized controller there's lots of ways to do it at either L2 (Unifi APs and Unifi controller reachable on the same LAN segment as the Unifis, or with its own management vlan), or with Unifi APs programmed to find a controller by hostname/IP address (L3). On Wed, Jun 29, 2016 at 5:55 AM, Paul Nash wrote: > My biggest issue with Meraki is that their tech staff can run tcpdump on > the wired or wireless interface of your Meraki box without having to leave > their desk. I have no reason to believe that they are malicious, or in the > pay of the NSA, but I am too paranoid to allow their equipment anywhere > near me. > > Yes, they work well and the cloud control panel makes remote support a > breeze; you have to decide how you feel about the insecurity. > > paul > > > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > > > I would second Meraki for the situation you describe. I don't feel that > > they are the most capable platform, they're expensive, and don't always > > present you with all the information you'd need for troubleshooting. > > However, the VPN offers great dynamic tunneling, instant-on performance, > > and are by far the simplest platform to offer a field person. They're > also > > tenacious - I've had them connect to the cloud management platform and > > build a VPN under some trying circumstances. > > > > From a security standpoint, they will offer features that will impress > for > > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN > > tunnel control), and we've found they punch above their weight and their > > APs perform fantastically. > > > > We deploy them worldwide many times per year in similar use cases, > > sometimes with 150 users on the LAN. If your routing is simple, you can > > define your security policies, and don't need crazy throughput on your > VPN, > > Meraki is the way to go. Be careful though: they have to be continually > > licensed to work and can get pretty expensive if you go for the higher > end > > gear. Thus far, we've been able to stick to the cheaper stuff and > > accomplish our goals. > > > > Dan > > > > (end) > > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > > > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > >>> In some cases... > >> > >> The words "in some cases" are a problem with any supposedly plug and > >> play solution. > >> > >>> We really could use a simple solution that you > >>> just flip on, it calls home, and works... > >> > >> ...but still requiring someone to enter credentials of some sort, > >> right? Otherwise you have a device wandering about that provides look > >> -mum-no-hands access to your corporate network. > >> > >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB > >> for a wireless dongle or storage, and has a highly-scriptable operating > >> system. Not a bad platform. > >> > >> Regards, K. > >> > >> -- > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> Karl Auer (kauer at biplane.com.au) > >> http://www.biplane.com.au/kauer > >> http://twitter.com/kauer389 > >> > >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > >> > >> > >> > >> > > From sryan at arbor.net Wed Jun 29 22:49:27 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 29 Jun 2016 18:49:27 -0400 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: I treat Meraki like SmartNET. The subscription comes with lifetime support (TAC + Warranty), you do have support on your production network gear don't you? It's not like they trick you going into it either. I for one am a huge fan of the simplicity, it just works. Disclaimer: We use them. ~35 access points all around the world. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Wed, Jun 29, 2016 at 6:33 PM, Eric Kuhnke wrote: > My biggest issue with Meraki is the fundamentally flawed business model, > biased in favor of vendor lock in and endlessly recurring payments to the > equipment vendor rather than the ISP or enterprise end user. > > You should not have to pay a yearly subscription fee to keep your in-house > 802.11(abgn/ac) wifi access points operating. The very idea that the > equipment you purchased which worked flawlessly on day one will stop > working not because it's broken, or obsolete, but because your > *subscription* expired... > > If you want wifi with a centralized controller there's lots of ways to do > it at either L2 (Unifi APs and Unifi controller reachable on the same LAN > segment as the Unifis, or with its own management vlan), or with Unifi APs > programmed to find a controller by hostname/IP address (L3). > > > > On Wed, Jun 29, 2016 at 5:55 AM, Paul Nash wrote: > > > My biggest issue with Meraki is that their tech staff can run tcpdump on > > the wired or wireless interface of your Meraki box without having to > leave > > their desk. I have no reason to believe that they are malicious, or in > the > > pay of the NSA, but I am too paranoid to allow their equipment anywhere > > near me. > > > > Yes, they work well and the cloud control panel makes remote support a > > breeze; you have to decide how you feel about the insecurity. > > > > paul > > > > > On Jun 27, 2016, at 6:28 PM, Dan Stralka wrote: > > > > > > I would second Meraki for the situation you describe. I don't feel that > > > they are the most capable platform, they're expensive, and don't always > > > present you with all the information you'd need for troubleshooting. > > > However, the VPN offers great dynamic tunneling, instant-on > performance, > > > and are by far the simplest platform to offer a field person. They're > > also > > > tenacious - I've had them connect to the cloud management platform and > > > build a VPN under some trying circumstances. > > > > > > From a security standpoint, they will offer features that will impress > > for > > > the price (Sourcefire, inability to use if stolen, 802.1x, and remote > VPN > > > tunnel control), and we've found they punch above their weight and > their > > > APs perform fantastically. > > > > > > We deploy them worldwide many times per year in similar use cases, > > > sometimes with 150 users on the LAN. If your routing is simple, you can > > > define your security policies, and don't need crazy throughput on your > > VPN, > > > Meraki is the way to go. Be careful though: they have to be > continually > > > licensed to work and can get pretty expensive if you go for the higher > > end > > > gear. Thus far, we've been able to stick to the cheaper stuff and > > > accomplish our goals. > > > > > > Dan > > > > > > (end) > > > On Jun 27, 2016 6:01 PM, "Karl Auer" wrote: > > > > > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote: > > >>> In some cases... > > >> > > >> The words "in some cases" are a problem with any supposedly plug and > > >> play solution. > > >> > > >>> We really could use a simple solution that you > > >>> just flip on, it calls home, and works... > > >> > > >> ...but still requiring someone to enter credentials of some sort, > > >> right? Otherwise you have a device wandering about that provides look > > >> -mum-no-hands access to your corporate network. > > >> > > >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, > USB > > >> for a wireless dongle or storage, and has a highly-scriptable > operating > > >> system. Not a bad platform. > > >> > > >> Regards, K. > > >> > > >> -- > > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> Karl Auer (kauer at biplane.com.au) > > >> http://www.biplane.com.au/kauer > > >> http://twitter.com/kauer389 > > >> > > >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > > >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > > >> > > >> > > >> > > >> > > > > > From sethm at rollernet.us Wed Jun 29 23:00:14 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 29 Jun 2016 16:00:14 -0700 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: On 6/29/16 15:33, Eric Kuhnke wrote: > My biggest issue with Meraki is the fundamentally flawed business model, > biased in favor of vendor lock in and endlessly recurring payments to the > equipment vendor rather than the ISP or enterprise end user. > > You should not have to pay a yearly subscription fee to keep your in-house > 802.11(abgn/ac) wifi access points operating. The very idea that the > equipment you purchased which worked flawlessly on day one will stop > working not because it's broken, or obsolete, but because your > *subscription* expired... I'm sure most hardware makers would love to lock in a revenue stream of "keep me working" subscriptions if they could get away with it. From the company's perspective what's not to love about that kind of guaranteed revenue? I often wonder if Microsoft will someday make Office365 the only way to get Office, which if you don't maintain a subscription your locally installed copy of Word will cease to function. ~Seth From kauer at biplane.com.au Wed Jun 29 23:07:45 2016 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 30 Jun 2016 09:07:45 +1000 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: <1467241665.2148.243.camel@biplane.com.au> On Wed, 2016-06-29 at 16:00 -0700, Seth Mattinen wrote: > I often wonder if Microsoft will someday make Office365 the only way > to get Office, which if you don't maintain a subscription your > locally installed copy of Word will cease to function. I live for that day. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 From raphael.timothy at gmail.com Wed Jun 29 23:38:42 2016 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 30 Jun 2016 07:38:42 +0800 Subject: automated site to site vpn recommendations In-Reply-To: References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> Message-ID: <95E5DDD2-1593-40C9-984B-7D2546E14121@gmail.com> There is a downside to subscription pricing for the vendor: they don't get the instant cashflow they're used to. I know Cisco seems to be taking a tactic where only some product lines use subscriptions and the others are on a typical enterprise 3-5 year replacements cycle to provide Cisco with the large cash injections upon upgrade. Tim > On 30 Jun 2016, at 7:00 AM, Seth Mattinen wrote: > >> On 6/29/16 15:33, Eric Kuhnke wrote: >> My biggest issue with Meraki is the fundamentally flawed business model, >> biased in favor of vendor lock in and endlessly recurring payments to the >> equipment vendor rather than the ISP or enterprise end user. >> >> You should not have to pay a yearly subscription fee to keep your in-house >> 802.11(abgn/ac) wifi access points operating. The very idea that the >> equipment you purchased which worked flawlessly on day one will stop >> working not because it's broken, or obsolete, but because your >> *subscription* expired... > > > I'm sure most hardware makers would love to lock in a revenue stream of "keep me working" subscriptions if they could get away with it. From the company's perspective what's not to love about that kind of guaranteed revenue? > > I often wonder if Microsoft will someday make Office365 the only way to get Office, which if you don't maintain a subscription your locally installed copy of Word will cease to function. > > ~Seth From kemp at network-services.uoregon.edu Thu Jun 30 17:04:56 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Thu, 30 Jun 2016 10:04:56 -0700 Subject: route-views.chicago.routeviews.org Message-ID: <34fc5e12-294f-df63-f445-3cd27ff15ff0@network-services.uoregon.edu> As mentioned at the peering personals... route-views.chicago.routeviews.org is now up and running. New peers are welcomed. We request full tables if possible. We send zero back in your direction. Peers should minimally filter default/null/rfc1918 from their view. Our side is: AS6447 206.223.119.187 2001:504:0:4::6447:1 telnet://route-views.chicago.routeviews.org {http/ftp/rsync}://archive.routeviews.org/route-views.chicago A huge thanks to our host, CTS Telecom. Those guys really made it happen. And as always, a huge thanks to Equinix. We could not make this all happen without the help of our hosts and the exchanges, so thanks to all. -- John Kemp RouteViews Network Engineer help at routeviews.org From javier at advancedmachines.us Thu Jun 30 18:35:19 2016 From: javier at advancedmachines.us (Javier J) Date: Thu, 30 Jun 2016 14:35:19 -0400 Subject: AT&T/Bellsouth Fiber Gear In-Reply-To: References: <5772AA15.5000102@caro.net> Message-ID: Haha, I would have done the same thing. If it is important, someone will show up. On Tue, Jun 28, 2016 at 5:58 PM, Carlos Alcantar wrote: > We had a similar situation a couple years ago we went around for weeks > trying to find someone that could help us with the equipment. We ended up > pulling the power on the gear someone showed up 2 hours later. That > finally got us someone we could actually talk with about re locating the > equipment in the building. > > > ? > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > ________________________________________ > From: NANOG on behalf of Morgan A. Miskell < > morgan.miskell at caro.net> > Sent: Tuesday, June 28, 2016 9:47:17 AM > To: nanog at nanog.org > Subject: AT&T/Bellsouth Fiber Gear > > Anyone on this list that can put me in touch with a contact in the > division within AT&T that manages their fiber equipment deployed in the > field? > > I need to speak with someone regarding some AT&T gear in our data center > that is on old Bellsouth Sonet rings...... thanks! > > You can contact me off list via e-mail please! > > -- > Morgan A. Miskell > CaroNet Data Centers > 704-643-8330 x206 > > ---------------------------------------------------------------------------- > The information contained in this e-mail is confidential and is intended > only for the named recipient(s). If you are not the intended recipient > you must not copy, distribute, or take any action or reliance on it. If > you have received this e-mail in error, please notify the sender. Any > unauthorized disclosure of the information contained in this e-mail is > strictly prohibited. > > ---------------------------------------------------------------------------- > > > From nanog at ics-il.net Thu Jun 30 19:41:24 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 30 Jun 2016 14:41:24 -0500 (CDT) Subject: Brocade Fabric Help In-Reply-To: <2108070581.6455.1467315622055.JavaMail.mhammett@ThunderFuck> Message-ID: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> I asked on the Brocade forum, but it's largely been crickets there. I hoped someone here would have an idea. One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) I saw that means, "The DCM Configuration DB is different on both the ends of ISL," but I have no idea how to resolve that. VDX-6720s running 4.1.3b. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From youssef at 720.fr Thu Jun 30 20:09:57 2016 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Thu, 30 Jun 2016 22:09:57 +0200 Subject: Brocade Fabric Help In-Reply-To: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> References: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> Message-ID: Dear Mike, Are you running fabric with logical-chassis mode. Did you set priorities on the rbridges to select selection order of the principal switch ? Did you make any configuration changes from anywhere else than on the principal switch (using cluster VIP to connect) ? IF so, then message seems to point to a configuration difference between nodes hence a possible DB corruption. When that happens, the switchs would rather not join the fabric then try merge and possibly cause configuration alterations and instabilities. You should try to dig that message out on the net or in NOS guides. Maybe open a case with BTAC ? But ultimately, I think you'll probably end up disabling one of the switchs, reset the config and rejoin it in the fabric. HTH. Y. > Le 30 juin 2016 ? 21:41, Mike Hammett a ?crit : > > I asked on the Brocade forum, but it's largely been crickets there. I hoped someone here would have an idea. > > One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) > The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) > > I saw that means, "The DCM Configuration DB is different on both the ends of ISL," but I have no idea how to resolve that. > > > VDX-6720s running 4.1.3b. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > From fred at web2objects.com Thu Jun 30 21:55:46 2016 From: fred at web2objects.com (Fred Hollis) Date: Thu, 30 Jun 2016 23:55:46 +0200 Subject: Brocade Fabric Help In-Reply-To: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> References: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> Message-ID: Hello Mike, Running a few larger Brocade VDX fabrics here... In case of that message, there is no other option not to reset that specific new switch and then re-join the device. I had that a few times, too. It happens when you already did some configuration changes on the new switch and the older fabric members weren't aware of that. On 30.06.2016 at 21:41 Mike Hammett wrote: > I asked on the Brocade forum, but it's largely been crickets there. I hoped someone here would have an idea. > > One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) > The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) > > I saw that means, "The DCM Configuration DB is different on both the ends of ISL," but I have no idea how to resolve that. > > > VDX-6720s running 4.1.3b. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > From liam at fedney.org Thu Jun 30 22:03:39 2016 From: liam at fedney.org (L Sean Kennedy) Date: Thu, 30 Jun 2016 18:03:39 -0400 Subject: [NANOG-announce] NANOG 68 Dallas, TX - Call for Presentations is Open! Message-ID: NANOG Community, The NANOG Program Committee is excited to announce that we are accepting proposals for all sessions at NANOG 68 in Dallas, TX on October 17-19. I have included key points from the Call for Presentations and the complete text is available on the NANOG website: https://www.nanog.org/meetings/nanog68/callforpresentations Early bird registration is open for NANOG 68 and hotel rooms in the NANOG block at the Fairmont Dallas can be reserved by those interested in making advance travel plans. We look forward to seeing all of you in Dallas! https://www.nanog.org/meetings/nanog68/home Sincerely, Sean NANOG Program Committee NANOG 68 Call for Presentations The North American Network Operators' Group (NANOG) will hold its 68th conference in Dallas, TX on October 17-19, 2016. CyrusOne will be the Local Host at NANOG 68. The NANOG Program Committee seeks proposals for presentations, panels, tutorials, and tracks sessions for the NANOG 68 program. We welcome suggestions of keynote speakers or topic ideas. Presentations may cover current technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 68 submissions can be entered on the NANOG Program Committee Tool . How To Submit The primary speaker, moderator, or author should submit a presentation proposal and an abstract on the Program Committee Tool . Please upload draft slides as soon as possible so the Program Committee can understand the intended structure and level of detail covered by the talk. Draft slides are not required for a proposal to be initiated, but they are usually expected before the Program Committee can definitively accept a submission. The following information should be included in the proposal: - Author's name(s) - Professional or Educational Affiliation - A preferred contact email address - A preferred phone number for contact - Submission category (General Session, Panel, Tutorial, or Track) - Presentation Title - Abstract - Slides (attachment), in PowerPoint (preferred), Keynote, or PDF format Timeline for submission and proposal review - Submitter enters Abstract (and draft slides if possible) in Program Committee Tool . - Any time following Call for Presentations and before deadline for Abstracts - PC performs initial review and assigns a ?Shepherd?, who will contact you to help develop the submission. - Within 2 weeks - Submitter develops draft slides of talk - Please submit initial draft slides early - Panels and Track submissions should provide topic list and intended/confirmed participants - PC reviews slides and continues to work with Submitter as needed to develop topic - Draft presentation slides should be submitted prior to published deadline for slides - PC accepts or declines submission - Agenda assembled and posted - Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee , and a representative of the Program Committee will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool without delay! We look forward to reviewing your submission. Key Dates For NANOG 68 Event/Deadline Date Registration for NANOG 68 Opens Monday, 6/27/2016 Agenda Outline for NANOG 68 Posted Monday, 6/27/2016 CFP Deadline #1: Presentation Abstracts Due Monday, 7/25/2016 CFP Deadline #2: Draft Presentation Slides Due Monday, 8/15/2016 CFP Topic List and NANOG Meeting Highlights Page Friday, 8/19/2016 Speaker Final presentation Slides to PC Tool Monday, 10/10/2016 On-site Registration Monday, 10/17/2016 Lightning Talk Submissions Open (Abstracts Only) Sunday, 10/16/2016 Further Presentation Guidelines can be found under "Present at a NANOG" and some general advice is available in Tips on Giving a Talk . The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, and tracks in all areas of network operations, such as: - Network Connectivity, Interconnection, and Architecture - Network Management and Configuration including Automation - Network Performance, Measurement, and Telemetry - Data Center and Physical Plant including Cooling and Power Efficiency - Network Research - Internet Governance - Routing and Switching Protocols - Network Data and Control Plane Security - Optical and Transmission Technologies - Wireless Networks - DNS, Transport, and Applications - Network Operations and Engineering Professional Experiences Submissions are welcomed by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. The NANOG registration fee is waived for: - General Session presentations: the conference registration fee will be waived for a maximum of one speaker. - General Session panels: conference registration fees will be waived for one panel moderator and all panelists. - Tracks: conference registration fees will be waived for one moderator. - Tutorials: conference registration fees will be waived for one instructor. -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From rfg at tristatelogic.com Thu Jun 30 01:08:46 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 29 Jun 2016 18:08:46 -0700 Subject: Malware/ransomware current live distribution points Message-ID: <82245.1467248926@server1.tristatelogic.com> The various domains and IP address listed in the following file are, as we speak, acting as distribution/infection points for some sort of Javascript malware which is almost certainly a flavor of ransomware. ** FAIR WARNING *** Please use exceptional caution when browsing to any of the domains listed within the following file. Doing so with a vlunerable browser and/or from a vulnerable platform is likely to cause encryption of your entire harddrive. Such encryption may perhaps be irreversable without paying a ransom. ftp://ftp.tristatelogic.com/pub/cases/295165/20160629-0.txt I am including below the same information as is present within the above referenced file, but without the associated domain names. I do this in order to avoid having this message improperly filtered, as it might be, by some of the spam filters being used by some of the people who really should see this message. (But the domain names are all readily available in the above file.) Note that the domain names involved in this particular set of malware distributors are all third-level .COM domains, and that in all cases, the actual text of the first (leftmost) of the three domain name labels is irrelevant and can be replaced by any other valid domain name label because the second level domains have all been wildcarded in the DNS. The following list has been sorted numerically, based on the AS number. RIR ASN IP address -------------------------- RIPE 16276 188.165.62.14 RIPE 16276 5.196.36.42 ARIN 19531 155.94.69.167 ARIN 19757 107.155.188.126 ARIN 33182 184.171.243.123 ARIN 33182 184.171.243.81 ARIN 33182 198.136.53.210 ARIN 46562 107.181.174.10 RIPE 47583 195.110.58.82 RIPE 50673 217.12.208.160 RIPE 50979 195.123.209.55 RIPE 51852 141.255.161.67 RIPE 52048 46.183.216.167 RIPE 56322 91.219.237.211 RIPE 56577 31.41.44.155 RIPE 59432 5.134.117.190 RIPE 59729 185.82.216.204 RIPE 62240 185.120.20.107 APNIC 63912 111.221.44.152 RIPE 201133 82.118.226.13 If you are an administrator of one of the above listed ASNs, or if you know someone who is, please spend a few minutes and help get this hostile trash off the Internet. Thank you. Regards, rfg P.S. Those who do elect to browse to the domains listed in the file cited above, and so do so without getting infected, will notice that the underyling actual web sites are all identical, and are all selling a completely bogus diet supplement called "CLA Safflower Oil". It is unclear at this time whether the criminals behind these IPs and domains are making more money from their ransomware extortion racket, or from selling this bogus diet supplement to naive idiots. From jnanog at gmail.com Thu Jun 30 05:43:57 2016 From: jnanog at gmail.com (Rick Astley) Date: Thu, 30 Jun 2016 01:43:57 -0400 Subject: NANOG67 - Tipping point of community and sponsor bashing? In-Reply-To: References: <20160614155024.GB8504@bamboo.slabnet.com> <57603722.4000609@bryanfields.net> <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se> <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net> <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de> Message-ID: I have to agree with Dan in that even if you disagreed with the talk you have to agree that it probably spawned relevant discussion and reflection (both on and off list). I would hate to see a move to ideas and discussions that are chosen simply for offending the fewest people. Another sort of similar critique aimed at large routing vendors was "Help! My big expensive router is really expensive" at NANOG 60 in Atlanta. Perhaps the critiques were seen as more constructive and I don't remember the same backlash after the talk but I found both talks and various discussions that followed insightful. On Fri, Jun 17, 2016 at 4:53 PM, Daniel Golding wrote: > Hmm - as far as whether this was a good or bad NANOG presentation...this is > some of the best discussion I've seen on list in a while. There is a frank > exchange of views between many different parties. This may result in some > follow-up presentations at future NANOGs by IXP operators (please!). > > Seems that, whether you agree with Dave or not, it was successful. It also > seems that the IXP operators who came under the most criticism have reacted > with a lot of professionalism and maturity. Other IXP operators have > reacted pretty poorly, which is ironic. > > Dan > From liltechdude13 at gmail.com Thu Jun 30 02:50:39 2016 From: liltechdude13 at gmail.com (Geoff Wolf AB3LS) Date: Wed, 29 Jun 2016 22:50:39 -0400 Subject: automated site to site vpn recommendations In-Reply-To: <95E5DDD2-1593-40C9-984B-7D2546E14121@gmail.com> References: <1467064762.2148.41.camel@biplane.com.au> <3E963AD5-C2C0-4DD7-A312-A14E57AD4A2A@nashnetworks.ca> <95E5DDD2-1593-40C9-984B-7D2546E14121@gmail.com> Message-ID: I have a feeling that most if not all of the requirements you have could be achieved with a Cisco ISR router running some kind of FlexVPN/DMVPN setup back to a network VPN hub. The ISR G3 series has the option of enabling a built in firewall/IPS. You'd need a RADIUS solution to authenticate the VPN from the spoke router in the field to the hub and also for 802.1X port authentication. Depending upon the number of port's you'd need, a downstream switch may be needed (ISR4331 has optional 4-port PoE switch module). http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-architecture-implementation/200031-Zero-Touch-Deployment-ZTD-of-VPN-Remot.html That said, I think this would be a huge headache compared to what can be done with Meraki. It would also involve a TON of R&D time (believe me). On Wed, Jun 29, 2016 at 7:38 PM, Tim Raphael wrote: > There is a downside to subscription pricing for the vendor: they don't get > the instant cashflow they're used to. I know Cisco seems to be taking a > tactic where only some product lines use subscriptions and the others are > on a typical enterprise 3-5 year replacements cycle to provide Cisco with > the large cash injections upon upgrade. > > Tim > > > On 30 Jun 2016, at 7:00 AM, Seth Mattinen wrote: > > > >> On 6/29/16 15:33, Eric Kuhnke wrote: > >> My biggest issue with Meraki is the fundamentally flawed business model, > >> biased in favor of vendor lock in and endlessly recurring payments to > the > >> equipment vendor rather than the ISP or enterprise end user. > >> > >> You should not have to pay a yearly subscription fee to keep your > in-house > >> 802.11(abgn/ac) wifi access points operating. The very idea that the > >> equipment you purchased which worked flawlessly on day one will stop > >> working not because it's broken, or obsolete, but because your > >> *subscription* expired... > > > > > > I'm sure most hardware makers would love to lock in a revenue stream of > "keep me working" subscriptions if they could get away with it. From the > company's perspective what's not to love about that kind of guaranteed > revenue? > > > > I often wonder if Microsoft will someday make Office365 the only way to > get Office, which if you don't maintain a subscription your locally > installed copy of Word will cease to function. > > > > ~Seth > -- Geoffrey Wolf From tmccleve at voonami.com Thu Jun 30 21:28:10 2016 From: tmccleve at voonami.com (TJ McCleve) Date: Thu, 30 Jun 2016 21:28:10 +0000 Subject: Brocade Fabric Help In-Reply-To: <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> References: <2108070581.6455.1467315622055.JavaMail.mhammett@ThunderFuck> <1217501659.6466.1467315681031.JavaMail.mhammett@ThunderFuck> Message-ID: <4E5E1BF4-F57C-4B66-BDF9-C7D984E0B7FF@voonami.com> I would suggest opening a TAC to get the full details on why it?s happening if the root cause not readily apparent. Typically remediating a these types of mismatches entails copying the default config to startup (triggers a reload) and rejoining the fabric. On 6/30/16, 1:41 PM, "NANOG on behalf of Mike Hammett" wrote: >I asked on the Brocade forum, but it's largely been crickets there. I hoped someone here would have an idea. > >One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) >The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, Distributed Config DB)(Trunk Primary) > >I saw that means, "The DCM Configuration DB is different on both the ends of ISL," but I have no idea how to resolve that. > > >VDX-6720s running 4.1.3b. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > >Midwest Internet Exchange >http://www.midwest-ix.com > >