Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] IPv6 and some cloud providers

Mark Tinka mark.tinka at seacom.mu
Mon Jun 1 07:40:05 UTC 2020




On 1/Jun/20 05:39, Owen DeLong wrote:


> So you are providing the network infrastructure… You said “hard to control… when…”.

>

> But you are in control of the network they attach to, so it’s not hard to control, it’s just potentially economically disadvantageous.

>

> I’m not saying you’re making the wrong decision, just questioning your original claim that you were incapable of controlling the situation.


You are overthinking my comment, Owen. Let me simplify it:

Just because we can transport IPv6 traffic, doesn't mean the customers
will automatically (want to) turn it on their side. The only thing we
can control is our IPv6 network. We can't force the customer to
implement IPv6 on their network, even if we provide them with all the IP
addresses to do so.



> To the best of my knowledge, Facebook has expressed a strong preference for third parties to deliver their services to Facebook via IPv6.


AFAIK, Facebook don't offer bare metal cloud services.



>

> I don’t think “3rd parties delivering service” applies in the case of Youtube, Netflix.


Those are not cloud providers. Those are simply content providers.



> Not sure i the case of Google.


Google Cloud provides bare metal services.



>

> Is there some content system you are referring to that has gone IPv6 on their backend and front end, but remains IPv4-only to their third-party APIs?

>

> If so, let’s call them out and bring some pressure to correct that.


You're missing my message, Owen.

All major cloud providers can support IPv6. But if they offer a customer
a bare metal service, they cannot make that customer turn on IPv6 on the
OS and applications they deploy.

Hopefully that is clearer enough.

Mark.




More information about the RPD mailing list