nebula
nebula copied to clipboard
slackhq
IPv6 for overlay network?
Is it possible to use IPv6 for the internal overlay network? Our IPv4 RFC1918 allocation strategy has been...not good.
Not currently, but this was a conscious decision in the short term. Support for IPv6 as the underlying udp transport is something we will likely get to in the near term.
As far as Nebula IPs, they have an interesting property that led to us not directly supporting IPv6, namely that you can create nebula IPs sequentially, regardless of where in the world that host lives. This means that you can efficiently use an ip range of whatever size makes sense in your organization, because you don't need to divide things into subnets for routing.
I think he was referring to the fact that given the big or complex enough landscape, in brownfields you can end up with partial overlappings that break local traffic as soon as you establish the tunnel.
Here local traffic would be endpoints external to the overlay that are routed by local network elements.
hi , with tinc vpn there is a router/switch/hub modes(i use with brctl to bridge local network to vpn network).....that will exist in the nodes of nebula? or some way to bridging local physical network to nebula overlay network ?
As far as Nebula IPs, they have an interesting property that led to us not directly supporting IPv6, namely that you can create nebula IPs sequentially, regardless of where in the world that host lives. This means that you can efficiently use an ip range of whatever size makes sense in your organization, because you don't need to divide things into subnets for routing.
How exactly is IPv6 not compatible with sequential numbering? All of the random and generated address schemes are optional. Assuming Nebula IPs were out of 2001:db8:1234:5678::/64, if desired they can be allocated 2001:db8:1234:5678::1, 2001:db8:1234:5678::2, and so on.
IPv6 has the advantage of having enough address space to not conflict with anything, from any organization, globally. Nebula IPs could come from v6 "public" allocations, or Unique Local Addresses.
v6 also solved the big enough address range problem. All subnets are /64. Every net that wants one can get a /64.
IPv6 has the advantage of having enough address space to not conflict with anything, from any organization, globally. Nebula IPs could come from v6 "public" allocations, or Unique Local Addresses.
v6 also solved the big enough address range problem. All subnets are /64. Every net that wants one can get a /64.
ipv6 could also be used to address one significant issue with Nebula, which is that the scope of trust for the CA is too broad. Not only is this an opportunity for accidents/shenanigans, it makes scenarios where you want multiple authorities (limited scope delegation, multi-tenancy) untenable. Scoping CAs to a single /64 would enable this.
How exactly is IPv6 not compatible with sequential numbering? All of the random and generated address schemes are optional. Assuming Nebula IPs were out of
2001:db8:1234:5678::/64, if desired they can be allocated2001:db8:1234:5678::1,2001:db8:1234:5678::2, and so on.
@jpmahowald I was not saying ipv6 is incompatible with the numbering. Sorry for the confusion. I was saying that because nebula doesn't care about routes, we can efficiently use ipv4 addresses with ease. A single /16 worth of addresses can represent 65,534 hosts without wasting a single address.
Note: this is listed as an Enhancement because there is an obvious case for supporting ipv6, and we will. The words above were just a bit of historical context.
ipv6 could also be used to address one significant issue with Nebula, which is that the scope of trust for the CA is too broad. Not only is this an opportunity for accidents/shenanigans, it makes scenarios where you want multiple authorities (limited scope delegation, multi-tenancy) untenable. Scoping CAs to a single /64 would enable this.
@rlyeh In what way is the scope of trust currently too broad, and how does an ipv6 /64 change this? We support limiting CA scope via groups, and in practice we write all rules based on groups, never ip/network/hostname. Adding the capability to limit the subnets a CA can address may be useful to others, so I guess this is something we may do in the future.
@rlyeh In what way is the scope of trust currently too broad, and how does an ipv6 /64 change this? We support limiting CA scope via groups, and in practice we write all rules based on groups, never ip/network/hostname. Adding the capability to limit the subnets a CA can address may be useful to others, so I guess this is something we may do in the future.
I was referring to limiting the networks the CA can address, in the CA itself (via Name Constraints). Ideally this combined with proper support for sub-ca's, allowing for rigorous control in some address spaces and lax control in others, with one or two roots of trust.
IPV6 combined with subgroups (eg. wildcarded groups) would also solve our requirements. Can someone provide the status or document what is blocking this?
I'm doing Nebula with non-RFC1918 globally routable space (and I'm actually routing to my nebula network from the internet) as part of a broadcast video platform. The ability to push v6 around the same way would be super useful for my (admittedly nonstandard) usecase, especially as we're ditching v4 as much as possible elsewhere in the platform.
As a current ZeroTier user, I've been referred to this project as an up-and-coming alternative, but I personally cannot consider it ready for prime time until IPv6 addressing in the overlay network is available.
The IPv4 address space of my mobile provider occupies the entire 10.0.0.0/8 subnet, and I've seen public Wi-Fi networks that do the same - that breaks most IPv4 VPN's right there. Plus, I have containers, virtual machines, LAN segments, etc. that need to be reachable behind my machines. All of this complexity would be completely unmanageable with pure RFC1918 IPv4 addressing.
~This is currently implemented in master and should be considered beta until we release v1.4.0~
I've made a horrible mistake on overlay/underlay here. #322 (underlay) is the only one that is closed by master currently.
We will support ipv6 in overlay as well, just not in v1.4.
I am a new (tentative) Nebula user, and I naively tried to use IPv6 addresses in the overlay. The thing is, the fact that IPv6 is not supported is not obvious, I didn't find a mention in the documentation and the certificate generation tool didn't complain, stuffing inside the certs the lower 32 bits of the addresses I provided.
This led to some confusion and wasted time, and I had to dig a little inside the Nebula code to understand what was happening. Would it be possible to let nebula-cert throw out an obvious fatal error on invalid addresses?
It's something that we would like to support but is not high on our priority list at the moment.
I am a new (tentative) Nebula user, and I naively tried to use IPv6 addresses in the overlay. The thing is, the fact that IPv6 is not supported is not obvious, I didn't find a mention in the documentation and the certificate generation tool didn't complain, stuffing inside the certs the lower 32 bits of the addresses I provided.
This led to some confusion and wasted time, and I had to dig a little inside the Nebula code to understand what was happening. Would it be possible to let
nebula-certthrow out an obvious fatal error on invalid addresses?
The very same happened to me as nebula-cert seems to interpret an IPv6 address ending in e.g. ::c013/64 (defacto …:0000:c013/64) as 0.0.192.19/0, but only for the network, not for the host IP itself. This results in such weird error messages like this one:
ERRO[0000] static_host_map key is not in our subnet, invalid network=0.0.192.19/0 vpnIp="[…]::c013"
So yes, at least an error message or a helpful line in the example config (quicker, but needs to be removed again later) would already help here to avoid further wasted time (and probably also unnecessary support requests).
I, like all other colleagues and friends, really need IPv6 support in the overlay. This functionality will avoid address conflicts when using a nebula. This would greatly expand the possibilities of use.
Could you clarify why this is not a priority? In any case, thanks for a cool project!
I also vote for the implementation of IPv6 support in the overlay! Thanks :-)
github has reactions. please vote by adding your reaction to the first post. each (useless) comment in here just results in spamming everyone subscribing to this issue.
