Slashdot Mirror
Transparent IPv6 with Linux?
David A. Madore asks: "Every once in a while, I decide to try out IPv6 (on my local PC network that isn't connected to the Internet). And every time I'm disappointed. Now that the kernel supports it, and libc (glibc 2.2.1) supports it, and that I've recompiled the net-tools with inet6 support (why doesn't RedHat do that by default, I'd like to know), I would expect to be able to type
'telnet ::1' and get a connection to localhost, prompto! Instead, I get '::1: Unknown host.' Isn't the whole point of' IPv6 support of the libc to make program support completely transparent? And isn't the whole point of dynamically linked libraries so that we get it without even having to recompile anything? Or am I being incomparably naïve here? Will we have to rewrite and recompile any network-aware program so as to get IPv6 support? By the way: How will X11 DISPLAY strings work with IPv6 ':0' is kindda confusing in relation with IPv6 addresses)? Can anyone clarify the matter?"
You shouldn't be too disappointed with beta code, in any case.
# Zoot
Well I've spent the last year setting up terminal servers and messing with IPv6 and I"ve had all sorts of problems with support for it. Most times it will be quite transparent with applications (just substituting the IPv4 address for the IPv6 works great) but every once in a while the application would except an argument with an IPv4 format.
Overall Its really bloody annoying but if it expects it to look like IPv4 then yea it will have to be rewritten hopefully it will not become the case too often. I actually like IPv6 and have been having a lot of fun with it especially with automating it (automated tunnel setups and such) have a slight issue with the NetBSD stack (its wierd Really wierd) =) Anyways thats it for now
but wouldn't transparent IPv6 look more like this:
telnet 127.0.0.1
telnetd takes this IP and asks the appropriate library to connect to this address. The library function would then recognize that an IPv4 address was given and convert it to the corresponding IPv6 address and connect to this address?
There -is- a way to get round that - an IPv4/IPv6 gateway - but that adds a lot of overhead and is not the way to fix broken apps.
There has been a LOT of discussion on URLs and X DISPLAY strings, as they would allow multiple interpretations of the IPv6 address. One possibility is to require fully-expanded addresses in those instances, another is to bracket the address somehow, so that it can be seperated. AFAIK, there's no real, universal consensus on this, at least not the last time I looked. There may be more of one, by now.
For Telnet, FTP, etc, go to ftp.inner.net and download the ported utils they have. I admit, the porting isn't the best code I've seen, but it does work, and'll give you a feel for what could be done.
If you want to try IPv6 properly, though, join the 6Bone and test your machine to the limits.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I understand that RedHat does not enable IPv6 in the nettools package due to the fact that IPv6 was not really ready for the everyday user at this point. cheerio The Squid
I thought there was still some issues with DNS and IPSEC. Is there stuff that still needs to be done?
--
"New worlds are not born in the vacuum of abstract ideas, but in the fight for daily bread..."
New worlds are not born in the vacuum of abstract
ideas, but in the fight for daily bread --Rudolf Rocke
Anybody in the know want to write a decent How-To?
-----------
"You can't shake the Devil's hand and say you're only kidding."
I can't remember, but is there no Linux support in KAME? I've patched a quite a few FreeBSD and NetBSD machines with the KAME stuff and they work fine. They come with new utilities (telnet, ftp, etc) that are transparent and accept both IPv4 and IPv6 addresses, as well as looking for A and AAAA records.
Where could one find info on joining the 6bone? Does it require that your ISP be running some IPv6?
-AP
Your ISP can be running a cooked hamburger, as far as you're concerned. :) So long as you've an internet connection, the only requirement is that you set up a tunnel, connecting to some existing node on the 6bone. It's as easy as that. :)
Just e-mail the maintainer of the node, get the IPv4 address for their end-point, let them know the address for your end-point, configure SIT0 accordingly, and you're sorted.
(If you get a dynamic IP address, from your ISP, it's slightly more complex. The maintainer'll need to have some kind of script running, to automatically adjust the tunnel, according to what your new IP address is.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
A combo of A and D. They wanted something clearly seperate and because MAC addresses use : as the seperator, they assumed it would be usable.
Not knowing everything else, but wouldn't a , be a good character?
--
Ben Kosse
Remember Ed Curry!
I've used several IPv6 stacks on FreeBSD and rarely had any problems. I've also tried to compile and use the network utilities for Linux and have always had lots of problems. It seems to me that Linux simply is not IPv6-ready (yet).
If you are looking to test a single IPv6 host, consider using FreeNet6 at www.freenet6.net. This site uses an automated web form to request and setup an IPv6 tunnel out to the mbone. The one drawback with this site is that you can't route hosts from behind this address. It is an end station address rather than a subnet. Anyway, it is still a great way to get your feet wet.
World Beach List, my latest project.
NetBSD has the Kame code integrated in -current and it works just fine -- you can telnet to a v6 host if you like.
I suspect your Linux userland utilities just haven't been updated to be v6 aware. Either complain to the maintainers of those programs or send them patches. There are lots of patches on several FTP sites for making utilities v6 aware, by the way.
It sure would be nice if someone would put together a site with patched RPM's and SRPMS's for IPv6 support under RedHat. Of course, the same needs to be done for Debian. For the nettools package, it was just a matter of fixing the "spec" file and recompiling it. If a set of patches could be put together and distributed in a RPM or deb file for packages such as inetd, bind, telnet, apache, etc, testing of IPv6 would be a heck of a lot easier.
World Beach List, my latest project.
There are a few things to be said about IPv6. The main thing is that IPv6 is still Beta. That means that it is being implemented and tested along the way. Everyone on the 6bone and alike knows this. Everyone getting an IPv6 number is told that they have to hand id back sometime, because the hand-out schemes are also being tested. And yes, they have already changed those hand-out schemes and addresses at least once.
:-)
Software vendors and network hardware vendors do not fully support it -- some will give software to you as an addon. But they do not support it. If you learn from it, great, but if it breaks, oh well, it isn't yet meant for production purposes anyway.
I think one of the main reasons RedHat doesn't ship with IPv6 enabled is that it is not yet supported everywhere. For example if you use things like sockaddr_in in your programs, you're hosed because it is IPv4 specific. And there are a lot programs that are IPv4 specific (not to mention 4-byte-copies to duplicate addresses). And checking all networking programs takes a lot of time. Not to mention fixing them and getting maintainers to support IPv6.
So this summs up to three important points:
1) IPv6 is development stuff and quite uncommon. So don't expect your average program to work.
2) It can be used very well to learn things on IPv6 and networking in general. That's also why 6bone started.
3) Because IPv6 is still beta and things, it isn't yet in very-easy to use packages with your favourite OS flavour. Also don't expect ISPs to support it. The larger ISPs are on the 6bone and might offer you a tunnel endpoint, but it's experimental for them too. So they probably don't want to invest too much time in it.
Oh, and for the people who still want to try IPv6, there is a good HOWTO on setting up IPv6 for Linux. If it's to technical, you don't want to try it on any operating system. If it's peanuts, you should help test IPv6 and help porting more applications
That's all for now, Erik.
I was really looking forward to reading more of his books to see where he fell in the whole BSD vs. Linux vs. everyone else debate. It was pretty clear from his other books that he really disliked System V, and really liked BSD.
And now I hear he died. :-( When did this happen?
Need a Python, C++, Unix, Linux develop
Some apps will work with IPv6 without needing changes, but it depends what set of functions they are using. If they use the updated IP functions and write their code the right way, transparent protocol support is possible. Alot of code i've seen uses the older functions, which is fine for the moment, and tends to be simpler to implement, some programs are using the newer functions, but don't do so in a way that allows use of IPv6, there are some really good books on how to do this (UNIX Network Programming Vol. 1 is what i generally use as a reference).
That said, there are also some other issues, such as people upgrading to BIND 8 for DNS stuff, implementation maturity, to name a couple.
Go here
And here thanks
Any thoughts about the truthfulness of those stories?
There was a Slashdot Article on September 4th.
The world lost a truly great networking mind when it lost W. Richard Stevens. May he rest in peace.
--Joe--
Program Intellivision!
I've been trying to compile the ipv6-net-tools on suse for some time now, but I haven't really succeeded yet. Weh I alter some include-files some errors disappear, but others show up. My redhat 6.1 system seems to be a bit better configured, because compiling goes perfectly (after hacking the include files for approx. 30 minutes). The ifconfig command works fine, route doesn't know address-family inet, nor inet6 (pretty useless) and ping6 ::1 works fine now. My redhat and suse systems are nog glibc-compatible, sow copying the binaries doesn't help. Has anyone created some rpm's with statical-linked binaries? That would be usefull!
Good luck, and if you really want ipv6 to work, upgrade to RH6.1
The big lesson that the world should be learning from IPv6 (but isn't) is that most existing network applications are hopelessly dependent on the protocol they were written for. So, for example, the standard 'telnet' program you get in your favorite Linux distribution supports IPv4 *only*. It *will not* work with IPv6. If you feed it IPv6 addresses, it's not going to somehow magically work. The telnet program just does not know anything about IPv6, and nothing short of installing a new version of telnet or using elaborate and dangerous kluges is going to change that.
There are ways to build applications that can support -- within some reasonable constraints -- any protocol you throw at them. A lot of this centers around using protocol-independent APIs such as getaddrinfo() and being careful about how you code things. It's also possible to take most existing apps and retrofit this flexibility into them, though some apps are really poorly written and those are really hard to fix. Applications written that way will transparently just deal with IPv4, IPv6, or whatever else you feel like using.
However, a lot of the IPv6 implementors are just making applications support IPv4 OR IPv6 rather than making them support anything. This just means that if IPv6 doesn't happen (which is definitely possible) or if we all decide later to move to IPv7, we're going to have the same problems all over again.
Now, there are tricks such as proxies and NATs that can be used to allow an IPv4-only app to talk using IPv4 to some intermediate point that then relays the data over IPv6 to some far end. This works, sometimes, but it's exactly the kind of kluge that IPv6 exists to try to avoid.
when the sysV guys found him....
Ever here of argv and argc?
Ever parse an input line?
Hello? Knock knock, is there is a coder in there?
This is the MOST common misconception about IPV6, and I wish people somehow would stop getting this idea.
IPV6 IS NOT solely to remedy ip address shortages. There are those who contend that there is no such shortage, and we can all just use NAT boxen and masquerading till the cows come home. Which leads to the natural assumption that there's no need for IPV6.
Other important things that come with IPV6 are the QoS ratings, additional security features (!), better design from the network architecture standpoint, general improvements in the spec, etc.
Keep in mind, IPV4 is OLD, and it was never meant to do the things we have it doing, becuase the designers at the time had no idea how the Internet would turn out.
(!) BTW, this does NOT refer to the so-called loss of anonymity caused by putting a MAC in the address. Read more at the IPV6 FAQ.
Check my Go-related blog for beginners: DGD
There has been some concern over the use of thw ':' character in the text representation of IPv6 addresses - this could break some programs parsing addresses or especially URLs.
There is an internet draft which proposes the following native format:
instead of "ABCD:EF01::2345:10.9.8.7" use "ABCD-EF01--2345-10.9.8.7.ipv6" which contains only characters valid on a domain name and marks the with a pseudo-TLD of ".ipv6"
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
The guy forgot to do any research before publishing. I checked back today, and there were a bunch of letters to the editor, none of them mentioning the IETF draft covering the same topic and dated June of this year, but at least letting him know that, for instance, ethernet MACs and IPv6 addresses are changeable.
The guy does have one legitimate privacy concern left, though: how to keep his idiocy a secret.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
I'm working on my MSCS and would love to get some practical experience with low level or network coding. Any body know of any good projects that I can get involved with, or anything in particular that needs to be done.
Thanks.
transparent ipv6 would be:
~> telnet localhost
connecting to localhost (::1)...
but that's a long way off.
Unfortunatly many TCP/IP programs will have to be rewritten to work with IPv6. Yes, it is possible to create protocol-independant (as far as v4 or v6) programs, but there is still lots of maintanence to be done (which is why I believe that the switch from IPv4 to IPv6 will have more problems than those caused by Y2K).
:)
The bulk of problems lie in the address conversion (from readable strings to data used by sockets) functions. Since IPv6 addresses need more space to store, the IPv4-centric program isn't going to have enough space for them, thus support for IPv6 in the libraries isn't going to solve everthing, a partial rewrite will be needed. Usually it will be simple to make it compliant, unless it uses a lot of IPv4 dependant stuff (like raw sockets for example).
If code uses gethostbyname and gethostbyaddr, it is probably IPv4-dependant. If code uses getaddrinfo and getnameinfo, it is probably protocol-independant. (Please note that I said "probably"). Just grep source and find out if it needs to be rewritten.
So, yes, you were slightly naive, there is yet work to be done
Ben Higgins
I'd much rather have 6to4 than the 6bone. Is anyone working on 6to4 for Linux?
What do I, as a lowly network application programmer do if I want to write portable code that migrates smoothly to ipv6?
Last I checked, getaddrinfo was not widely available under most Linux distros. Apparently, there is no api standard for sockets, ipv6 or no (the ipv4 api is more or less a de facto standard, although there are still gaps, such as a threadsafe version of gethostbyname).
Stevens talks about XTI, but as far as I can tell it's yet another example of Open Group navel gazing. Is it even available under Linux?
Unless I'm wrong, they haven't made it easy to do the Right Thing. Ah well, I guess the right thing to do is complain to a local representative of ITC (the International They Consortium).
LILO boot: linux init=/usr/bin/emacs
The Linux Kernel actually supports IPv6 pretty well, from what I can see. What you're forgetting
::1 probably isn't a good idea anyways, you're really asking for it. You should use IPv4 mapped IPv6 addresses like ::127.0.0.1 and the like.
,reverse qq;):zrekcahzlrepzrehtonaztey; );"
is sysutils and the like DON'T always know about
IPv6 yet. For instance, I don't think telnet is protocol independant. So you really can't blame it.
Besides, an addr of
For you coders out there, STOP using the old methods, inet_ntoa and inet_aton. These DON'T work! You need to use inet_pton (which are defined in to handle IPv6 properly, if at all. Read the prototype if you haven't already.)
It's a wise idea these days to develop network applications that are protocol independant. I see stuff that isn't coming out of freshmeat.net all the time.
It's usually a simple chore to patch source to be protocol independant, you just whip around a few different calls. Developers should take heed!
- Paradox
Man of the C!!!
perl -e "print join q( ), split(q.z.
Slashdot. It's Not For Common Sense
The problem with recompiling for IPv6 is that coders are lazy, and didn't do things right.
The sockaddr_in and hostent structures were meant to vary in size, that is why they are defined as arrays of n-bytes, with n specified in the structure. But most programmers thought it was easier to use a single 32-bit number, instead of an array.
And so incompatabilities arise. It should not be difficult to baby step existing code to do things RIGHT using the IPv4 headers, then plunge into IPv6. In my case, I wrote libraries around BSD sockets, so all I need to do is change a small library, for older code, it may be more difficult.
For 6bone info, see http://www.6bone.net/
XTI isn't available under linux, well not under redhat 6.0 or debian 2.2. A search through the debian pacakge archive only produced icbs (the intel binary compatibility standard), which supported binaries compiled using XTI, but doesn't include the headers or libraries for XTI development.
;)
Anyway, sockets are easier to use
I think the parsing code is designed for IPv4, so it will only recognize a x.x.x.x as an ip, otherwise it tries a DNS lookup. If you setup an IPv6 name server, it might work.
It seems to me that IPv6 needs an evangelist - someone like RMS who can tirelessly poke and prod people to sit up and take notice of the requirements of this new, but incredibly important protocol.
I have read posts here pointing out that programmers need to be educated to write their apps to support methods that have IPv6 support and that word needs to be gotten out to ISP's, network admins etc about how to integrate a changeover to the new protocol.
Now, in the true spirit of the Internet community, I should be offering my services instead of just suggesting this, but whoever takes on this is going to need *way* more free time and money that I have unfortunately. They'll also need to be prepared to dive in and build up a deep understanding of the programming and technical issues involved.
Of course, an evangelist isn't the only thing that will be required to muster up support and readiness for the changeover, but it's one of the ingredients that I feel is lacking at the moment.
Anyone feel a call to action???
A little planning goes a long way...
Not everyone can write good code.
That shouldn't stop them from pointing out the rough edges and asking for help.
Yep, but who's tried it out? It seems that netbase and some basic packages do have IPv6 support. I think Debian has the best support so far...
--exa--
IPv6 is most certainly about alleviating the IP address space shortage. Everything else was a case of "well, if we're redesigning the world, there's this one small thing I want to add..."
Network Address Translation (NAT) is an unmitigated Evil in that it breaks the End-to-End model - the basic design assumption of the Internet (you know, smart end hosts, with stupid routers in the middle who are not supposed to muck with the packets in any way?). There's also one other small gotcha with NAT - if you NAT, you can't use IP security. How can the NAT translate IP addresses hiding in an encrypted packet?
The 32-bit IPv4 address space will exhaust, and when it does, we all must have IPv6 stacks in our kernels, and our applications converted and working in both the old and the new address space.
Anything else is just an egregious hack, and must not be tolerated.
When you're parsing $DISPLAY, are you looking
for an IP address? NO! You're looking for:
ip-addr:n[.n]
So you rip of the right hand display[.screen]
spec _first_, then hand the left hand side to your
ascii2address routine.
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
W. Richard Stevens UNP book is full of well-explained IPv6 material, down to the detailed API level. I highly recommend his books on UNIX or Network Programming or both.
I don't know much about IPv6 and haven't done anything to set it up on my system--i use the same /etc stuff i used when we had only IPv4. On NetBSD-current, I can verify that 'telnet ::1' will get you a login prompt on the local machine. I didn't know ::1 was the loopback addr until I read it here, so obviously I don't know enough to answer your DISPLAY question. NetBSD-current has merged into both the kernel and the userland the IPv6 stack developed in Japan by KAME. KAME supports IPsec, and KAME's IPsec implementation in NetBSD contains strong cryptography which can be legally downloaded both inside and outside the US. One of the KAME developers is active on the NetBSD mailing list, and continues to directly support the NetBSD port of KAME. IPv6-aware versions of popular tools like apache are available in NetBSD's pkgsrc, as well as directly from KAME.
There's a distinct lack of good punctuation marks available. Grr.
--
Ben Kosse
Remember Ed Curry!
I won't dispute most of what you've said, only this:
IPSEC can be NAT'd -- The black tunnel endpoints are not encrypted, and most of the time not included in the encrypted data.
I've got an IPSEC client I use for work and a Linux "firewall" that masquerades IPSEC rather nicely.