I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon@gmail.com -----------------------------------------------------------------------------
On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon@gmail.com> wrote:
I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA?
Yes, you want to deploy it outside your CG-NAT. I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc. Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users. - Jared
On Sep 17, 2018, at 8:48 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon@gmail.com> wrote:
I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA?
Yes, you want to deploy it outside your CG-NAT.
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc.
Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users.
- Jared
Actually, Tik gear fully supports IPv6, so only UBNT gear is really an issue here. Owen
On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote:
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues
Getting IPv6 to your customers is good, but they still have to use it. If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is 5.5:1, while for Google it's 1.1:1 and for Facebook 1.33:1 (peak-time ratios, when traffic is mostly from residential users) . The best explanation I could get is people may use Netflix from devices that do not support IPv6, such as some/most (not-so-old) Smart TVs. There's also the issue of some brain-dead wifi APs that filter or severely limit traffic required for proper IPv6 operation (multicast comes to my mind). I'm not even mentioning the situation in the "pro"/"enterprise" world (much worse) since it doesn't (or it's not supposed to) generate much Netflix traffic (still, during the morning IPv4:IPv6 ratio for Netflix can go as low as 3.5:1). -- R-A.F.
On Tue, Sep 18, 2018 at 1:21 AM Radu-Adrian Feurdean < nanog@radu-adrian.feurdean.net> wrote:
On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote:
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues
Getting IPv6 to your customers is good, but they still have to use it.
If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is 5.5:1, while for Google it's 1.1:1 and for Facebook 1.33:1
(peak-time ratios, when traffic is mostly from residential users) . The
best explanation I could get is people may use Netflix from devices that do not support IPv6, such as some/most (not-so-old) Smart TVs. There's also the issue of some brain-dead wifi APs that filter or severely limit traffic required for proper IPv6 operation (multicast comes to my mind).
so, first: "Thanks for getting v6 to your customers!!" because srsly, some folks (verizon residential dsl/fios) can't seem to make that happen, there's some form of serious magic obviously involved... That said, it's funny that tv's (bluray/etc) are not v6 capable?? ugh :( -chris
FWIW (reviving an old thread)- Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work. We only use BGP to inform our control plane, not for local routing. Any traffic not served via the OCA will go through CGN as usual and out peering/transit. Note that it does complicate troubleshooting for both sides. And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year. -Dave On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch <jared@puck.nether.net> wrote:
On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon@gmail.com> wrote:
I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA?
Yes, you want to deploy it outside your CG-NAT.
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc.
Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users.
- Jared
Thanks Dave, so my local OCA will listen to my BGP advertisements for RFC1918 prefixes if I decided to advertise them? Aaron
On Nov 25, 2018, at 10:47 PM, Dave Temkin <dave@temk.in> wrote:
FWIW (reviving an old thread)-
Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work. We only use BGP to inform our control plane, not for local routing. Any traffic not served via the OCA will go through CGN as usual and out peering/transit. Note that it does complicate troubleshooting for both sides.
And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year.
-Dave
On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch <jared@puck.nether.net> wrote:
On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon@gmail.com> wrote:
I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA?
Yes, you want to deploy it outside your CG-NAT.
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc.
Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users.
- Jared
Not exactly. You don't need to advertise the RFC1918 to the OCA - just make sure you advertise the CGN prefix to it, and make sure that the OCA's default gateway knows how to reach the RFC1918 clients. So long as the "outside" IP of your CGN is advertised to the OCA (the IP that clients who would be using the OCA would appear to the internet as) it should work. Regards, -Dave On Mon, Nov 26, 2018 at 1:04 PM Aaron1 <aaron1@gvtc.com> wrote:
Thanks Dave, so my local OCA will listen to my BGP advertisements for RFC1918 prefixes if I decided to advertise them?
Aaron
On Nov 25, 2018, at 10:47 PM, Dave Temkin <dave@temk.in> wrote:
FWIW (reviving an old thread)-
Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work. We only use BGP to inform our control plane, not for local routing. Any traffic not served via the OCA will go through CGN as usual and out peering/transit. Note that it does complicate troubleshooting for both sides.
And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year.
-Dave
On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch <jared@puck.nether.net> wrote:
On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon@gmail.com> wrote:
I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA?
Yes, you want to deploy it outside your CG-NAT.
I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc.
Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users.
- Jared
On 11/25/2018 09:47 PM, Dave Temkin wrote:
Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work.
Does this include RFC 6598 Shared Address Space, 100.64.0.0/10? Or is it limited to RFC 1918 Address Space? Does it really matter what the private IPs are? (I've seen people re-use publicly allocated but not publicly used IP address space.) Or does it "just work" as long as the OCA's first hop knows how to reach the private IPs? -- Grant. . . . unix || die
On Tue, Nov 27, 2018 at 3:48 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:
On 11/25/2018 09:47 PM, Dave Temkin wrote:
Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work.
Does this include RFC 6598 Shared Address Space, 100.64.0.0/10? Or is it limited to RFC 1918 Address Space?
Does it really matter what the private IPs are? (I've seen people re-use publicly allocated but not publicly used IP address space.) Or does it "just work" as long as the OCA's first hop knows how to reach the private IPs?
The latter. -Dave
On 26/Nov/18 06:47, Dave Temkin wrote:
And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year.
Funny you should mention this... my Sony TV from 2014 has IPv6 support: https://www.youtube.com/watch?v=la9G3bF6rYU But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't currently support IPv6 in 2018 :-(... Mark.
Sony Entertainment is know to be slowpoke in this area. PS4 firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and thus apps doesn't use it at all. Are you sure about ATV4 netflix app? Support is there and I've seen traffic from it when recently did tcpdump from ATV4. On 28/11/18 9:27 am, Mark Tinka wrote:
But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't currently support IPv6 in 2018 :-(...
On Wed, 28 Nov 2018 14:37:06 +0300, Nikolay Shopik said:
Sony Entertainment is know to be slowpoke in this area. PS4 firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and thus apps doesn't use it at all.
Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't notice an unused SLAC address..
On Wed, Nov 28, 2018, at 12:37, Nikolay Shopik wrote:
Are you sure about ATV4 netflix app? Support is there and I've seen traffic from it when recently did tcpdump from ATV4.
Or there is some braindead wifi in-between that does not allow IPv6 to function (or makes it unreliable). Already seens a number of such devices from different vendors.
On 28/Nov/18 16:15, Radu-Adrian Feurdean wrote:
Or there is some braindead wifi in-between that does not allow IPv6 to function (or makes it unreliable). Already seens a number of such devices from different vendors.
I have mine hooked into Cat-6 to my home switch (which has switching IPv6 traffic for all devices that support it). I have IPv6 working over wi-fi for all devices that support it, including iPhones and such. But like I said before, I've seen every device supporting IPv6 to have IPv6 setting bits. Apple TV 4 - my one anyway - does not have this. Only IPv4. Mark.
On 28/Nov/18 13:37, Nikolay Shopik wrote:
Sony Entertainment is know to be slowpoke in this area. PS4 firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and thus apps doesn't use it at all.
Which is what really surprised me with this 2014 TV I have, considering it stopped getting updates about 2 or so years ago.
Are you sure about ATV4 netflix app? Support is there and I've seen traffic from it when recently did tcpdump from ATV4.
Well, my Apple TV interface only has IPv4 bits to show. Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't done an actual wire tap. Mark.
On 11/28/18 8:25 AM, Mark Tinka wrote:
On 28/Nov/18 13:37, Nikolay Shopik wrote:
Sony Entertainment is know to be slowpoke in this area. PS4 firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and thus apps doesn't use it at all.
Which is what really surprised me with this 2014 TV I have, considering it stopped getting updates about 2 or so years ago.
Are you sure about ATV4 netflix app? Support is there and I've seen traffic from it when recently did tcpdump from ATV4.
Well, my Apple TV interface only has IPv4 bits to show.
Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't done an actual wire tap.
Mark.
Vizio also no joy with IPv6. Sigh.
On 28/11/18 5:25 pm, Mark Tinka wrote:
Well, my Apple TV interface only has IPv4 bits to show.
Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't done an actual wire tap.
tvOS doesn't expose IPv6 addresses but it fully supported just like all ios based systems since all apps now required to work in IPv6-only network, otherwise they won't able push update into app store. tvOS will only show IPv6 dns servers in their "Network Settings" tab. They just forgot to update interface for some reason, like they did in back ios10 iirc to show all network configuration including IPv6.
On 28/Nov/18 17:23, Nikolay Shopik wrote:
tvOS will only show IPv6 dns servers in their "Network Settings" tab. They just forgot to update interface for some reason, like they did in back ios10 iirc to show all network configuration including IPv6.
I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6 anywhere on the system. Mark.
So comparing the ARP and ND tables on my Mikrotik home router, I see that my Apple TV, indeed, does have an IPv6 address assigned to it (SLAAC), even though the device, itself, does not display any IPv6 information in its network settings. Then again, Apple never did think an "HDD is Active" blinker on their laptops was ever necessary :-). Mark. On 28/Nov/18 22:10, Mark Tinka wrote:
On 28/Nov/18 17:23, Nikolay Shopik wrote:
tvOS will only show IPv6 dns servers in their "Network Settings" tab. They just forgot to update interface for some reason, like they did in back ios10 iirc to show all network configuration including IPv6. I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6 anywhere on the system.
Mark.
participants (12)
-
Aaron1 -
Bryan Holloway -
Christopher Morrow -
Dave Temkin -
Grant Taylor -
Jared Mauch -
Mark Tinka -
Nikolay Shopik -
Owen DeLong -
Radu-Adrian Feurdean -
Tom Ammon -
valdis.kletnieks＠vt.edu