Add PI via VPN/Tunnelprovider?

[agowa]

Should we add a note to the PI (and conclusion) section that it is also possible to get the PI space routed without the help of the on-link ISP by using a tunneling service?

It was mentioned briefly on the mailing list. I googled for it, and apparently, many LIRs offer it as an "off the shelf" solution. As well as, many cloud providers...

And many of them not only allow for PI prefixes that way but would also provide a PA-prefix. So we would also have an option for a tunneled "on-link ISP independent"-PA prefix. This could solve the "pollutes global routing table" issue as well as "may be dynamically changed by the ISP upon reconnect" and "ISP may charge for routing." However, the traffic flow may be slightly suboptimal. However, a company seeking redundancy probably doesn't care about that.

Providers that offer it:

• https://he.net/ "Get BGP+IPv6+IPv4 for $0.06/Mbps!"
• https://www.servperso.net/ 7.5€/Month IPv6-only and 10€/Month Dual stack, each with 1Gbps OR 160€/year for ASN+IPv6 /44 + BGP VM)
• https://www.webconex.io/services/bgp
• ...

[EduardVasilenko]

For sure, 3rd party tunneling solution would not be accepted by Enterprises. But our document for small business too. SMB could use tunneling service. Typically, SMB/SOHO uses tunneling to get IPv6 over IPv4-only provider. Nothing precludes them to use it for resiliency too. If I would be in need - I would use it.

My proposition is to create the completely new section 5.5 "Centrilized third party tunneling"

[agowa]

For sure, 3rd party tunneling solution would not be accepted by Enterprises.

Why is that? You could as well just have a tunnel to your cloud provider I.E., "Cloud connect" (which many would already have regardless at that point) and route all your traffic through it instead of a split tunnel.

In fact if you have branch offices that topology may even be preferable as you can centralize your routing at a cloud provider/datacenter instead of at your main office...

My proposition is to create the completely new section 5.5 "Centrilized third party tunneling"

We'd have to discuss ordering than again. As we wrote in the conclusion that we listed the approaches in order of preferability. And I'd definitely put this solution before the NPT and NAT ones...

[EduardVasilenko]

Imagine Enterprise that has got PI. They could distribute it statically and create the normal routing network. The fact that some links may be encrypted tunnels over the Intrenet - is not important. They may distribute address space dynamically (over tunnels). I do not see a value in this. Static PI address attachment is much better.

Imagine Enterprise has no address space. They could lease it from cloud providers. Let's call it CA (Cloud Aggregate) in the analogy to PA. Then Enterprise is fully dependent on this cloud provider. Are you sure that any Entetrprise would agree for such deep dependency? What if other cloud provider would not server requests from competitor's address space? What is this cloud provider would restrict (by performance) the access to other OTTs? Your are already loocked - they could do nasty things.

I do not believe that it is a good idea for business to outsource such fundamental thing as "your address". Have you heard about any Enterprise did it? (when internal addressing is leased) Worst case they could use ULA - it would be much better.

SMB/SOHO would not think about this. They would just use it. (and regret about it later) I have no problem to prioritize "Centrilized third party tunneling" above NAT/NPT.

[agowa]

They could distribute it statically and create the normal routing network. The fact that some links may be encrypted tunnels over the Intrenet - is not important

I disagree because we explicitly wrote that a con is that the ISP may not support or upcharge for "normal routing". So we probably should add a note about using a tunnel to a cloud provider or the LIR.

Then Enterprise is fully dependent on this cloud provider. Are you sure that any Entetrprise would agree for such deep dependency?

Enterprises would use case 1 with own PI + tunneling to avoid the limitations of the "on link"-ISP. And this would be mainly for smaller businesses or Homes that want to be multihomed...

What if other cloud provider would not server requests from competitor's address space? What is this cloud provider would restrict (by performance) the access to other OTTs?

This one is out of scope, as anyone within the AS path could do the same. Even if you have a native connection...

Your are already loocked - they could do nasty things.

No, you are not, you could always just fall back to NPT and rewrite their GUA. As realistically you then don't care about being able to reach them anyway...

I do not believe that it is a good idea for business to outsource such fundamental thing as "your address". Have you heard about any Enterprise did it? (when internal addressing is leased)

Depends on how big you define Enterprise, but I know of very big players that outsource to very small IT service providers for "risk management purposes" as they signed a contract to be liable for the risks...

Worst case they could use ULA - it would be much better.

I disagree, it would be worse. That's why I'd like to prioritize it higher.

SMB/SOHO would not think about this. They would just use it. (and regret about it later)

Then pay for a PI using a tunnel instead of a PA using a tunnel... But I agree with you in so far as we should outline the risks and impact of that decision.

Edit: How about this, we suggest getting PI+Tunnel in cases where you cannot get native routing for your PI. The main reason I brought up the get PA+Tunnel was to solve the polluting global routing table problem as it will be aggregated by the provider...

[EduardVasilenko]

My concern is pure organizational ("how bad for middle-size business to outsource address space"). Never to say about the security problem that somebody would have a copy of all your traffic.

I agree that SBM/SOHO would not think about it - they may join a proposition for CA (Cloud Agregated) if it would be from somebody big and respected (like Amazon or Microsoft). They may use it even if it is from somebody well known regionally. Hence, it looks like the section for the new solution is needed.

I do not know what is worse: such a suboptimal traffic path or NAT. Both are bad. Hence, I do not have an objections for this section to be before NAT/NPT.

But does it exist in the real world? Is it already a trend that we could claim as reality? I remember that you have shown couple of URL. Do they have many such clients? It looks for me like an excellent idea for a new Cloud service (especially good for big guys like Amazon or Microsoft). I doubt that it is already a trend. I will research on monday.

[o5edaxi]

I think medium/large enterprises might adopt this solution by using their own HQ or DC as the tunnel provider. Backhauling traffic is of course suboptimal but most overlay connectivity products already do this, and local breakout is optional. Another advantage of this tunneling would be... symmetric traffic steering and total control of the first-mile of the branch 😎

[EduardVasilenko]

Hi Paolo, would you be satisfied if we would add a solution that looks like this: Section 5.x: It is possible to shift the internet resiliency problem to the centralized site of the big enterprise if the branch has a redundant WAN connectivity organized in any other way (SDH/PDH/OTN links, MPLS VPNs, encrypted tunnels). It is typically much easy to arrange the resiliency over internal WAN links with the help of routing. Unfortunately, the disablement of "local Internet breakout" increases the latency for the users on the branch site. On the contrary, a centralized gateway to the Internet permits improved security. Enterprise WAN design is out of the scope of this document.

PS: OTN with the latest granularity 2Mbps is especially popular in China. Not encrypted tunnels over the internet (with SD-WAN management or not).

[o5edaxi]

It definitely seems like an option that many would consider. However, is it distinct enough from PI-based in your opinion? We might also add it in 5.1 as previously mentioned, or flesh it out to a full section. Must also avoid getting too specific about the tunnel type and who the tunnel endpoint is (the HQ vs. a broker, etc.).

[EduardVasilenko]

I do not believe that "shifting a problem from the branch to HQ" is related to PI. The HQ may solve Internet resiliency in a different way. For example, by NAT.

Moreover, I believe that for middle-size companies would be no PI. Because they do not have public IPv4 now. They try to use the current model, i.e. NAT

[o5edaxi]

Totally agree, although if NAT were accepted in the org, then local breakout might seem more attractive than tunneling.

I think we could work on this section and then keep it if it appears to help the overall document.

[EduardVasilenko]

section 5.5 is created.

[EduardVasilenko]

Hi Klaus, while Paolo was trying to discuss the solution in section 5.5 for the "shift multihoming problem to a different part of the network", he elegantly discussed the situation when this "other part" is a "3rd party broker". Please, look at section 5.5. Are you happy about it? Could we close this issue?

Sorry that I have delayed the resolution of this problem - I was busy this week. I had the problem you raised on my list of "to do". But Paolo did it better and faster. Eduard

[agowa]

Sorry that I have delayed the resolution of this problem - I was busy this week. I had the problem you raised on my list of "to do". But Paolo did it better and faster.

No worries, the same applied to me as well. I also had written that section on my to-do list and responded to this earlier. Sometimes real world really could use a pause button 😅

I'll try to have a close look at it today, but from what I've seen so far it looks good.

[agowa]

I'm quite happy with 5.5. Thanks again for writing it.

I opened #32 with some minor editorial enhancements. And sorry again that it took me so long to provide feedback on this.

[EduardVasilenko]

Looks like resolved.