search

jackaudio / jack2

jack2 codebase
GNU General Public License v2.0
2.2k stars 373 forks source link

IPv6 support for jack_netsource #139

Open trupanka opened 9 years ago

trupanka commented 9 years ago

Currently jack_netsource doesn't support IPv6 address for -H option. Fix that, please.

sletz commented 9 years ago

Patch ?

Le 24 ao�t 2015 � 22:21, Gangr�na Gorgeous notifications@github.com a �crit :

Currently jack_netsource doesn't support IPv6 address for -H option. Fix that, please.

� Reply to this email directly or view it on GitHub.

trupanka commented 9 years ago

feature request

nedko commented 9 years ago

@trupanka Consider providing a patch

7890 commented 5 years ago

https://github.com/jackaudio/jack2/pull/27 says to add support for IPv6

highgain86j commented 4 years ago

I've been using Jack2 for some time and I personally do not see the point in having IPv6 support. The reason is, once you have IPv6 support for certain applications and try to let the related-traffic pass through ND-proxy (typically built around OpenWrt in my case), many-short-packet communication like that of netjack would get really cumbersome. Besides, I don't see myself typing in jackd -S -R -aa -dnet -a "<some IPv6 address>" on slave machines even when needed.

It's also been pretty handy for me that Jack2 does not automatically start to mess with IPv6 because I have two NICs on the master of jacknet, each respectively used for IPv4 and IPv6 exclusively. For most things (like logging into the machine via SSH and so on), I use IPv6 link-local address as advertised by avahi and this does not screw with jacknet traffic at all at levels lower than Layer-2. Same thing for when you are sftp-ing or accessing the machine via samba.

Plus having multiple NICs and multi-core CPU allows you to assign each NIC to a specified CPU-core. There are performance-related advantages that come as side-effects from Jack2 not supporting IPv6.

So even if future-releases of Jack came with IPv6 support, I only see myself disabling it manually or even requesting for a separate command option to implicitly tell Jack2 to also listen on IPv6 addresses. Having IPv6-support enabled by default with Jack is something I'd be very against about - till all of my NIC stop speaking in IPv4.

Folks, do you need all that many machines (you have segments in the basic size of /64 for IPv6) to speak jacknet on your local segment? What kind of mass-scale sound-rendering farm are you running?

Don't get me wrong here though - I'm open to changes if advantages of the new are obvious. Here specifically, though, I'm saying that both IPv4 and IPv6 have and will continue to have different roles if not strengths (hence IPv6 won't be a direct substitution for IPv4 unlike many would believe it would be).

Further speaking, a single segment of IPv6 on which SLAAC can be enabled is fixed to the size of /64 (hence the practical equivalent of /24 in IPv4 in typical personal LAN setups). Link-local addresses are in fe80::/64 as well. On any IPv6 segments larger or smaller than this, use of unicast addresses with netJack may be practical if all hosts have static ULA addresses...but never ever with link-local addresses or global addresses configured through SLAAC because you now have most OS having random-addressing enabled by default for IPv6 for enhanced privacy.

If you believe IPv6 will one day disappear from your home/office network entirely, I'd say you may be right. But that's superficial - because ISP-grade routers speaking to each other in some dynamic-routing protocols (like OSPFv3 and/or BGP4+) are configured with router-id that is expressed in a string in the format of IPv4 addresses (they are merely identifiers though).

Eventually IPv4 will fade away entirely from the internet (WAN) for sure, but it's only natural (as it seems to me) to then assume that IPv4 will live on as 32bit identifiers for many "local" applications. And I think jackNet is one of such applications, too...

Besides, IPv4 has technical advantages too, of the length of packet-header being 20bytes less than IPv6. This means every packet exchanged in IPv6 will be at least 20bytes larger compared to the same set of packets being exchanged in IPv4. Performance drawbacks? Maybe minor but inevitable.

So, these combined, I see (not immediate benefits of, but) potential causes of numerous obstacles ahead with jackNet natively and by-default supporting IPv6.