private peering

[acrg]

Hi,

Firstly, huge thanks to the good people at HE for providing their professional tunnel brokering service for free for all this time!

I'm posting to ask HE's policy regarding private peering with the IPv6 prefixes they allocate tunnel users.  My situation: I'm in Africa where international Internet access is slow, and IPv6 is scarce, but there are a handful of us who are starting to think about peering privately with tunnels (and other means) to avoid the high RTT of routing via EU/US.  By "us" I mean a collection of South African entities ranging from individuals like me, and small-medium ISPs with their own ASNs and IPv6 space.

Do you have a policy for authorising private peering of your IP space?


Thanks,
Aragon

[broquea]

For the peering session itself? Why not use Link-Locals or ULA rather than an allocation registered to a company if its just for use with private peering.

[acrg]

For the peering session itself?

No, more so from the perspective of exchanging routes with one another so that, for instance, traffic to my HE prefix (from local peers here) flows via the private peering sessions rather than international transit.

[kasperd]

This is all the terms has to say on that matter:

Addresses assigned to Customer by Hurricane may only be used in association with the service under which they were assigned and only while a Hurricane Electric customer.

The wording is a bit vague. What does in association with cover? I expect that every host and network you give addresses out of the HE provided address space will still route some of its traffic through the tunnel service, so the addresses would have been assigned in association with the service. The terms don't require you to have every single packet used with those addresses go through the tunnel service. Packets between two hosts on your LAN with addresses out of the same prefix assigned from HE, will never reach the tunnel service.

Enough about the wording of the terms, lets for a moment consider what the intent of that sentence might be. I think what that sentence is mainly supposed to disallow is the following situation. You register a tunnel and get a /48 assigned. But instead of using the tunnel service at all, you publish that prefix through a BGP peering, which could in theory reach all of the world. Being a more specific route than the one published by HE, it would attract the traffic. Such usage would clearly be a violation of the terms. And if that's how you want to use the address space, then you should be getting address space from a RIR, not from HE.

So I have given one example, which is clearly permitted, and another which is clearly not. Your question is about a setup which is somewhere between those two extremes. It would be nice with an official response about where that line is drawn. There are two questions that seem important in answering the question about which side of the line you are on:

• Do you have a tunnel to the tunnel server?
• Are you advertising the addresses through BGP?

If the answer to those questions are, yeas you do have the tunnel, and no you are not advertising the prefix through BGP, then I cannot think of a reason for HE to say you are on the wrong side of the line.

The traffic that goes through the peering would never touch any of HE's systems, and as such I'd say it should be outside of the scope of the agreement. And apart from the one sentence mentioned above, I couldn't find anything in the terms that would apply to your setup.

I don't know if you would intend to use BGP for your peerings, and I think HE will consider that important. Even if you don't intend those prefixes to leak outside of your peering, there is always a risk of that happening by accident.

[acrg]

Thank you for the great summation!

So I have given one example, which is clearly permitted, and another which is clearly not. Your question is about a setup which is somewhere between those two extremes. It would be nice with an official response about where that line is drawn. There are two questions that seem important in answering the question about which side of the line you are on:

• Do you have a tunnel to the tunnel server?
• Are you advertising the addresses through BGP?

My HE tunnel will always stay.  If I get international transit through someone else, I'll renumber into their range.

As for BGP, I'd guess that some of the ISPs will definitely be exchanging prefixes with it, or some other routing protocol.

[kasperd]

As for BGP, I'd guess that some of the ISPs will definitely be exchanging prefixes with it, or some other routing protocol.

An ISP that does not make use of BGP seems somewhat unlikely. The question is, would any of the HE prefixes be announced over BGP? Would they be announced with some other routing protocol, that could potentially be fed into BGP? How exactly do you intend to setup the peerings in the first place?

Would the individuals, who take part in such peerings with address space from a tunnel provider, be running any BGP sessions? Or do they register a static peering configuration with ISPs? Are the peerings going to be physical links or 6in4 tunnels? (The last questions probably isn't important policy-wise, but it may help understand what kind of setup you have in mind)

[acrg]

The question is, would any of the HE prefixes be announced over BGP?

I think BGP is a bit of a loaded term.  On the one hand, it's just a routing protocol.  Local ISPs here will be using it to announce routes to each other across private and public peering points.  On the other hand, it's also the routing protocol from which the global routing table is built by carriers.  The intention is not to announce any HE prefixes to the global routing table.  If that were to happen by accident, it would be considered an error and rectified.  The ISPs in question are trying to do this for free for the sake of more efficient routing, not to provide free intl transit.

How exactly do you intend to setup the peerings in the first place?

I'm just one player so I can't speak for everyone else, but I would use a 6in4 tunnel to a local ISP here and collect other local prefixes by whatever means they prescribe while keeping my v6 default route via my HE tunnel.

Would the individuals, who take part in such peerings with address space from a tunnel provider, be running any BGP sessions?

Some will, some won't.  In the case of a local ISP providing someone with both address space and intl transit, a BGP session wouldn't be relevant.

Are the peerings going to be physical links or 6in4 tunnels?

Both.

[kasperd]

The intention is not to announce any HE prefixes to the global routing table.  If that were to happen by accident, it would be considered an error and rectified.  The ISPs in question are trying to do this for free for the sake of more efficient routing, not to provide free intl transit.

That's also the impression I had all along. Even nobody intend to route them to the global routing table in your setup, there is always a risk that it can happen by mistake. I won't try to asses that risk neither how much it grows by using BGP for both purposes. This risk is the only reason I can think of that HE could have for saying no.

The ISPs shouldn't be announcing those prefixes upstream. Taking prefixes from a peer and announcing them to your upstream just doesn't make sense economically. Additionally the upstreams of those ISPs should have filters in place, that would filter those routes even if they did leak by accident. Finally if both companies screw up and the routes do leak, the packets will still end up on the same network eventually as they would have done in the first place. So personally, I don't see any significant risk.

To me what you want to do sounds fine, but I have no authority to give you an official answer. If you want an official answer, you should probably send an email to ipv6@he.net and ask for it, as it doesn't seem like any official answer is going to be posted to this thread without asking for it. I think this thread already contains sufficient information about the intended usage to base an answer on.

I should mention that I sell a product, which can do something similar to what you intend to do, although I do not make any use of BGP whatsoever. So I will be paying attention to any answers.

[acrg]

send an email to ipv6@he.net

Done, and the response is "not allowed."

[kasperd]

Done, and the response is "not allowed."

That's not a very detailed answer. I still don't know where they draw the line between what is permitted and what is not permitted.

[broquea]

It isn't that complicated. HE doesn't want tunnel users to go start announcing specific chunks of HE's IPv6 allocation randomly at wild on the internet.
If this "private peering" and announcement of address space isn't intended for public use let alone the global routing table, THEN USE ULA or get your own RIR allocation.
Would you go use Google's IPv6 allocations for this? No, so why would you use HE's.

[kasperd]

If this "private peering" and announcement of address space isn't intended for public use let alone the global routing table, THEN USE ULA or get your own RIR allocation.

You don't seem to understand the intent. The intent is that the different parties who have IPv6 addresses from different sources and have AAAA records pointing at their servers can communicate efficiently with each other.

Assigning ULA addresses is not going to help. As long as the AAAA records are pointing at public addresses, those addresses are what is going to be used for the actual communication. And putting ULA addresses in AAAA records supposed to be reachable by the entire Internet is not going to work well.

I can understand if HE don't want users to announce their assigned prefix through BGP or other routing protocols. It would be a perfectly sensible policy, however I have not seen any official statement saying that this is what the policy says. The wording in the terms is open for interpretation. It didn't say BGP.

Getting your own RIR allocation is a perfectly valid response for ISPs involved in such peerings. But for individuals I am not sure if it is feasible to do so at a reasonable price. You both need to pay to the RIR for the allocation, and you'll need for an upstream to provide you transit. I know HE has some tunnels with BGP support as well, I haven't checked if those are free and whether they offer transit. And I haven't checked how much it costs for an individual to get an allocation from a RIR. But it sounds a lot more expensive and a lot more complicated.

If announcing routes is what is not allowed by the policy, then there are ways to achieve roughly what acrg asked for without announcing any routes at all, thus achieving roughly the same end result without violating the policy.

[broquea]

Suffice to say it falls under a policy of common sense and netiquette when it comes to using temporarily allocated ranges from someone else's address space. The tunnels can be revoked at any time as explained in the TOS/AUP and other reasons perhaps not covered but easily explained if you email ipv6@he.net (like general asshattery on IRC as an easy valid example). If you want a network you already communicate with over IPv4 (local region) to see you over IPv6 via tunnels you set up directly with them, then why would you use 2001:470:xxxx::/48 versus fd01:470:xxxx::/48, if only to force them to either set connected/static routes for specifics to a chunk of HE range that they already learn from peers/upstreams? What I read in the OP's post is they are located in a region without a local tunnel-server, want to avoid a RTT nightmare via US/EU, to communicate with other local people/networks via 6in4 tunnels (let us assume p41). You don't need to use HE's address space to solve that. However if they still want real world connectivity, then they can set up something like an IPv6 firewall/nat66 that handles the transport between ULA and globally routed space. What happens when it all gets town down at the HE tunnel side, and then all those networks now have static routes pointing to an invalid path, and someone else creates a tunnel with that range? They become unreachable to anyone sitting behind that setup.

[kasperd]

If you want a network you already communicate with over IPv4 (local region) to see you over IPv6 via tunnels you set up directly with them, then why would you use 2001:470:xxxx::/48 versus fd01:470:xxxx::/48

Because you don't want ULA addresses in AAAA records that are served not only to your peers, but to all of the world. And because the client doing source address selection for a TCP connection won't know that the public IPv6 address it is connecting to is routed through a peering and thus a ULA address will work.

What is going to happen if you set up a peering using ULA addresses like you mentioned is that it is not going to be used at all. Let's say both client and server have public and ULA addresses, only the public address of the server is in DNS records. Thus the client will connect to the public address. The client doesn't know about routing and by connecting to a public address it should prefer to use its own public address. Thus none of the packets being sent will have a ULA destination address, and the routing table entries for the ULA addresses will not match any packets.

However if they still want real world connectivity, then they can set up something like an IPv6 firewall/nat66 that handles the transport between ULA and globally routed space.

Frankly I think they'd rather stay with IPv4 than deploying IPv6 in a way that requires that sort of NAT.

What happens when it all gets town down at the HE tunnel side, and then all those networks now have static routes pointing to an invalid path, and someone else creates a tunnel with that range? They become unreachable to anyone sitting behind that setup.

That's a valid concern. But I still don't know where to draw the line, and the terms don't say.

Assume I have a router with a route to ::/0 through my tunnel to HE, a route to 2002::/16 that automatically sends directly to the appropriate IPv4 address, a route to 2001::/32 that sends to my own Teredo relay, and routes to 2001:db8:123::/64 and fd91:3022:179a::/64 that were configured in a way that was completely unrelated to my HE tunnel. Am I violating the terms if my router uses one of those more specific routes for a packet that has a source IPv6 address from within the address space assigned to me by HE? Or is it fine as long as I don't advertise the HE IPv6 addresses and let packets coming back to me take the standard route?

[broquea]

But I still don't know where to draw the line, and the terms don't say.

You don't have to draw the line, HE.NET does. If you are uncertain about specific or a randomly generated set of circumstances YOU ASK HE.NET. I promise they will reply, maybe not with a diatribe about their reasoning, but them saying yes/no with regards to their address space and services should be the final word on the matter. You can wish and hope for detailed explanations, but in the end a free service isn't obligated to provide one despite people's sense of entitlement.

Assume I have a router with a route to ::/0 through my tunnel to HE, a route to 2002::/16 that automatically sends directly to the appropriate IPv4 address, a route to 2001::/32 that sends to my own Teredo relay, and routes to 2001:db8:123::/64 and fd91:3022:179a::/64 that were configured in a way that was completely unrelated to my HE tunnel. Am I violating the terms if my router uses one of those more specific routes for a packet that has a source IPv6 address from within the address space assigned to me by HE? Or is it fine as long as I don't advertise the HE IPv6 addresses and let packets coming back to me take the standard route?

The tunnel-server has RPF upstream of it and will not let improperly sourced IPs get past (this was true when I left, and appears to remain so after testing with someone else that found Comcast doesn't have upstream RPF for residential native IPv6 as of this writing). If 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel, THEN THOSE RELAYS ARE IMPROPERLY CONFIGURED. That is no fault of your own, but rather the relay operators (assuming not you, if it is you, then yes you are at fault but it's OK, you'll fix it :)). That kind of issue needs to be reported to both HE.NET and the relay operator.