X Might Be Ready For IPV6

makapuf writes "According to linuxtoday, the X Consortium has published enhancement proposals to let X and IPV6 interoperate. This is surely a relief for the masses here that longed for X support for IPV6. Or the contrary? The proposal can be found here."

Comments

And I was just thinking

[Anonymous Coward]

The only thing holding me back on IPv6 was X. Well, that's solved. IPv6 here I come!!!

Re:And I was just thinking

[Anonymous Coward]

Do you think before you post or just say what ever come out of your butt?

Sorry, but this post is so uninformed that it is distrubing. IPv6 was designed from the ground up to deal with the existing limitations of IPv4; therefore, you would be an idiot to make things a subset of the existing design, you wouldn't be accomplishing anything because all the inherent problems of IPv4 would still exist. You seem to focus on one aspect of IPv6, the # of addresses, but IPv6 was created to solve much more than just this problem.

The primary design goals of it were to

1) Increase the # addresses available and to have addresses autoconfiguring.

2) Increase security

3) Improve network routing and ease network autoconfiguration

IPv6 accomplishes all these goals and very well. Next time you decide to post check to see if you actually know what you are talking about.

Oh yeah, and while IPv6 is not compatible with IPv4 there are methods available to allow the two to coexist while the transition happens.

Re:And I was just thinking

[Hellkitten]

I don't want my toaster to have a public IP address

You just wait until they put that IP enabled pacemaker into you. The hospital will be able to monitor the battery easily, and that ungratefule slob of useless trash grandson you put in your will anyway get's to practice his 1337 h4x0rin9 zki115. It's technology, how can it be bad?

Re:And I was just thinking

[Erik Hensema]

• For starters, it's essential that the old addressing scheme be a straightforward subset of the new one.
  You can simply run dual stack. No problem in there.
• What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers? No human should ever want to, even in the IPv4 world. We've got a nice little thing called DNS which makes it possible to assign nice and easy names to those horrible numeric addresses.
• And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET.
  We don't need more than 640 K of memory either.

You haven't actually used IPv6 at all, have you?

Re:And I was just thinking

[tchuladdiass]

> So you're advocating security through obscurity? Well, I think everyone advocates this. If you don't beleive in the obscurity thing, then tell me, what is your credit card number, bank account, ATM pin code, Slashdot password, etc..., or would you rather keep them secure by making them obscure?

You are short-sighted

[Rosco P. Coltrane]

This is surely a relief for the masses here that longed for X support for IPV6. Or the contrary?

I don't care about IPv6, you don't care about IPv6, my grandmother doesn't care about IPv6 and 99.99% people don't care either. And even fewer care about X supporting IPv6 (hi guys). But one day in the future, you may care, when IPv6 spreads out, and if you happen to want X working that day you'll be glad.

Some dude at Microsoft, echoing what many people thought at the time, said nobody needed more than 640K in their computer. Just look at how much RAM you have today ...

Prediction

[Pres. Ronald Reagan]

My prediction:

There will be two posts that, without base or thought, recommend replacing X with a different default windowing system on Unix for every one post that discusses the article.

Perhaps

[fireboy1919]

I can think of what that will be like.

"Hey...X doesn't work with IPv6. I'll just tunnel it through an IPv6 ssh tunnel. Problem solved."

I guess I won't have to worry much about that day.

Besides, if you're using X over the net WITHOUT ssh (the only place where IPv6 is necessarily needed, since everywhere else you can use private addresses), what are you thinking?!!!

It's WAY to slow without compressing, which means sending it through some kind of tunnel. Personally, I think it's way too slow anyway. RealVNC beats it for bandwidth usage and it's just a framebuffer, even compared to dxpc and lbxproxy (at least that has been my observation).

Re:Perhaps

[Phil Karn]

I agree, X is one of the less compelling applications for native IPv6 support given that just about everyone I know already tunnels it over an SSH connection. SSH has had IPv6 support for some time, so you can easily SSH into a machine with IPv6 and invoke an X session with the IPv4 connections on each end that never leave the local machines.

SSH tunneling works so well for X that I wouldn't even mind if all IP support were removed, as long as there was still a way (e.g., UNIX domain sockets) to connect the SSH daemons to the X server and client on each end.

That said, it's still a good thing for X to support IPv6, just in case someone wants to use it. Every Internet application should support both IPv4 and IPv6.

Re:Perhaps

[Wumpus]

The problems you mentioned are fixable (and by that I mean working out of the box in some current Linux distributions, available now, and running on my machines).

Changing resolutions works with xrandr now.

As for XDM being brain-dead, I recently broke my XF86Config on a RedHat 8.0 system, and then had the brilliant idea to try and log out. Sure enough, XDM did its "X didn't start - must have been cosmic radiation. Let's try again!" thing, but after a couple of times of that, SOMETHING in the system decided to put a stop to this, dropped me to the command line with an error explaining what happened, and some helpful hints how to proceed.

I've read and hacked X server code. It's ugly, but it isn't the bloatfest people seem to think it is. Moving to glibc 2.3 did more for desktop responsiveness on my machine than any amount of twiddling with X could have done. It isn't X that's slowing things down.

Re:Perhaps

[ColaMan]

SOMETHING in the system decided to put a stop to this

init will get the shits if a restarts a process too often in a certain period of time and will kill it off.

(init being the "master" program that the linux kernel loads as boot... it loads everything else. It's normally the first process if you type 'ps ax' at a prompt)

I think IP v6 is not ready for IP v6

[stonebeat.org]

I think IP v6 is not ready for IP v6 :)

Higher Priorities

[Bonker]

Yeah, it'll be nice to have ipv6 in place when we need it, but I think a higher priority would be to speed up X's abysmal performance when compared to most other modern windowing subsystems out there, including Aqua and Windows' GUI.

The guy up above noted that there would be discussions on X needing to be replaced. I don't think X needs to be replaced it just needs to be more efficient. <blatant lack of application engineering knowledge> If *everything* has to go through a tcp/ip stack before it goes to the monitor, there should at the very least be some speed improvedments.</blatant lack of application engineering knowledge>

Re:Higher Priorities

[HBI]

Everything doesn't go through a tcp/ip stack.

Are you using DRI?

If you were, you'd probably not be complaining about performance.

You might want to consider compiling Xfree86 + DRI modules for your arch also.

Re:Higher Priorities

[Anonymous Coward]

Clue1: X uses UNIX domain sockets when run locally. This is actually quite efficient.

Clue2: X is fast when used correctly, as some toolkits seem to not do.

Re:Higher Priorities

[ahaning]

DRI (when it works; it's flakey on my Radeon VE) is fast at OpenGL stuff and playing video through the xv extension. I don't notice any change in 2D speed (window moving and such) with DRI loaded as opposed to without it loaded. I don't know about most other people, but this is what's most important to me.

However, it could just be that Mozilla's use of XFree86 is really slow. Other programs (abiword, gnumeric, dillo, netscape 4.7, xmms...) are faster.

Okay, so that wasn't too helpful. But, really, when people complain about poor performance, they aren't always talking about GL and video playback.

Re:Higher Priorities

[alienw]

It works poorly with the Radeon because ATI makes shitty drivers. Get a real videocard (nvidia) and you'll appreciate the sudden disappearance of flakiness.

As for the rest of your complaint: take the beef up with application or toolkit developers. X sure seems faster than Aqua for me, even for Mozilla. Mozilla is pretty slow by itself. Also, the desktop doesn't run in double-buffered mode, so the windows don't exactly move smoothly. This is not an X problem, it's a toolkit/desktop environment problem. If KDE doesn't use XRender and Xv to render faster, it's not an X problem.

X certainly has its inherent problems. Slowness is not one of them.

Re:Higher Priorities

[dbarclay10]

Yeah, it'll be nice to have ipv6 in place when we need it, but I think a higher priority would be to speed up X's abysmal performance when compared to most other modern windowing subsystems out there, including Aqua and Windows' GUI.

Yeah, I know, you're trolling, but hey - why not use this as an opportunity to enlighten others? :)

Many people, unfortunately, misunderstand what X is. Basically, X is a hardware abstraction layer. Each app doesn't need to code specifically for each video card, nor do they code specifically for a given output device.

Instead, X exports a fair number of "primitives" which applications use. The X server then renders these primitives. Normally to a screen.

How does the X server get these instructions, for lines, pixels, polygons, bitmaps, and what have you? That primarily depends on the task at hand; there are a number of extensions and modules that are used when they're needed. There's DRI, which allows a very, very thin abstraction layer. There's TCP, which lets apps talk X over a network. Loads of other ones. Shared memory and UNIX domain sockets are used for general local communications, just as fast as any other platform.

"Wait! You're describing a video driver!" you might say. Indeed, you'd be right; XFree86 is you're computer's video driver. But instead of each driver needing to be 20M full of duplicated code, we have small driver-modules, which share a common code base (the rest of XFree86). XFree86 also includes the libraries apps use, a (very) basic GUI toolkit, the tools to control your video drivers, etc., etc.

Is XFree86 slow? No. I'd like to see some benchmarks where XFree86 is more than 1-4% slower than a similarily-functional Windows or Mac driver. You might have trouble though, since none exist.

Last time I booted into Windows 2000 and tried to run a game, it came out at about 62 frames per second. The same game under XFree86 ran at about 64.5 frames per second. Why such a little difference? Because XFree86 with a decent video card is just as fast as any video drivers you'll find under Windows. The differences in speed I saw had nothing to do with XFree86 and everything to do with what I was running it on; CPU-intensive programs I run under Windows 2000 which don't do *any* graphics whatsoever are almost exactly 4% slower than under Linux; the same difference I saw when running that game.

Re:Higher Priorities

[ahaning]

Heh. You need to be a little more informed.

It works poorly with the Radeon because ATI makes shitty drivers. Get a real videocard (nvidia) and you'll appreciate the sudden disappearance of flakiness.

ATI doesn't write (many of) the drivers for XFree86. They've started to write some, but AFAIK, there are none from ATI for XFree86 for the Radeon VE. The ones I'm using are written by the DRI developers and are opensource/free software.

As for the rest of your complaint: take the beef up with application or toolkit developers. X sure seems faster than Aqua for me, even for Mozilla. Mozilla is pretty slow by itself. Also, the desktop doesn't run in double-buffered mode, so the windows don't exactly move smoothly. This is not an X problem, it's a toolkit/desktop environment problem. If KDE doesn't use XRender and Xv to render faster, it's not an X problem.


I admitted that certain programs (generally GNOME 1.2 stuff, since I don't have KDE libs or GNOME 2 libs installed) are fast, and that maybe it's just Mozilla that is slow. This seems the most likely, since they really don't have time to go trying to get it to work perfectly on a little-used platform (XFree86 as compared to Windows). I don't know where KDE comes in here. I use FVWM2, myself.

Verry wrong.

[Anonymous Coward]

You are so wrong, my presription glasses had to be wiped clean.

The purpose of IPv6 is: fix some flaws within the design of IPv4 and expand network addressing.

If you think IPv6 is a waste of time, you wait when the global networks start using IPv6 for the same strengths they needed and IPv4 did not provide.

If you think IPv6 is a waste of time, you wait when you need an IPv6 X client to connect to your server and VPN is not an option.

If you think IPv6 is a waste of time, you wait when even streaming media or realtime data requires IPv6.

LOOK: IPv6 has strengths that IPv4 doesn't have and never will be able to have, with exception to workarounds on the application layer. Don't knock IPv6, it is a Good Thing(TM).

Problem...

[yehim1]

IPv6 support for X seems to be a logical move, since the only way IPv6 would be embraced by the masses would be the support by the applications. After all, it takes but a few changes to the network layer socket code for the different packet structure.

However, the applications layer is important as well. For example, the X team has to consider changing XDM-AUTHORIZATION-1 to XDM-AUTHORIZATION-2 since the earlier could not support the longer packet structure.

Another change of mindset for X users that is required is the way of specifying the display number (:0, :1, etc) with the IPv6 address, since both IPv6 and the screen number uses the colon (:) separator.

Thus, the traditional way of denoting 2003:1080:1111:4034:1212:3fdb:1123:0001 with screen :1 would be

2003:1080:1111:4034:1212:3fdb:1123:0001:1 !!

For the clients, the X team has suggested the use of strrchr or rindex in their code so as to maintain compability.

For the human users, we need a DNS (most probably, since the address is too long to remember), or, well, we can all use an extra octet in the address, can we?

--

Re:Problem...

[nsayer]

The fix for this is to specify IPv6 literal addresses inside [], which is the solution for IPv6 literals in URLs. For example, the IPv6 equivalent to 127.0.0.1:0 is [::1]:0.

cool!

[VAXGeek]

now one standard no one seems to like can use a standard that no one likes to use!

Remove head from ass

[Anonymous Coward]

The latest X is Version 11 Release 7; shouldn't you call it X11R7? I read the manpage: man X.

X is not from MIT. There is an MIT X CONSORTIUM that designs and publishes the standards for X.

To my understanding, there are many implementations of X:

X86
XFree86
XDirectFB
TinyX
Accelerated-X
M etro-X
WeirdX
PicoGUI (yes, PicoGUI provides X services too...server)

That's all I can remember. All trademarks have been infringed by me. I 0wn all commercial X servers unlawfully. Have a nice day :)

Re:IPv6 is just a backbone technology

[toasted_calamari]

I don't understand why IPv6 would ever catch on as anything but a backbone protocol

I'm afraid I have to disagree. Maybe we don't need IPv6 *right now*, but networks are growing at an alarming rate. it would not be hard to see a future in which almost EVERYTHING is attached to a network, your PDA, desktop, laptop, car, appliances, watch, etc.

while you could just stick everything behind a NAT, why do it when you can give everyone (and everything) an IP, why add that extra level of complexity.

Whenever a new development comes out, people always claim that it will never catch on, because the current system works fine. However, they are usually wrong. "this will never catch on" is broad statement to make. "never" is a big time range.

Re:IPv6 is just a backbone technology

[Phil Karn]

There are a few important situations where IPv6 is already The Right Answer.

First on the list is accessing servers behind a NAT. Wouldn't you like to connect directly to the multiple Linux boxes behind your NAT box without having to first log into the NAT and out again, or having to set up ad-hoc port forwarding kludges? Configure 6to4 on your NAT (easy if it's a Linux box) and you can establish a direct logical end-to-end IPv6 ssh connection even if the path in the middle is IPv4 only. Works great for me. I have been maintaining my parents' network in exactly this fashion for some time now.

Also on the list is VoIP. Look at all the hassles involved in running H323 from behind a NAT. (SIP may be more NAT-friendly, I haven't investigated it yet.) If only H323 supported IPv6, life would be so much easier.

But the real killer app for IPv6 will be cell phones. If cell phones are to implement true VoIP, there is simply no alternative to IPv6 because there are simply far too many cell phones in the world for the number of available IPv4 addresses.

Basically, IPv6 is all about wiping out the NAT plague and restoring the end-to-end model that originally made the Internet great. That's exactly opposite to the claim you make in your subject line. If you don't use NATs, or if you're unimaginative enough to think that you'll never need to do what they make difficult or impossible, then you probably won't be excited by IPv6. But eventually you'll probably discover why IPv6 is inevitable, even though it will have to coexist with IPv4 for a very long time.

SSH tunnels, the "nazi analogy" of slashdot

[coyote-san]

It's time to declare a discussion over whenever somebody suggests SSH tunnels as the answer to all of the world's problems. Security, authentication, fresher breath and bedmates with big breasts! It's as predictable as a flame war escalating to the inevitable comparison to Nazi Germany.

If you knew half as much as you think you do, you would know that SSH tunnels are a clever ad hoc tool but they suck as a real VPN solution. They also don't give you nearly as much authentication as you think, since that information is not available to the user. In contrast my Unix socket code and SSL-aware applications always pull strongly authentication information about the peer as the first thing they do.

If you want to learn more, check out the documentation on CIPE... and try to write a tunneled application that can provide strong socket-level authentication of the peer's identity.

X Rules

[Anonymous Coward]

It might not detect any of my mouse buttons, but it sure as hell can address 2^128 nodes!

Need GUI's over HTTP

[Tablizer]

I have concluded that it is best if the GUI goes over regular HTTP. The red tape to get non-HTTP thru many companies is too great.

Although HTTP may not be the ideal protocol for GUI transport, I have concluded that it is satisfactory for most B-to-B biz forms if you "tune" it right.

My own pet draft GUI protocol, SCGUI, is an attempt to define such a standard. There is also XWT, but it is more fat-client than SCGUI, which attempts to define a non-Turing-complete protocol for improved security (although client-side T.C. scripting could be added).

More IPv6 Support, Please

[serial frame]

We need to get this fucking ball moving. Look, people, face it, IPv6 is the future, has been tested and has very many stable implementations. It's already in Windows XP, so there's no reason to begin porting programs over to the more modern address resolution code. getaddrinfo() is much neater and lives up to POSIX ideals of code beauty. There is no reason your application-level code shouldn't be able to handle both IPv4 and IPv6, which is a result of using getaddrinfo().

We shouldn't stop at just X Window. Many other vital network-able applications should be on the list. VNC would be a prime candidate for IPv6 support; many programs such as ssh and standard utilities in the major BSD's already prove themselves in terms of IPv6 support. Instant messengers, online games, etc. should also be next on the IPv6 support bandwagon.

Honestly, there is no reason why we shouldn't take advantage of functions that make IPv6 transition (as well as IPv4 compatibility) trivial. IPv6 provides many clear advantages as to why it would be the next de-facto Internet protocol, thus I am able to say with certain confidence that IPv6 will be next up on the plate, and therefore applications should support IPv6 early on for the quickest, most painless transition. If you're interested in seeing why for yourself, just hit www.faqs.org/rfcs/ and search for RFCs on IPv6. They will tell you everything you may need to know as to why I'm ranting.

If you're interested in trying out IPv6 for yourself, I highly suggest using freenet6.net if you are running a flavor of Unix. Otherwise, on Windows XP and similar, simply type 'ipv6 install' on a command line, reboot, and test your connection with a simple ping6 www6.netbsd.org. Oh yeah, if you do join the IPv6 world, make sure your webserver supports IPv6--I'll be sure to visit :)

Re:IPv6 is just a backbone technology

[ghostgum]

H.323 does support IPv6, it is just the implementations that don't. The 1996 release of H.225.0 (part of H.323) includes the following ASN.1 syntax.

ip6Address SEQUENCE
{
ip OCTET STRING(SIZE(16)),
port INTEGER(0..65535),
...
},

Other suported choices for TransportAddress are ipAddress (IPv4), ipSourceRoute, ipxAddress, netBios, nsap, nonStandardAddress, and "..." to allow extensions.

X and IPV6

[Anonymous Coward]

It already does support it. Guess it must not be official, but debian has an IPV6 aware X server in their ipv6 packages.

# ipv6 support
deb http://debian.fabbione.net/debian-ipv6 sid ipv6
deb-src http://debian.fabbione.net/debian-ipv6 sid ipv6

Re:X is a thing of the past

[Erwos]

Would you like to inform us what exactly makes you knowledgeable enough about the subject to lecture us all about the need to dismantle X?

And, even ignoring your lack of credentials, your criticisms don't even seem to make sense.

"Whos runs X apps over the network?" I do, and I've seen _many_ places where people should as well. Quick example: my girlfriend does finite element analysis using ANSYS. She has to trudge up to the Linux lab every so often. If she was running ANSYS using remote X, she wouldn't have to do that. How much time could be saved by not making people waste an hour of their day walking to labs on the other side of the building?

How about embedded apps? Wouldn't it be simpler to move processing to a server somewhere, and just run a simple X server on the device? It certainly seems more efficient and less expensive than trying to stuff ample hardware onboard each one of them. But, hey, let's ignore that obvious use for X, and claim "no one uses it anymore!"

XF86 _DOES_ have DirectX. We call this "DRI", and if you combine it with SDL, there you go, DirectX for Linux. DRI is a local interface. It has none of the supposed problems X has with regards to performance. Even casual benchmarking of games in Linux and Windows reveals that any impact X has is minimal. There's also nothing preventing you from doing a hardware-accelerated GUI - the architecture is all there.

In other words, I'm calling bullshit on you. Prove yourself. It's easy to talk smack about something you obviously don't understand.

-Erwos

Re:X? X?!?

[ctr2sprt]

I know, don't feed the trolls, but... From X(1):

The X Consortium requests that the following names be used when referring to this software:

• X
• X Window System
• X Version 11
• X Window System, Version 11
• X11

Pay special attention to the first option. IHBT, IHL, but HTH, HAND.

All I want for Christmas...

[tupshin]

is simultaneous support for Xinerama and DRI.

Re:IPV6...pah!

[bazmonkey]

If that's all you need, go play with DirectFB. It's even 3D accelerated if set up correctly, and has GNOME working.

Re:Great!

[Fembot]

Hint: If the problem and solution are so obvious get off your arse and fix it