Comments (22)
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.
from nebula.
I too vote/wish for IPv6 support in the overlay.
from nebula.
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.
from nebula.
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.
from nebula.
I also vote for the implementation of IPv6 support in the overlay! Thanks :-)
from nebula.
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!
from nebula.
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.
from nebula.
It's something that we would like to support but is not high on our priority list at the moment.
from nebula.
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.
from nebula.
I am trying to gauge the likelihood of ipv6 in the future. Is there any sort of roadmap for this feature or sense of where it sits on the list of priorities?
It would be helpful in my early stages of deciding on a solution to be able to gauge whether I should roll out a Nebula network with the assumption that ipv6 may be down the line or whether to play it safe and start with another solution.
from nebula.
🤔
from nebula.
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?
from nebula.
any updates on this?
from nebula.
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.
from nebula.
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.
from nebula.
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 ?
from nebula.
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.
from nebula.
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.
from nebula.
@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.
from nebula.
IPV6 combined with subgroups (eg. wildcarded groups) would also solve our requirements. Can someone provide the status or document what is blocking this?
from nebula.
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.
from nebula.
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?
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).
from nebula.
Related Issues (20)
- 🐛 BUG: Logging is very heavy if certificate has expired. HOT 1
- 🐛 BUG:How do I get the client virtual ip after the relay? HOT 12
- 🐛 BUG: tun cannot be unset on mac os HOT 4
- lighthouse.dns.host does not accept ::, but listen.host does HOT 2
- 🐛 BUG: Runtime Panic HOT 1
- Feature request: Ability to install multiple instances of nebula-service on Windows
- Thanks for nebula
- example config: commented punchy.respond value should be false HOT 1
- 🐛 BUG: tests fail after 2027-11-11 HOT 1
- 🐛 BUG: Unable to reconnect after server crash HOT 4
- 🐛 BUG: overall poor behavior with "not before" field in host certificate HOT 5
- Feature request: push unsafe routes from lighthouse HOT 1
- 🐛 BUG:Failed to setup adapter (problem code: 0x34) HOT 21
- Feature Request: Relative paths in config HOT 1
- Feature Request: `nebula-service -test -config` should warn about unknown keys and stuff in config yaml
- 🐛 BUG: wintun failed HOT 6
- 🐛 BUG: Event Log spam when handshake timeout fails HOT 10
- 🐛 BUG: "Refusing to handshake with myself" when configuring self as unsafe_routes via
- Windows is not as fast as linux for downloading files
- 🐛 BUG: Nebula nodes cannot ping each other , however they can ping the lighthouse vpn IP HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nebula.