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
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
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
On 2016-06-07 07:23 AM, Davide Davini wrote: 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@supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian
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 <diotonante@gmail.com> 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
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 <diotonante@gmail.com> 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
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 <elvis@velea.eu> 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 <diotonante@gmail.com> 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
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <elvis@velea.eu <javascript:;>> 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 <diotonante@gmail.com <javascript:;>> 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
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 <cb.list6@gmail.com> wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <elvis@velea.eu> 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 <diotonante@gmail.com> wrote:
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
Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I 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
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <cb.list6@gmail.com <javascript:_e(%7B%7D,'cvml','cb.list6@gmail.com');>> wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com <javascript:_e(%7B%7D,'cvml','tknchris@gmail.com');>> 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 <elvis@velea.eu> 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 <diotonante@gmail.com> wrote:
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
Today I discovered Netflix flagged my IPv6 IP block as "proxy/VPN" and I 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
On Jun 7, 2016, at 11:25 PM, Ca By <cb.list6@gmail.com> wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <cb.list6@gmail.com <javascript:_e(%7B%7D,'cvml','cb.list6@gmail.com');>> wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com <javascript:_e(%7B%7D,'cvml','tknchris@gmail.com');>> 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 <elvis@velea.eu> 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 <diotonante@gmail.com> 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 > > >
Once upon a time, Owen DeLong <owen@delong.com> 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 <cma@cmadams.net>
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 <cma@cmadams.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> 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.
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@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 <john-nanog@peachfamily.net> 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 <cma@cmadams.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> 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.
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 <sryan@arbor.net> 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@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 <john-nanog@peachfamily.net> 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 <cma@cmadams.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> 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.
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 <elvis@velea.eu> 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 <sryan@arbor.net> 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@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 <john-nanog@peachfamily.net> 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 <cma@cmadams.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> 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.
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@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@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 <john-nanog@peachfamily.net> 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 <cma@cmadams.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> 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.
On Jun 8, 2016, at 10:37, Spencer Ryan <sryan@arbor.net> 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@feld.me
On 11 June 2016 at 17:04, Mark Felder <feld@feld.me> 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
Ca By wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <elvis@velea.eu <javascript:;>> 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 <diotonante@gmail.com <javascript:;>> 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
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" <alh-ietf@tndh.net> wrote:
Ca By wrote:
On Tuesday, June 7, 2016, chris <tknchris@gmail.com> 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 <elvis@velea.eu <javascript:;>> wrote:
apparently, all they see is 3 people complaining on this mailing
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.. 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 <diotonante@gmail.com <javascript:;>> 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
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
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@nanog.org] On Behalf Of Laszlo Hanyecz Sent: Wednesday, June 8, 2016 3:34 PM To: nanog@nanog.org Subject: Re: Netflix banning HE tunnels
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
On 2016-06-08 18:57, Javier J wrote: 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
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@nanog.org] On Behalf Of Matthew Huff Sent: Wednesday, June 08, 2016 12:45 PM To: Laszlo Hanyecz; nanog@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@nanog.org] On Behalf Of Laszlo Hanyecz Sent: Wednesday, June 8, 2016 3:34 PM To: nanog@nanog.org Subject: Re: Netflix banning HE tunnels
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
On 2016-06-08 18:57, Javier J wrote: 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
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@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@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@nanog.org] On Behalf Of Matthew Huff Sent: Wednesday, June 08, 2016 12:45 PM To: Laszlo Hanyecz; nanog@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@nanog.org] On Behalf Of Laszlo Hanyecz Sent: Wednesday, June 8, 2016 3:34 PM To: nanog@nanog.org Subject: Re: Netflix banning HE tunnels
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
On 2016-06-08 18:57, Javier J wrote: 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
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@arbor.net] Sent: Wednesday, June 8, 2016 4:02 PM To: Tony Hain <alh-ietf@tndh.net> Cc: Matthew Huff <mhuff@ox.com>; Laszlo Hanyecz <laszlo@heliacal.net>; North American Network Operators' Group <nanog@nanog.org> 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@arbor.net<mailto:sryan@arbor.net> Arbor Networks +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com<http://www.arbornetworks.com/> On Wed, Jun 8, 2016 at 4:00 PM, Tony Hain <alh-ietf@tndh.net<mailto:alh-ietf@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@nanog.org<mailto:nanog-bounces@nanog.org>] On Behalf Of Matthew Huff Sent: Wednesday, June 08, 2016 12:45 PM To: Laszlo Hanyecz; nanog@nanog.org<mailto:nanog@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<tel:914-460-4039> aim: matthewbhuff | Fax: 914-694-5669<tel:914-694-5669>
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org>] On Behalf Of Laszlo Hanyecz Sent: Wednesday, June 8, 2016 3:34 PM To: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Netflix banning HE tunnels
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
On 2016-06-08 18:57, Javier J wrote: 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
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 <mhuff@ox.com> 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@arbor.net] Sent: Wednesday, June 8, 2016 4:02 PM To: Tony Hain <alh-ietf@tndh.net> Cc: Matthew Huff <mhuff@ox.com>; Laszlo Hanyecz <laszlo@heliacal.net>; North American Network Operators' Group <nanog@nanog.org> 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@arbor.net<mailto: sryan@arbor.net> Arbor Networks +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com<http://www.arbornetworks.com/>
On Wed, Jun 8, 2016 at 4:00 PM, Tony Hain <alh-ietf@tndh.net<mailto: alh-ietf@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@nanog.org<mailto: nanog-bounces@nanog.org>] On Behalf Of Matthew Huff Sent: Wednesday, June 08, 2016 12:45 PM To: Laszlo Hanyecz; nanog@nanog.org<mailto:nanog@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<tel: 914-460-4039> aim: matthewbhuff | Fax: 914-694-5669<tel:914-694-5669>
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org<mailto: nanog-bounces@nanog.org>] On Behalf Of Laszlo Hanyecz Sent: Wednesday, June 8, 2016 3:34 PM To: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Netflix banning HE tunnels
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
On 2016-06-08 18:57, Javier J wrote: 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
On Jun 8, 2016, at 3:52 PM, Chris Knipe <savage@savage.za.org> 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@newslink.com News Link – Manager Travel, Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular
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 <andy@newslink.com> wrote:
On Jun 8, 2016, at 3:52 PM, Chris Knipe <savage@savage.za.org> 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@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
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 <savage@savage.za.org> 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 <andy@newslink.com> wrote:
On Jun 8, 2016, at 3:52 PM, Chris Knipe <savage@savage.za.org> 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@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
On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff <mhuff@ox.com> 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.)
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@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 <jfbeam@gmail.com> wrote:
On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff <mhuff@ox.com> 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.)
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 <sryan@arbor.net> 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@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 <jfbeam@gmail.com> wrote:
On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff <mhuff@ox.com> 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.)
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 <hvgeekwtrvl@gmail.com> 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 <sryan@arbor.net> 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@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 <jfbeam@gmail.com> wrote:
On Wed, 08 Jun 2016 17:24:48 -0400, Matthew Huff <mhuff@ox.com> 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.)
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
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 <jlightfoot@gmail.com> 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@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.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@nanog.org] On Behalf Of Michael Still Sent: Thursday, June 9, 2016 10:10 AM To: John Lightfoot <jlightfoot@gmail.com> Cc: North American Network Operators' Group <nanog@nanog.org> 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 <jlightfoot@gmail.com> 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@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.com ~]$
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 <mhuff@ox.com> 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@nanog.org] On Behalf Of Michael Still Sent: Thursday, June 9, 2016 10:10 AM To: John Lightfoot <jlightfoot@gmail.com> Cc: North American Network Operators' Group <nanog@nanog.org> 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 <jlightfoot@gmail.com> 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@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.com ~]$
-- [stillwaxin@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.com ~]$
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@gmail.com] Sent: Thursday, June 9, 2016 10:33 AM To: Matthew Huff <mhuff@ox.com> Cc: John Lightfoot <jlightfoot@gmail.com>; North American Network Operators' Group <nanog@nanog.org> 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 <mhuff@ox.com<mailto:mhuff@ox.com>> 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<tel:914-460-4039> aim: matthewbhuff | Fax: 914-694-5669<tel:914-694-5669>
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org>] On Behalf Of Michael Still Sent: Thursday, June 9, 2016 10:10 AM To: John Lightfoot <jlightfoot@gmail.com<mailto:jlightfoot@gmail.com>> Cc: North American Network Operators' Group <nanog@nanog.org<mailto:nanog@nanog.org>> 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 <jlightfoot@gmail.com<mailto:jlightfoot@gmail.com>> 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@gmail.com<mailto:stillwaxin@gmail.com> ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.com<mailto:stillwaxin@gmail.com> ~]$
-- [stillwaxin@gmail.com<mailto:stillwaxin@gmail.com> ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin@gmail.com<mailto:stillwaxin@gmail.com> ~]$
Hi,
Op 8 jun. 2016, om 23:39 heeft John Lightfoot <jlightfoot@gmail.com> 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
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 <sander@steffann.nl> wrote:
Hi,
Op 8 jun. 2016, om 23:39 heeft John Lightfoot <jlightfoot@gmail.com> 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
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 :)
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 <Steve.Mikulasik@civeo.com> 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 :)
On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild <asr@latency.net> 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-...] 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.
In message <op.yita8coctfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild <asr@latency.net> 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@isc.org
On 10 June 2016 at 01:17, Mark Andrews <marka@isc.org> 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
On Thu, 09 Jun 2016 21:41:05 -0400, Baldur Norddahl <baldur.norddahl@gmail.com> 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.
On Jun 9, 2016, at 19:57 , Ricky Beam <jfbeam@gmail.com> wrote:
On Thu, 09 Jun 2016 21:41:05 -0400, Baldur Norddahl <baldur.norddahl@gmail.com> 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
On Sun, 12 Jun 2016 19:47:18 -0400, Owen DeLong <owen@delong.com> 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.
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....
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> wrote:
On Sun, 12 Jun 2016 19:47:18 -0400, Owen DeLong <owen@delong.com> 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
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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
On Jun 20, 2016, at 1:30 PM, Owen DeLong <owen@delong.com> wrote:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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
On Mon, 20 Jun 2016, Jared Mauch wrote:
On Jun 20, 2016, at 1:30 PM, Owen DeLong <owen@delong.com> wrote:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> 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
In message <B950E696-1A72-4166-B615-A68BF30AD4F2@puck.nether.net>, Jared Mauch writes:
On Jun 20, 2016, at 1:30 PM, Owen DeLong <owen@delong.com> wrote:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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 <local-prefixes>/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 <local-prefixes>/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@isc.org
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 <local-prefixes>/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
In message <F7BADD47-3CC9-478C-96DA-A07FCB8CBDBF@delong.com>, 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 <local-prefixes>/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@isc.org
In message <E67D028D-2A66-453C-9D8B-0AC8FEA88131@delong.com>, Owen DeLong writes:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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@isc.org
On Jun 20, 2016, at 13:45 , Mark Andrews <marka@isc.org> wrote:
In message <E67D028D-2A66-453C-9D8B-0AC8FEA88131@delong.com>, Owen DeLong writes:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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
In message <28657BED-E262-452D-B218-7B39B17F36FE@delong.com>, Owen DeLong writes:
On Jun 20, 2016, at 13:45 , Mark Andrews <marka@isc.org> wrote:
In message <E67D028D-2A66-453C-9D8B-0AC8FEA88131@delong.com>, Owen DeLong writes:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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@isc.org
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" <marka@isc.org> wrote:
In message <28657BED-E262-452D-B218-7B39B17F36FE@delong.com>, Owen DeLong writes:
On Jun 20, 2016, at 13:45 , Mark Andrews <marka@isc.org> wrote:
In message <E67D028D-2A66-453C-9D8B-0AC8FEA88131@delong.com>, Owen
DeLong writes:
On Jun 17, 2016, at 10:10 , Mark Milhollan <mlm@pixelgate.net>
wrote:
On Tue, 14 Jun 2016, Owen DeLong wrote:
On Jun 14, 2016, at 11:57 , Ricky Beam <jfbeam@gmail.com> 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@isc.org
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
On 6/20/16, 1:45 PM, "NANOG on behalf of Mark Andrews" <nanog-bounces@nanog.org on behalf of marka@isc.org> 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.
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
On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews <marka@isc.org> 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.)
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@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
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
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.
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@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
On Thursday, June 9, 2016, Randy Bush <randy@psg.com> 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.
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
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*.
Valdis.Kletnieks@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
On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush <randy@psg.com> 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.
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
In message <m2wplwswlw.wl%randy@psg.com>, 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@isc.org
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 <jfbeam@gmail.com> wrote:
On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush <randy@psg.com> 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.
(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 <cryptographrix@gmail.com> 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 <jfbeam@gmail.com> wrote:
On Thu, 09 Jun 2016 23:57:08 -0400, Randy Bush <randy@psg.com> 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.
On Jun 10, 2016, at 11:58 , Cryptographrix <cryptographrix@gmail.com> 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
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@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*
In message <op.yitmccdptfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews <marka@isc.org> 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@isc.org
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.
In message <0e36af3e-9781-4f2b-1080-af915fff3755@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@isc.org
On Friday, 10 June, 2016 05:48, "Mark Foster" <blakjak@blakjak.net> 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.
On Fri, 10 Jun 2016 07:19:22 +0100, "tim@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.
On Jun 10, 2016, at 01:32 , Valdis.Kletnieks@vt.edu wrote:
On Fri, 10 Jun 2016 07:19:22 +0100, "tim@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
On 13 June 2016 at 02:05, Owen DeLong <owen@delong.com> 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
In message <CAPkb-7AMjiVPqTSmTvk7Wa0NW3WysOPhxPyEGhTJ+8O54=UEzw@mail.gmail.com>, Baldur Norddahl writes:
On 13 June 2016 at 02:05, Owen DeLong <owen@delong.com> 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@isc.org
On Mon, 13 Jun 2016 03:27:41 +0200, Baldur Norddahl said:
On 13 June 2016 at 02:05, Owen DeLong <owen@delong.com> 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.
On Jun 12, 2016, at 18:27 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 13 June 2016 at 02:05, Owen DeLong <owen@delong.com> 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
On 13 June 2016 at 10:56, Owen DeLong <owen@delong.com> 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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-4.2>. "::" Usage 4.2.1 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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
On Jun 13, 2016, at 02:16 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 13 June 2016 at 10:56, Owen DeLong <owen@delong.com> 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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-4.2>. "::" Usage 4.2.1 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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 <https://tools.ietf.org/html/rfc5952#section-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
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
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@nanog.org Reply To: elvis@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 <diotonante@gmail.com> 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
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Elvis Daniel Velea Sent: Tuesday, June 07, 2016 6:36 PM To: nanog@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
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
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 <sethm@rollernet.us> 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
On 6/12/16, 8:10 PM, "NANOG on behalf of Seth Mattinen" <nanog-bounces@nanog.org on behalf of sethm@rollernet.us> 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.
participants (42)
-
Adam Rothschild -
Alain Hebert -
Andy Ringsmuth -
Baldur Norddahl -
bzs＠theworld.com -
Ca By -
chris -
Chris Adams -
Chris Knipe -
Chuck Church -
Cryptographrix -
Davide Davini -
Donn Lasher -
Elvis Daniel Velea -
Eric Kuhnke -
Harald Koch -
james machado -
Jared Mauch -
Jason Baugher -
Javier J -
John Lightfoot -
John Peach -
Karl Auer -
Laszlo Hanyecz -
Mark Andrews -
Mark Felder -
Mark Foster -
Mark Milhollan -
Masataka Ohta -
Matthew Huff -
Michael Brown -
Michael Still -
Owen DeLong -
Randy Bush -
Ricky Beam -
Sander Steffann -
Seth Mattinen -
Spencer Ryan -
Steve Mikulasik -
tim＠pelican.org -
Tony Hain -
Valdis.Kletnieks＠vt.edu