Best US Tunnelbroker for Youtube
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
On Wed, 20 Aug 2014, Ryan Shea wrote:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
I haven't noticed any significant performance degradation to Youtube lately over my HE tunnel. My home ISP is Verizon Fios. Are you experiencing problems _just_ to Youtube, or wider-scale problems in general? If it's the latter, perhaps there's congestion or some other problem between your ISP and HE. jms
On 2014-08-20 16:55, Ryan Shea wrote:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately
Instead of saying that something is "poor", you might want to do the operational/technical[1] thing and include things like: - IPv4 traceroute from your endpoint to the PoP you are using - IPv6 traceroute over the tunnel to the destination that is "poor" And depending on things tcpdump/wireshark might be an amazing tool too. There are apparently some US ISPs who are throttling protocol-41 btw, which might actually be what your problem is. Only data will tell though. I am fairly sure that bringing problems with HE up to them directly or at least on their forums instead of a mailinglist for Network Operators[1] will get you better results...
- so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
For SixXS it all depends on which ISP network you are located in and what PoP you select. If you are west-coast, at the moment, you will likely not get the best performance as there are no PoPs in that area and thus you would have to cut through the country. But more importantly: did you consider asking your ISP for native IPv6? Greets, Jeroen [1] https://www.nanog.org/list
I was attempting to determine the lowest-time-cost path to "happy wife". My candidate paths are "kill v6", "sixxs", "routinghouse" and I was looking for anecdotes that might lead me to test one over another. Yes there are better operational approaches if I ditch the "happy wife" && low-cost (time) concerns, but it certainly seems that the problem of reliable high-quality video streams is more complex than a traceroute/tcpdump are going to indicate. Where is the wireshark button my Chromecast? What is the PoP I am using for this particular video versus another? Is this request filled from Google Global Cache or not? I am choosing not to tilt at these particular windmills. There are not Amazon reviews for tunnel brokers, so yes, I come to an operator mailing list. On Wed, Aug 20, 2014 at 11:05 AM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 16:55, Ryan Shea wrote:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately
Instead of saying that something is "poor", you might want to do the operational/technical[1] thing and include things like: - IPv4 traceroute from your endpoint to the PoP you are using - IPv6 traceroute over the tunnel to the destination that is "poor"
And depending on things tcpdump/wireshark might be an amazing tool too.
There are apparently some US ISPs who are throttling protocol-41 btw, which might actually be what your problem is.
Only data will tell though.
I am fairly sure that bringing problems with HE up to them directly or at least on their forums instead of a mailinglist for Network Operators[1] will get you better results...
- so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
For SixXS it all depends on which ISP network you are located in and what PoP you select. If you are west-coast, at the moment, you will likely not get the best performance as there are no PoPs in that area and thus you would have to cut through the country.
But more importantly: did you consider asking your ISP for native IPv6?
Greets, Jeroen
On 2014-08-20 17:28, Ryan Shea wrote:
I was attempting to determine the lowest-time-cost path to "happy wife".
Does your wife care it is IPv4 or IPv6 or just "funny cat videos"? I think your answer should be clear from that perspective. As somebody eager to post on NANOG though one would think it prudent and a good challenge to figure out what the problem is and actually resolve that problem. You might learn something from it.
My candidate paths are "kill v6", "sixxs", "routinghouse" and I was looking for anecdotes that might lead me to test one over another.
There are these things called search engines, you might know about them. Depending on the exact query though, you might or might not get an appropriate answer. Remember that the US is a rather large country with a very big network, and a very big variance in ISPs hence the answers found will not always match what you will be looking for, especially when you are unable to provide details of your problem.
Yes there are better operational approaches if I ditch the "happy wife" && low-cost (time) concerns, but it certainly seems that the problem of reliable high-quality video streams is more complex than a traceroute/tcpdump are going to indicate.
As the first big leg goes over IPv4, traceroutes and such information can be extremely useful as it might just expose a choke point. That choke point IS something that people on NANOG maybe could do something about. Though the direct thing is to contact your ISP. As you have a tunnel, that means both the IPv4 and IPv6 provider. As an enduser you could also check the various speedtest sites etc. I'll provide you also with the SixXS answer as per google(tunnel is slow): https://www.sixxs.net/faq/connectivity/?faq=slow That lists a variety of other things to look at. Definitely meant for end-users though, not operators. You can also ask around on Freenode's IPv6 channel http://webchat.freenode.net/?channels=ipv6&uio=d4 Lots of knowledgeable people there who can help you debug the issue.
Where is the wireshark button my Chromecast?
Does your Chromecast terminate the tunnel? As you seem to have a @google.com address, you might want to ask internally about that feature.
What is the PoP I am using for this particular video versus another? Is this request filled from Google Global Cache or not? I am choosing not to tilt at these particular windmills.
It seems you pick the other meaning of PoP. The meaning I referred to was the Tunnel Broker's PoP, see also: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers And yes, indeed, if you have network issues on the IPv4 leg between your host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) then that will also affect your IPv6 traffic. It is surprising that you have to ask on NANOG about the other kind of PoP (the google kind), as well, you could ask your colleagues about that who will be much more able to answer those kind of questions.
There are not Amazon reviews for tunnel brokers, so yes, I come to an operator mailing list.
Amazon does not sell those things. Also, depending on the setup chosen, you'll find a wide variety of (Tunnel Broker) PoPs and thus they all affect what one might actually be reviewing, hence, better to ask directly at the provider in question. Greets, Jeroen
For the record, I would leave my wife if I found her watching funny cat videos. V6 would increase the settlement amount, but she would be history. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jeroen Massar <jeroen@massar.ch> Date: 08/20/2014 8:45 AM (GMT-08:00) To: Ryan Shea <ryanshea@google.com> Cc: nanog list <nanog@nanog.org> Subject: Re: Best US Tunnelbroker for Youtube On 2014-08-20 17:28, Ryan Shea wrote:
I was attempting to determine the lowest-time-cost path to "happy wife".
Does your wife care it is IPv4 or IPv6 or just "funny cat videos"? I think your answer should be clear from that perspective. As somebody eager to post on NANOG though one would think it prudent and a good challenge to figure out what the problem is and actually resolve that problem. You might learn something from it.
My candidate paths are "kill v6", "sixxs", "routinghouse" and I was looking for anecdotes that might lead me to test one over another.
There are these things called search engines, you might know about them. Depending on the exact query though, you might or might not get an appropriate answer. Remember that the US is a rather large country with a very big network, and a very big variance in ISPs hence the answers found will not always match what you will be looking for, especially when you are unable to provide details of your problem.
Yes there are better operational approaches if I ditch the "happy wife" && low-cost (time) concerns, but it certainly seems that the problem of reliable high-quality video streams is more complex than a traceroute/tcpdump are going to indicate.
As the first big leg goes over IPv4, traceroutes and such information can be extremely useful as it might just expose a choke point. That choke point IS something that people on NANOG maybe could do something about. Though the direct thing is to contact your ISP. As you have a tunnel, that means both the IPv4 and IPv6 provider. As an enduser you could also check the various speedtest sites etc. I'll provide you also with the SixXS answer as per google(tunnel is slow): https://www.sixxs.net/faq/connectivity/?faq=slow That lists a variety of other things to look at. Definitely meant for end-users though, not operators. You can also ask around on Freenode's IPv6 channel http://webchat.freenode.net/?channels=ipv6&uio=d4 Lots of knowledgeable people there who can help you debug the issue.
Where is the wireshark button my Chromecast?
Does your Chromecast terminate the tunnel? As you seem to have a @google.com address, you might want to ask internally about that feature.
What is the PoP I am using for this particular video versus another? Is this request filled from Google Global Cache or not? I am choosing not to tilt at these particular windmills.
It seems you pick the other meaning of PoP. The meaning I referred to was the Tunnel Broker's PoP, see also: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers And yes, indeed, if you have network issues on the IPv4 leg between your host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) then that will also affect your IPv6 traffic. It is surprising that you have to ask on NANOG about the other kind of PoP (the google kind), as well, you could ask your colleagues about that who will be much more able to answer those kind of questions.
There are not Amazon reviews for tunnel brokers, so yes, I come to an operator mailing list.
Amazon does not sell those things. Also, depending on the setup chosen, you'll find a wide variety of (Tunnel Broker) PoPs and thus they all affect what one might actually be reviewing, hence, better to ask directly at the provider in question. Greets, Jeroen
IRC is a good suggestion, thanks. They'll likely be helpful. I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections). Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution. I just tried poking at iPerf, but my client and server are wildly different versions and it seems to be lying to me about my speed (14748046472308289536 Bytes/sec) To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels. You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug? Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent. On Wed, Aug 20, 2014 at 11:43 AM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 17:28, Ryan Shea wrote:
I was attempting to determine the lowest-time-cost path to "happy wife".
Does your wife care it is IPv4 or IPv6 or just "funny cat videos"?
I think your answer should be clear from that perspective.
As somebody eager to post on NANOG though one would think it prudent and a good challenge to figure out what the problem is and actually resolve that problem. You might learn something from it.
My candidate paths are "kill v6", "sixxs", "routinghouse" and I was looking for anecdotes that might lead me to test one over another.
There are these things called search engines, you might know about them.
Depending on the exact query though, you might or might not get an appropriate answer.
Remember that the US is a rather large country with a very big network, and a very big variance in ISPs hence the answers found will not always match what you will be looking for, especially when you are unable to provide details of your problem.
Yes there are better operational approaches if I ditch the "happy wife" && low-cost (time) concerns, but it certainly seems that the problem of reliable high-quality video streams is more complex than a traceroute/tcpdump are going to indicate.
As the first big leg goes over IPv4, traceroutes and such information can be extremely useful as it might just expose a choke point.
That choke point IS something that people on NANOG maybe could do something about. Though the direct thing is to contact your ISP. As you have a tunnel, that means both the IPv4 and IPv6 provider.
As an enduser you could also check the various speedtest sites etc.
I'll provide you also with the SixXS answer as per google(tunnel is slow): https://www.sixxs.net/faq/connectivity/?faq=slow
That lists a variety of other things to look at. Definitely meant for end-users though, not operators.
You can also ask around on Freenode's IPv6 channel http://webchat.freenode.net/?channels=ipv6&uio=d4
Lots of knowledgeable people there who can help you debug the issue.
Where is the wireshark button my Chromecast?
Does your Chromecast terminate the tunnel?
As you seem to have a @google.com address, you might want to ask internally about that feature.
What is the PoP I am using for this particular video versus another? Is this request filled from Google Global Cache or not? I am choosing not to tilt at these particular windmills.
It seems you pick the other meaning of PoP.
The meaning I referred to was the Tunnel Broker's PoP, see also: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
And yes, indeed, if you have network issues on the IPv4 leg between your host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) then that will also affect your IPv6 traffic.
It is surprising that you have to ask on NANOG about the other kind of PoP (the google kind), as well, you could ask your colleagues about that who will be much more able to answer those kind of questions.
There are not Amazon reviews for tunnel brokers, so yes, I come to an operator mailing list.
Amazon does not sell those things.
Also, depending on the setup chosen, you'll find a wide variety of (Tunnel Broker) PoPs and thus they all affect what one might actually be reviewing, hence, better to ask directly at the provider in question.
Greets, Jeroen
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"? If so, then you have just nicely excluded that the tunnel is NOT the problem. Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there. Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross. Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine? Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark). [..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively. NANOG has operators who have been running native IPv6 for over a decade. Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs. Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers. Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks? Greets, Jeroen
Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details. Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app). I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem. On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"?
If so, then you have just nicely excluded that the tunnel is NOT the problem.
Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there.
Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross.
Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine?
Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark).
[..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively.
NANOG has operators who have been running native IPv6 for over a decade.
Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs.
Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers.
Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks?
Greets, Jeroen
On Wed, Aug 20, 2014 at 01:26:37PM -0400, Ryan Shea wrote:
video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
Happy Eyeballs is only about TCP session setup race, not how the established session performs. Normally with bias (headstart) for IPv6, sometimes (Apple) egoistic and reckless without. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Sorry, I wasn't clear. When my tunnel is not functioning correctly my end hosts still have global v6 addresses and a route. The v6 tcp connections would fail entirely, so v4 would handily win a tcp setup race. A v4-only client does not experience huge delays in video loading. I'm not sure happy eyeballs is implemented in Android. On Wed, Aug 20, 2014 at 1:36 PM, Daniel Roesen <dr@cluenet.de> wrote:
On Wed, Aug 20, 2014 at 01:26:37PM -0400, Ryan Shea wrote:
video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
Happy Eyeballs is only about TCP session setup race, not how the established session performs. Normally with bias (headstart) for IPv6, sometimes (Apple) egoistic and reckless without.
Best regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Wed, Aug 20, 2014 at 1:26 PM, Ryan Shea <ryanshea@google.com> wrote:
Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details.
i have this: yt_ that I should add to a code.google.com location... and will ship you a copy tomorrow of as well. Running this on my home fios + he-tunnel bits now to see what result come out. I'd report that the YT homepage seems to be 'super slow' loading and that when I stream: <https://www.youtube.com/watch?v=LDZX4ooRsWs> (was on the YT homepage as a featured video.. though I am a sucker for the song....) I seem to stream from: 2607:f8b0:400d:c06::81 qh-in-x81.1e100.net. that's not TOO far off my homebase, so... it seems reasonable for a geolocation choice.
Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem.
i think jjb's report was that 'all' of comcast (consumer at least) is v6 capable... as a point of reference. I expect the heat-death of the universe before fiosv6 happens though. (back on that 'simply embarassing' commentary from 8+ months ago, of course) -chris
On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"?
If so, then you have just nicely excluded that the tunnel is NOT the problem.
Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there.
Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross.
Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine?
Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark).
[..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively.
NANOG has operators who have been running native IPv6 for over a decade.
Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs.
Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers.
Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks?
Greets, Jeroen
On Wed, Aug 20, 2014 at 4:59 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
i have this: yt_
funny... part of the filename disappeared here :( ./yt_troubleshooting.py
that I should add to a code.google.com location... and will ship you a copy tomorrow of as well. Running this on my home fios + he-tunnel bits now to see what result come out.
I'd report that the YT homepage seems to be 'super slow' loading and that when I stream: <https://www.youtube.com/watch?v=LDZX4ooRsWs> (was on the YT homepage as a featured video.. though I am a sucker for the song....)
I seem to stream from: 2607:f8b0:400d:c06::81 qh-in-x81.1e100.net.
apologies, if I change the 720p I start streaming from: 2607:f8b0:4004:1b::6 which is much closer to verizon-land, so my packets go: me -> verizon -> he -> google -> he -> verizon -> me I'm betting that in one direction or the other the he/verizon links are no-bueno :(
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients? Thanks - Fred fred.l.templin@boeing.com
If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication. Jared Mauch
On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients?
Thanks - Fred fred.l.templin@boeing.com
My clients typically do DHCP authentication in order to have the ability to tell which user has which IP at what time. The challenge with doing this with IPv6 is that the original DHCPv6 spec has no provision for there to be any unique identifier that can be tied to a particular user like DHCPv4 does. RFC 6939 defines a way to fix that, but I have yet to see it implemented by anything. thanks, -Randy ----- Original Message -----
If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication.
Jared Mauch
On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients?
Thanks - Fred fred.l.templin@boeing.com
Hi Jared, I am assuming 802.1x (or equivalent) security at L2, but the "link" between my DHCPv6 client and server is actually a tunnel that may travel over many network layer hops. So, it is possible for legitimate client A to have its leases canceled by rogue client B unless DHCPv6 auth or something similar is used. Yes, rogue client B would also have to be authenticated to connect to the network the same as legitimate client A, but it could be an "insider attack" (e.g., where B is a disgruntled employee trying to get back at a corporate adversary A). Thanks - Fred fred.l.templin@boeing.com
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Wednesday, August 20, 2014 5:14 PM To: Templin, Fred L Cc: nanog list Subject: Re: DHCPv6 authentication
If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication.
Jared Mauch
On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients?
Thanks - Fred fred.l.templin@boeing.com
I similarly was counting on 802.1x + RA-Guard and other techniques. I can easier do an insider attack by gaining console or connecting to a trusted wire as most places I've seen don't do 802.1x on wired but do on wireless. I'm not going to enumerate the universe for the sake of 6man/dhc or v6ops, and this seems like a futile effort. - Jared (who sometimes runs a network) On Thu, Aug 21, 2014 at 03:46:18AM +0000, Templin, Fred L wrote:
Hi Jared,
I am assuming 802.1x (or equivalent) security at L2, but the "link" between my DHCPv6 client and server is actually a tunnel that may travel over many network layer hops. So, it is possible for legitimate client A to have its leases canceled by rogue client B unless DHCPv6 auth or something similar is used. Yes, rogue client B would also have to be authenticated to connect to the network the same as legitimate client A, but it could be an "insider attack" (e.g., where B is a disgruntled employee trying to get back at a corporate adversary A).
Thanks - Fred fred.l.templin@boeing.com
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Wednesday, August 20, 2014 5:14 PM To: Templin, Fred L Cc: nanog list Subject: Re: DHCPv6 authentication
If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication.
Jared Mauch
On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients?
Thanks - Fred fred.l.templin@boeing.com
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Hi, the question is simply whether anyone is using, or knows of any use of) DHCPv6 Authentication. Does it work? What is the operational experience? Thanks - Fred fred.l.templin@boeing.com
Hi, the question is simply whether anyone is using, or knows of any use of) DHCPv6 Authentication.
Given the responses thus far, my guess would be "no". On Thu, 21 Aug 2014 12:14:57 +0000, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi, the question is simply whether anyone is using, or knows of any use of) DHCPv6 Authentication. Does it work? What is the operational experience?
Thanks - Fred fred.l.templin@boeing.com
-- Hugo
FWIW, loading up a lovely 1080p video now at a time when I am guessing the HE/VZ links are running a little more hot than not and I'm getting perfect playback and nload is showing that I hit a max of 67.9Mb/s on my tunnel. I have not tested with _all_ full hd cat videos, but that sounds like a good challenge for tonight. On Wed, Aug 20, 2014 at 5:03 PM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Wed, Aug 20, 2014 at 4:59 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
i have this: yt_
funny... part of the filename disappeared here :( ./yt_troubleshooting.py
that I should add to a code.google.com location... and will ship you a copy tomorrow of as well. Running this on my home fios + he-tunnel bits now to see what result come out.
I'd report that the YT homepage seems to be 'super slow' loading and that when I stream: <https://www.youtube.com/watch?v=LDZX4ooRsWs> (was on the YT homepage as a featured video.. though I am a sucker for the song....)
I seem to stream from: 2607:f8b0:400d:c06::81 qh-in-x81.1e100.net.
apologies, if I change the 720p I start streaming from: 2607:f8b0:4004:1b::6
which is much closer to verizon-land, so my packets go: me -> verizon -> he -> google -> he -> verizon -> me
I'm betting that in one direction or the other the he/verizon links are no-bueno :(
My understanding is that almost all of the Comcast network is now IPv6 capable. Owen On Aug 20, 2014, at 10:26 AM, Ryan Shea <ryanshea@google.com> wrote:
Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details.
Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem.
On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"?
If so, then you have just nicely excluded that the tunnel is NOT the problem.
Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there.
Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross.
Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine?
Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark).
[..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively.
NANOG has operators who have been running native IPv6 for over a decade.
Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs.
Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers.
Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks?
Greets, Jeroen
Someone was telling me this weekend their entire network is native dual stack now. I haven't had a chance to confirm it yet, but he said they are issuing /60's to residential users using DHCPv6. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG@ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Tue, Aug 26, 2014 at 8:42 PM, Owen DeLong <owen@delong.com> wrote:
My understanding is that almost all of the Comcast network is now IPv6 capable.
Owen
On Aug 20, 2014, at 10:26 AM, Ryan Shea <ryanshea@google.com> wrote:
Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details.
Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem.
On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"?
If so, then you have just nicely excluded that the tunnel is NOT the problem.
Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there.
Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross.
Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine?
Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark).
[..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively.
NANOG has operators who have been running native IPv6 for over a decade.
Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs.
Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers.
Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks?
Greets, Jeroen
On Tue, 26 Aug 2014 21:17:14 -0400, ITechGeek said:
Someone was telling me this weekend their entire network is native dual stack now. I haven't had a chance to confirm it yet, but he said they are issuing /60's to residential users using DHCPv6.
I believe the status is "every residential customer should be able to get a /60 via DHCPv6-PD". It's worked for me for a while, and somebody official from Comcast posted a while ago that they'd finished rolling out to 100% of the residential network. If it isn't working, it's time to complain (and hope you get a level-1 guy who knows what IPv6 is. :)
On Tue, Aug 26, 2014 at 9:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
hope you get a level-1 guy who knows what IPv6 is
Is that possible? ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG@ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net
In message <CAN2EnhCBRR6qS4PWPG9UkQF3SqkPjJw9cXEqu+1uVhM26PcJEQ@mail.gmail.com> , ITechGeek writes:
Someone was telling me this weekend their entire network is native dual stack now. I haven't had a chance to confirm it yet, but he said they are issuing /60's to residential users using DHCPv6.
The residential network in fully IPv6 capable. The commercial network is still a work in progress. This is based on the last notice I saw from Comcast. Mark
----------------------------------------------------------------------------- ------------------ -ITG (ITechGeek) ITG@ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net
On Tue, Aug 26, 2014 at 8:42 PM, Owen DeLong <owen@delong.com> wrote:
My understanding is that almost all of the Comcast network is now IPv6 capable.
Owen
On Aug 20, 2014, at 10:26 AM, Ryan Shea <ryanshea@google.com> wrote:
Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details.
Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app).
I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem.
On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-08-20 18:21, Ryan Shea wrote:
IRC is a good suggestion, thanks. They'll likely be helpful.
I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections).
Does that path between your $home and $server go over the tunnel you find so "slow"?
If so, then you have just nicely excluded that the tunnel is NOT the problem.
Hence, why traceroutes would be so extremely useful.
Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution.
google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there.
Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross.
Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine?
Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark).
[..]
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
Tunnels are for endusers who still are at ISPs who don't do IPv6 natively.
NANOG has operators who have been running native IPv6 for over a decade.
Hence, StackExchange might be useful for your purpose.
You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug?
My cat videos are streaming perfectly fine...
Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent.
Interesting, I was not aware they did not care about their eyeballs.
Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers.
Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks?
Greets, Jeroen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 8/20/14 9:21 AM, Ryan Shea wrote:
To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels.
... and the suggestion you've received several times now is, "reach out to HE, as they are quite responsive." Good luck, Doug
Ryan Shea wrote on 8/20/2014 9:55 AM:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead. I've found HE's support to be surprisingly responsive, even to non (paying) customers. You might reach out to them.
--Blake
On Wed, Aug 20, 2014 at 7:55 AM, Ryan Shea <ryanshea@google.com> wrote:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
You might also consider trying alternate sources of video streams such as screen.yahoo.com to see if your cat video bliss might be better fulfilled through a different source than Youtube, if indeed the problem lies between you and Youtube. Matt
I expect it would work (ignoring the obvious reasons this is likely not to lead to bliss) - but not for the reasons expected. I get a AAAA back from screen.yahoo.com, but the actual video stream (which I am largely guessing is the "big" content I see in iftop coming from yahoo's CDN) comes over v4. At least it is better than vimeo's, A-only. On Sun, Aug 24, 2014 at 6:46 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Wed, Aug 20, 2014 at 7:55 AM, Ryan Shea <ryanshea@google.com> wrote:
Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead.
You might also consider trying alternate sources of video streams such as screen.yahoo.com to see if your cat video bliss might be better fulfilled through a different source than Youtube, if indeed the problem lies between you and Youtube.
Matt
participants (19)
-
Alex Howells -
Blake Hudson -
Christopher Morrow -
Daniel Roesen -
Doug Barton -
Hugo Slabbert -
ITechGeek -
Jared Mauch -
Jared Mauch
-
Jeroen Massar -
Justin M. Streiner -
Mark Andrews -
Matthew Petach -
Owen DeLong -
Randy Carpenter -
Ryan Shea -
Templin, Fred L -
Valdis.Kletnieks＠vt.edu -
Warren Bailey