On Fri, Sep 30, 2005 at 11:24:52AM +0200, Jeroen Massar wrote: > 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.
Such a client would not be able to write /etc/resolv.conf without something in userspace (or, at least, without some ugly hacks). > This is just a matter of design. Hurd for example does TCP/IP in > userspace, thus if they ever would implement IPv6, That's the magic word, isn't it? ;-) Anyway; doing RA in userspace, while probably possible, doesn't strike me as a particularly good idea if the network stack itself runs in kernel space. > > > > 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? Well, no. D'oh. That's *exactly* my point. > Anycast is a routing trick, no clients or serversside tricks are > involved. Of course not, but if you switch from IPv4 to IPv6 IP addresses in /etc/resolv.conf (or the equivalent thereof for your operating system), you'll need to configure that just one time. Hence the 'scripting' which you will do once. The thing is that you still need 'something' to set up your routing. You could use DHCP for that, but it's not as interesting, since clients are not required to implement it. > > 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. That's a major difference, actually. If your DHCP server goes down for some reason, your clients lose their network once their lease expires. How often that is obviously depends on your configuration, but if your network is large enough, the first clients will start losing their network connection after a few minutes already. If your RA server goes down, the same doesn't happen. RA actually assumes your server will go down at some point. Indeed, when I changed my v6 router at home to start broadcasting a different address, one of my machines still had the old address three days later, when I logged in to reboot it to a new kernel. Since the old address had lower priority, it was not being used, so this doesn't hurt; but if rather than the RA daemon sending out new addresses, it would have gone down, I could've continued to use this box for far longer than that, without noticing anything. Obviously, new machines will not get a functional IP address without RA packets; so you don't want your RA setup to go down for more than a day or so. But if it does break down at some point during the working day, then there's no reason to be all stressed about it, or something, because people will still be able to use their network. Another case where it's clear that DHCP assumes the DHCP daemon is up at all times is when you first connect to the network. If you connect to a network with RA, and there's nothing, then you don't have network -- but you can set your network interface to be "up". If you connect to a network with DHCP, and the DHCP daemon is down, then the DHCP client will try for a while to connect to the network, will eventually decide that there is nothing, and stop sending out DHCPDISCOVER packets. Once this happens, the only way to get network on that machine is to restart the process, which may be troublesome if you're $FAR_AWAY from the machine. > > > 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? Of course not -- I didn't say that, either. > It all requires installation and configuration. Sure. However, with RA and some more tricks, I feel the IPv6 network will require less administration than the IPv4 one. If you don't see that, you're either blind or like to micro-manage your network. > > 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. I disagree. > You need to install software on the clients, servers and routers and > you need to configure them all. Obviously. > The only real noticable difference is longer addresses and some > terminology. And some benefits and new features, such as RA and address scope. Which will go a long way towards helping you make the transition easier when you use to IP stacks. [...] > > 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. You're crazy. I said a host has to support 'IPv4' to be compliant. I never said that IPv4 support also has to include something completely and utterly different which happens to be supported by both IPv4 and IPv6, such as IPSEC. If you think differently, I urge you to go learn some better English. > > > 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? That's not the important question. The important question is: how many protocols do you expect to be using during the lifetime of your proxy, and how many of them are you willing to give up because reconfiguring the proxy to support them (or adding a second system for that function) is going to be too expensive and/or difficult? > Also for dual-stack you would have to fix all your apps too. If you switch to IPv6, you'll have to do that anyway. And since the IPv6 API includes IPv4 support for free, there isn't much work to be done to get that to work. > > 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. Uh, I think we're talking about different protocols here. I actually meant application-level protocols -- things that run on top of TCP or UDP or so. Say there's this new shiny and hot buzzword that involves some new protocol going over your network. But oh -- this is a very strange protocol that doesn't really like being NATted, or so. > 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. Yes, and that's unfortunate. On FreeBSD, for example, you don't need two different applications to implement firewalling for IPv4 and IPv6, and that is clearly superior; indeed, you can say things like "this group of IPv4 and IPv6 addresses belong to mail servers. Now for my mailservers, open port 25 and nothing else", and it will do that. The same isn't possible for other dual-stack networks, such as (say) IPX with IPv4, or so -- at least not AFAIK (not too comfortable with IPX). [...] -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
