On Thu, 2005-09-29 at 22:25 +0200, Wouter Verhelst wrote: <SNIP> > DHCP requires a userspace client; RA is a feature that is enabled as > soon as you have an IPv6-enabled network stack and a network interface > that is up and physically connected. DHCP can also be implemented in the kernel, just like the RA client. This is just a matter of design. Hurd for example does TCP/IP in userspace, thus if they ever would implement IPv6, the RA component would also be there. An IPv6 host could do without RA support and just implement DHCP. Not many people would find it really useful but still. DCHP/RA is just a matter of choice depending where and why you want to use it. > > > For higher-level protocols, using an anycast IP for those things that > > > are really required in a network (such as the DNS server) will make it > > > possible to configure those statically on your client machines (which > > > you do by scripting it the first time, obviously). > > > > You can do the same with IPv4. > > Sure. However, you cannot easily use anycast for routers (that would > give problems with hosts that have connections to more than one network, > without being a router themselves), hence the need for "some" solution > there that does not require changes on the clients when there are > changes on the network. Did you change anything on your computer when the root-servers started become anycasted? Anycast is a routing trick, no clients or serversside tricks are involved. > Since IPv4 does not have route advertisement, you could not have a > similar (anycast DNS + RA routing) setup there. As I mentioned, replace RA with DHCP, there is not much of a difference, except that in DHCP the server chooses the IP and with RA the client chooses it and that DHCP is stateful and RA is stateless. > > The fact that you say you are scripting is already configuring, thus > > removes the whole idea of RA in the first place. > > You'll need to update the clients anyway when you introduce IPv6. > > Gee, I never said you wouldn't have to do /anything/ to introduce IPv6, > or that there would be /no/ configuration at all. What is the difference of installing an "IPv6 stack" or "IPv6 stack + your cool script" or "IPv6 stack + DHCP client"? not much is it? It all requires installation and configuration. > What I'm saying is that there is less configuration to do. And this is > true; sure, you need to update your clients, sure you need to set up > some extra servers. But once everything is up and running, your clients > will require /much/ less configuration to keep running than is the case > for IPv4. There is no difference. You need to install software on the clients, servers and routers and you need to configure them all. The only real noticable difference is longer addresses and some terminology. > Uh, I'm not going to engage in a silly "did too!" "did not!" game, See the archives, they show that you did, having an actual valid argument might help you here. [ One more 'did too' than you 'do not'! <evil grin> ] > sorry. I didn't even know there are cases where Linux IPC uses the IPv4 > stack; I thought that was a "feature" of XFree86. Most OS's use IPv4 for some form of IPC. As an example Mozilla/Firefox for long didn't support IPv6 on Windows for the same reason; they use a IPv4 socket to communicate between the various components and they had some mental issues in having it also getting it to support IPv6, because of mapped addresses which are not supported on Windows due to the simple fact that on Windows the IPv4 and IPv6 stacks are completely separated. As Windows didn't support the mapped stuff, they would have to setup 2 seperate sockets for IPC and that completely spoiled the way they designed the IPC functions as suddenly one has to do select() and other creepy stuff. Just for ze record(tm): I understand quite well why they did it that way and yes, redesigning it then afterwards is not an easy task... > Fact is, you can't set up a compliant IPv6 box without some support for > IPv4. Then I really wonder what that box under my desk is. According to TAHI tests it is fully IPv6 compliant, it even has working IPv6 IPSEC :) Oh and no IPv4 to be found in the kernel or in userspace, took some time to get that to work but it does. > > > > > You can't set up an IPv6 host that cannot be assigned > > > > > an IPv4 address. > > > > > > > > Why not? > > > > > > Because an operating system that supports IPv6 is required by the > > > relevant RFC documents to also support IPv4. If you find an operating > > > system that does support IPv6 with IPv4-support disabled, then they > > > violate several RFC documents. Such as RFC3493, section 3.7. Go read it. > > > There are more RFC documents that spell out the requirement of support > > > for both protocols; I'm too lazy to go and dig them all out for you, but > > > I'm sure you'll find them if you start looking. I know I did, last time > > > I tried. > > > > You misread it the RFC, which is not a IETF STD (standard) btw. > > News flash: RFCs ... Please don't try to explain IETF procedures to me... > > RFC3493 only specifies the API. > > A network API is fairly useless if it doesn't have a network stack that > behaves the way the API thinks it will. As I noted it doesn't need IPv4 as you can embed it over the wire. > > The section you refer to states that the API _SHOULD_ support IPv4 > > mapped/compat addresses. > > Dude, get off the drugs. Indeed, don't go to the local 'coffee shop' drink some real coffee. > ::FFFF:<IPv4-address> Which is what goes over the wire, and the OS really can't care less as it is IPv6 for it. eg "[2001:db8::1]:1234 -> [::ffff:192.0.2.1]:80" would be a tcp connection to a webserver on 192.0.2.1. Normally you will not see it going over the wire that way, and actually you don't want to for various reasons, but it is possible and also the reason why it is specified in the API. IMHO they really should take out all this IPv4 compat/mapped support though and there has been some movement to deprecate all of this. <SNIP> > Now, explain to me please how such a dual-stacked gateway is supposed > to tell its applications the difference between an IPv4-mapped address > that arrived to it over the wire, and an IPv4-mapped address that it > locally had to generate so that IPv6-using applications are able to talk > to IPv4 machines? Why would it need to know the difference? > Yes, this is necessary -- there's a reason why your TRT example uses a > different address space for IPv6-mapped IPv4 addresses. It can use both. Try it. > > Also, if you are saying that it has supports everything to be IPv6 > > compliant, > > ... > > Okay, I'll bite. Where the fuck did I say that a host has to support > everything to be IPv6 compliant? > > Answer: I didn't. You did, to quote you: "Because an operating system that supports IPv6 is required by the relevant RFC documents to also support IPv4. If you find an operating system that does support IPv6 with IPv4-support disabled, then they violate several RFC documents. Such as RFC3493, section 3.7. Go read it." In which you imply that if it doesn't support it it isn't IPv6 compliant, otherwise it would not be 'violiating RFC's", which it isn't. > I've had enough of this, really. Go read some standards documents, > please, and stop putting words in my mouth. Which standard document? Most IPv6 documents, produced by the IETF that is, are still in RFC or at most Draft or Proposed Standard state. FYI and reading happiness: http://www.rfc-editor.org/rfcxx00.html > > then there are not many IPv6 compliant machines on this planet, as > > most do not do IPv6 IPSEC. > > I didn't even mention IPSEC. But I did to show you that there are not many hosts doing full IPv6. <SNIP> > > Dual-stack is the 'easiest' way from one perspective, but that doesn't > > mean that there are no others. Many IPv6 systems are using tunnels over > > IPv4 at the moment anyway, this is effectively the same as translating > > it. > > I disagree, but let's not go there. > > (translating is NAT; tunnels are a completely different beast. While > both functionalities are often implemented by the same device, > especially on small networks, it's important not to mix things up, which > you appear to be doing here) Tunneling is effectively translating the address twice: IPv6 -> IPv4(+IPv6) -> IPv6 NAT in principle is not a bad thing, the problem is that it is used normally in one direction > > I can at the moment build an IPv6-only host, connect it to my network at > > home, or any other place that has DHCPv6 or RA+self-configged-DNS. It > > will then nicely browse all IPv4 websites with http://ipv6gate.sixxs.net > > The same application proxy trick can be installed easily and quickly > > using TRT and a number of other methods. Much easier than having double > > IP addresses on all the hosts and managing all of that. > > Yes, but you don't have full network capabilities; you'll lose > everything except for those protocols you're setting up a gateway for. Of course. But how many protocols do you actually use? Also for dual-stack you would have to fix all your apps too. > Network requirements change. At some point, you'll need to enable some > extra protocol that you didn't think of when you were setting up the > gateway, and that will require some extra configuration, completely > unlike what you already have on your gateway. In dual-stack that would require you to upgrade all the clients and servers to support this new protocol. With a gateway you do that in 1 spot. > Also, note that there's no reason why you would need two firewalls or > two routers to be able to provide both IPv4 and IPv6 to a network; it's > perfectly possible and feasible to use the same device for both. But, taking linux as an example; I have "iptables" and "ip6tables", and I have to set them up separatly. As there is still no state (afaik) in the Linux Kernel for IPv6 I can't re-use my rules and simply also add them with ip6tables. Next to the obvious fact that the addresses used are completely different. > > But it all depends on perspective and applicability. Which is also the > > reason why there are so many transition mechanisms, as not all of them > > are useful/possible/acceptable everywhere. > > I'm not denying that. I'm only saying that if you want an IPv6-only > network, you'll be cutting yourself off of most of the Internet. At the moment yes. But that is the same as using IPX (or MSN versus ICQ or ... bitlblee is a gateway remember, just add protocols in one spot), when the other side doesn't support it it won't work. > That there are ways to bypass that problem (proxies, gateways, ugly > setups) is not something you'll see me deny; but I think it's a silly > idea, for there's a far easier way to set up things -- provide routing > and firewalling for both protocols (which isn't as hard as you seem to > suggest), and let your clients use the protocol they want or need. Try that again with a network with say 10 million devices... and please upgrade them all in time ;) As I said, depends on perspective and where you try to apply it. (Not that a single gateway will scale very well but still, better than trying to update all the client boxes ;) Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part