netflix OCA in a CG-NAT world

Mon Nov 26 04:47:39 UTC 2018

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 at puck.nether.net> wrote:

>
>
> > On Sep 17, 2018, at 6:54 AM, Tom Ammon <thomasammon at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181126/f3785345/attachment.html>