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
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
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).
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
Thanks Dave, so my local OCA will listen to my BGP advertisements for RFC1918 prefixes if I decided to advertise them?
Aaron
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
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
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.
Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
notice an unused SLAC address..
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.
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 what Sony device? I know they have different OS's for different TV
models, which could have an impact on this...
Mark.
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.
Vizio also no joy with IPv6.
Sigh.
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.
I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6
anywhere on the system.
Mark.