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?"
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)
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.
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.
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.
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!
Actually, I believe that Debian already enables IPv6 in many programs (sometimes with patches). I haven't tried this myself, though, so I don't know how well it works.
Daniel
Hurry up and jump on the individualist bandwagon!
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.
yes, so your IPv6 adress WILL be static, possibly even on a dailup. This means that it may be easier for websites to track you without the use of cookies. It means if you get glined from an irc network you can't just logoff and log back on.
But it also means that you can host a web/ftp/etc server and have it be in the same location all the time; it also means you can buy a .com or .net or whatever domain name. Basically it means everything that having a static IPv4 adress meant.
This is not something that the IPv6 protocol makers should be worrying about. After all, if you'll remember, the entire point of the IPv6 standard is to create a system whereby everyone gets their own static IP. The privacy concerns are something that your ISP should be handling. Talk to them. And the ISP can handle this probably by setting up a system whereby you change your IP occationally if you want to; this is how some *dsl and cable providers handle the exact same privacy problems (since *dsl and cable also have static IPs).
But the fact is that a lot of people-- me, for instance-- would _want_ a static IP. And there's no real way that the people writing the IPv6 protocol _can_ do anything about privacy concerns arising from static IPs, since there's no system i can think of where you can't be tracked but can have a DNS name.. The ISP should be the one you should be complaining to.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Ahem.....one of the most emphasized points with IPv6 is that renumbering should be EASY.
We KNOW that sites hanging on to an address when changing providers is a long term disaster - the routing tables just get too big.
There's lots of things in IPv6 to support renumbering. So expect addresses to be relatively static - but do NOT write them down if you don't absolutely have to!
(Yes - there is stuff in DNS too. Look up A6 records in the internet-drafts directory.)
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.
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
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
For 6bone info, see http://www.6bone.net/
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...