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