Second Account?

[KiLaHuRtZ]

I was curious if HE allowed multiple accounts if one were to use up the allotted 5 tunnels in their account?  I have a need for a 6th tunnel and possibly a 7th.  Is this allowed?

[snarked]

Please explain why a person would need more than 5 tunnels for himself....  I can't think of a good reason offhand why one should....

[KiLaHuRtZ]

I knew that was going to come up.  :D  I guess one could say I'm not your average user when it comes to this stuff.  I'm looking to setup some routers in an isolated lab environment and wish to get them IPv6 connectivity.  I've exhausted my five tunnels already for personal home use as well as for my server environment.  I have mutiple routers and mutiple IPv4 address on these and wanted each to have it's own dedicated IPv6 gateway to the internet.  This is why I am asking permission first before I do anything as I realize this is outside the typical norm for the average user.

[kasperd]

Please explain why a person would need more than 5 tunnels for himself....

How hard can that be? Imagine being in the process of moving and having a period, where you do have Internet connectivity at both the old and the new place. Add to that a laptop that connects from many different locations and needs it own tunnel along with one or two VPSes, and the desire for some redundancy, so setting up dual tunnels in some of the places.

[kasperd]

I knew that was going to come up.  :D  I guess one could say I'm not your average user when it comes to this stuff.  I'm looking to setup some routers in an isolated lab environment and wish to get them IPv6 connectivity.  I've exhausted my five tunnels already for personal home use as well as for my server environment.  I have mutiple routers and mutiple IPv4 address on these and wanted each to have it's own dedicated IPv6 gateway to the internet.  This is why I am asking permission first before I do anything as I realize this is outside the typical norm for the average user.

The forum is not the best place to ask such a question. Instead write an email to HE and ask nicely, they might grant you permission.

[broquea]

Short answer? Sure as many accounts as you have unique email addresses, and tunnels as you have unique IPv4 addresses that respond to ICMP.

[kasperd]

Sure as many accounts as you have unique email addresses

That can mean quite a lot.

and tunnels as you have unique IPv4 addresses that respond to ICMP.

Apparently the unique IPv4 address requirement is due to limitations in the software used on the HE side. There is nothing in the protocol preventing the use of multiple tunnels on the same IPv4 address, and there are some reliability advantages from having two independent tunnels. Currently if you want that sort of redundancy you either need two different IPv4 addresses or use two different tunnel brokers.

I don't know what is the reason for the ICMP requirement. I have several times been on a network where ICMP was blocked, but 6in4 was fully functional. I had to use a different tunnel broker when I was on that network. And even if the IPv4 address does respond to ICMP packets, that doesn't guarantee 6in4 is working or that the user entered the correct IPv4 address.

Did anybody actually ever notice that they had mistyped the IPv4 address due to the ICMP check?

[broquea]

Not so much "limitations in software" as "policy". A change in policy would cause a bit to get flipped, and poof, 29897238492374 tunnels living on a single IP.

ICMP responding means they know the host is live; would you rather a portscan? (no really, what is a good recommendation for validating that a remote side is "UP" or reachable)

Filtering ICMP? Well that isn't even barely security through obscurity: it is pointless. If someone really wants to cause you "security" headaches, they can do a whole lot more without even touching ICMP. Smurf/Ping of Death is so last century.

[KiLaHuRtZ]

Thanks for the responses!  I really appreciate this, now I can get IPv6 tunnels to my lab w/HE.   :D ;D

Filtering ICMP? Well that isn't even barely security through obscurity: it is pointless. If someone really wants to cause you "security" headaches, they can do a whole lot more without even touching ICMP. Smurf/Ping of Death is so last century.

This is so true, I run into so many people who think that they are "hidden" from attacks by disabling ICMP, when in reality, it just causes more problems for them in the end.  :o

[kasperd]

Not so much "limitations in software" as "policy". A change in policy would cause a bit to get flipped, and poof, 29897238492374 tunnels living on a single IP.

I'd expect somebody to react before a single individual allocated an entire /18 of tunnels. Applying a reasonable cap on the number of tunnels per IP would make a lot of sense.

List of reasons why the limit shouldn't be a single tunnel include:

• Somebody might like to have 2 or 3 tunnels for redundancy.
• There may be multiple people behind a single IPv4 NAT, who need tunnels and cannot get native IPv6.
• A user with a dynamic IPv4 address may get an address which has previously been used by another tunnelbroker.net user, who has forgotten about a configured tunnel.
  

The redundancy case only makes sense if the tunnels are configured for different tunnel servers. And the NAT case is probably only going to work if the tunnels are using different tunnel servers anyway. Thus the only case where permitting multiple tunnels with same client IPv4 address on the same tunnel server would help is in the case of a forgotten tunnel.

In that case it would make sense to disable the tunnel that had previously been using that IPv4 address by changing the client IPv4 address to a null routed IPv4 address.

ICMP responding means they know the host is live; would you rather a portscan? (no really, what is a good recommendation for validating that a remote side is "UP" or reachable)

I would validate it by sending a 6in4 packet. The IPv4 source and destination IP as well as TTL should look the same as it will once the tunnel is up. The IPv6 source IP should be of the host doing the validation and the IPv6 destination IP should be in either the tunnel prefix or the routed prefix. The IPv6 hop limit should be set to 1 such that the user's router will send a time expired response back.

If you send an ICMPv6 echo request that way and get back an ICMPv6 echo reply or an ICMPv6 error, you know that the destination IPv4 address got routed to a tunnel endpoint. Additionally you know that if the user is able to send and receive protocol 41 packets, then they will also be able to produce the required response to the ICMPv6 packet.

Still just one packet back and forth. The difference being that the probe I proposed is actually related to the tunnel being configured. What is currently being probed is completely unrelated to the actual tunnel and can easily fail with both false-positives and false-negatives. And I guess of those cases where it does not get an ICMP reply, the majority are actually due to ICMP being filtered, and only a minority are due to a wrong IPv4 address being specified.

Filtering ICMP? Well that isn't even barely security through obscurity: it is pointless. If someone really wants to cause you "security" headaches, they can do a whole lot more without even touching ICMP. Smurf/Ping of Death is so last century.

I completely agree with that. However I consider the ICMP probe before setting up the tunnel to be equally pointless.

Reality is, some users find themselves in a position where ICMP is being filtered for no good reason, and they do not have any way to get that filter removed. The filtering is happening outside of the user's control, and is happening on a network managed by a person who heard about ping of death and will consider that "knowledge" to be more true than any sensible information you can give him about the reality.

Many of those users could be using the tunnel without any problem if only they weren't required to have an IPv4 address, which could be pinged. We are talking about two pointless restrictions, and the combination of those two makes it impossible to bring up the tunnel. Eliminating one of those two restrictions would be sufficient to make it work, HE is in a position where they could remove one of them.

[broquea]

Somebody might like to have 2 or 3 tunnels for redundancy.

Redundancy is an issue, albeit really small for a free service. Each tunnel gets its own IP allocations, and IPv6 RPF is in place upstream, and the IPv6 allocation pools are unique to each tserv. The only free redundant tunnel you can get is a BGP tunnel, which relies on the user having their own allocations. I'm willing to bet, as I have in other threads, the number of users competent of source address routing/selection are fewer than those wanting multiple tunnels per single IP. Sounds like it is reaching paid tunnel time if users want something more resilient. How much are they going/willing to pay for that feature set? Etc. Private-asn you might say? That is a service with a charge for HE colo/transit customers, why should it be free for the broker? They'd just come to the broker, bam no native, no revenue, etc.

There may be multiple people behind a single IPv4 NAT, who need tunnels and cannot get native IPv6.

Agreed, CGN sucks, should vote with wallet on their ISP choice. If it is the office, and you aren't the neteng/netadmin, tunneling of any kind through the corp firewall tends to be discouraged anyways. If you are, hey whattya know, you can modify the edge.

A user with a dynamic IPv4 address may get an address which has previously been used by another tunnelbroker.net user, who has forgotten about a configured tunnel.

This has always been a problem, and there is an internal mechanism in place for claiming that IPv4 endpoint and nuking the old tunnel or having it associated with the account. Also the abandoned tunnels should be really rare now with tunnels getting culled after inactivity. As for those blocked for abuse by another user....that was always an admin's call to remove, at least it was when I did it. As long as the requester doesn't match any similar internal blacklists.

Tunnels aren't supposed to be the preferred method of IPv6 connectivity, native is. I weep for an IPv6 world where ISPs/etc see that their users will just tunnel, and slow progress on native deployment because their users figured out a workaround. I weep even for those stuck behind 6rd because that is how lazy their ISP/etc is.

Anyways, OP, glad your Q was asked and answered.

[kasperd]

Somebody might like to have 2 or 3 tunnels for redundancy.

Redundancy is an issue, albeit really small for a free service. Each tunnel gets its own IP allocations, and IPv6 RPF is in place upstream, and the IPv6 allocation pools are unique to each tserv. The only free redundant tunnel you can get is a BGP tunnel, which relies on the user having their own allocations. I'm willing to bet, as I have in other threads, the number of users competent of source address routing/selection are fewer than those wanting multiple tunnels per single IP. Sounds like it is reaching paid tunnel time if users want something more resilient. How much are they going/willing to pay for that feature set? Etc. Private-asn you might say? That is a service with a charge for HE colo/transit customers, why should it be free for the broker? They'd just come to the broker, bam no native, no revenue, etc.

Redundant connectivity with the same addresses being used on both connections more or less requires that prefix being worldwide visible through BGP (i.e. not aggregated). There is a limit to how many people can get redundancy that way since the BGP table simply doesn't scale to having a separate route per household.

I think other forms of redundancy should be available to smaller networks. And they already are, since you can assign multiple prefixes to your LAN and have them routed through different tunnels. Not all routers support this out of the box, but my stack deals with that just fine. It would be even better to run those two tunnels over independent IPv4 connections, but that is not only more expensive to the users, it is also not a possibility for everybody, since some users will live in a place where there is only one ISP to choose from.

There may be multiple people behind a single IPv4 NAT, who need tunnels and cannot get native IPv6.

Agreed, CGN sucks, should vote with wallet on their ISP choice.

Not everybody have a choice. There are places where there is effectively a monopoly on internet access.

If it is the office, and you aren't the neteng/netadmin, tunneling of any kind through the corp firewall tends to be discouraged anyways. If you are, hey whattya know, you can modify the edge.

Not all networks fall into one of those two classes. As an example I have seen places where multiple tiny companies share an office space. There is a common network through a single NAT, but security policies are left for the individual companies to decide.

A user with a dynamic IPv4 address may get an address which has previously been used by another tunnelbroker.net user, who has forgotten about a configured tunnel.

This has always been a problem, and there is an internal mechanism in place for claiming that IPv4 endpoint and nuking the old tunnel or having it associated with the account.

Ok, the question has come up a couple of times, but it has not been answered before.

Tunnels aren't supposed to be the preferred method of IPv6 connectivity, native is. I weep for an IPv6 world where ISPs/etc see that their users will just tunnel, and slow progress on native deployment because their users figured out a workaround. I weep even for those stuck behind 6rd because that is how lazy their ISP/etc is.

That's not my main concern. I believe that if we can successfully move towards a situation where the communication between ISPs is primarily IPv6 (native or tunnelled) and IPv4 is demoted to just a layer for IPv6 protocols, then migrating to native IPv6 will eventually be the only natural strategy to ISPs.

I am more worried about a tendency to deploy CGN without offering any sort of IPv6 connectivity. In this country ISPs are saying that since they have plenty of IPv4 addresses for themselves, they don't need to deploy IPv6. And they have never had a customer ask for IPv6, so they don't see a need to offer it. At the same time hosting providers are saying they have no plans about deploying IPv6, and that's final, no discussion. Both ISPs and content providers are forced to keep supporting IPv4 and provided no incentive to start deploying IPv6.

At the current rate, in half a year I may be forced to go back to IPv4 only, because I can no longer get a public IPv4 address and thus cannot have a 6in4 tunnel.

[snarked]

I'm now wondering why he can't set up a machine to be his own tunnel server as an endpoint for a /48, thus having many thousands of /64 individual tunnels split from it....  It appears that some of his tunnelled networks will be at the same physical location.

Isn't his situation why HE also offers a /48 allocation?  (Rhethorical question)

[kasperd]

I'm now wondering why he can't set up a machine to be his own tunnel server as an endpoint for a /48, thus having many thousands of /64 individual tunnels split from it....  It appears that some of his tunnelled networks will be at the same physical location.

If they are in the same physical location and if he does not want redundancy from using different tunnel servers, then using a /48 would be suitable.

A single /48 consumes more addresses than 6000 user accounts using only /64s. Addresses are not the only resources consumed by such tunnels, but it is the only resource an outsider has any chance of comparing. The performance of a tunnel server should mostly depend on the amount of traffic send through it, which supposedly would be the same if it was done with a single tunnel with a /48 or with multiple tunnels with a couple of /64s each. The tunnel server could be implemented in a way, which drops in performance as the number of tunnels increase, but it would be a better idea to choose an implementation, where the performance remains essentially the same regardless of the number of tunnels.