On Fri, 2005-09-30 at 13:43 +0200, Wouter Verhelst wrote: > 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). Just implement it using a proc interface and then: "ln -s /proc/net/resolv.conf /etc/resolv.conf" :) Which is IMHO pretty clean. Then again I'd like to see more stuff getting moved out of kernel space into user space, the performance-odds are a bit against this though. > > > 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. When your radvd dies, try it with a nice kill -9, the route also goes away after some while. Most RA setups though don't have an expiry. DHCP of course can be configured with an infinite expiry time too. No difference here either. > 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. This is a not a property of RA but a property of IPv6, one can also setup multiple DHCP boxes, have mixed RA/DHCP environments, manually add addresses etc. > Obviously, new machines will not get a functional IP address without RA > packets; Not exactly; an interface that goes up gets a link-local address, this is a fully functional address that one can use to communicate to other machines. One just doesn't get global connectivity with it. This is called the "dentist's office" example. Most good books about IPv6 list it. Side-note; LL's are great for rescueing machines, as long as one can be on the same link you can ssh into the box using it's LL address, just ping6 ff02::2 to find out where it is, then pick the right one. Another reason why having EUI64-derived addresses in DNS is handy, as one can also find out the LL address from it easily. > 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. RA servers usually run from routers, as such, you don't want them to be down as then you don't have any connectivity to the outside, unless you have of course multiple routers announcing the same prefix. But that is the same as getting two DHCP's and thus two default routes, which is also what happens with multiple RA's eg: default via fe80::2d0:ff:fe83:a000 dev eth0 proto kernel metric 1024 expires 166sec mtu 1500 advmss 1440 hoplimit 64 default via fe80::2d0:ff:fe8a:400 dev eth0 proto kernel metric 1024 expires 166sec mtu 1500 advmss 1440 hoplimit 64 Note the 'expires 166sec' in there. > 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". "ip link set dev eth0 up", try it without RA or DHCP, both get marked up and both get linklocals. No difference here either. Actually dhcpv6 will mark the interface up, it has to: to actually be able to send the DHCP packet and next to it because then it uses the LL to send out the DHCP request. Next to that the RA message contains a bit flagging the network as being 'managed', which means that the host should try DHCP. Though one can do DHCP with RA. > 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. Depends completely on the configuration of the client daemon. Default installs (but hey what is default when one can make custom images and run scripts when installing boxes) don't wait forever, but others do. > 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. Then I wonder why my dsl box at home, which is 800km or so from where I usually am always gets up again. DSL is sometimes flaky because of a very old alcatel box and it always comes up again. > > 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. Then I am probably blind, because really there is not much of a difference. The only reason why a network could potentially have less administration is because with IPv4 one most likely gets a NATted network, with IPv6 it is public address space. > > > 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. Reasoning and argumentation? What do you have to do less? In both cases you need to: - install them - update them - configure ACL's - etc So what is the difference? Especially in the cases where you can automate things, which in bigger networks always happens, unless one didn't get the idea of automation. > > The only real noticable difference is longer addresses and some > > terminology. > > And some benefits and new features, such as RA and address scope. Address scope is going to help? It is giving a lot of pain actually :) And as I mentioned, RA is just a form of autoconfig, with DHCP providing more options. > [...] > > > 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. Yep, "airplane airplane, vroooom" :) > I said a host has to support 'IPv4' to be compliant. Do you mean here "IPv4 addressing format" or "IPv4 stack" or "IPv4 connectivity" or "IPv4 <fillin>". Which part of the compliancy do you mean? As I am crazy, to what was it supposed to be compliant for it to need that IPv4 part? > 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. I mentioned IPSEC as a sidenote showing that there are many hosts that are claimed to be "IPv6 compliant" but don't include an important bit like IPSEC, which is always touted to be 'the great security feature of IPv6'. > If you think differently, I urge you to go learn some better English. I strongly think differently and I am quite sure my english is fine, even though I don't capitalize the word. > > > > 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? The important question is: can you make the applications do both IPv4 and IPv6, do you have the source, or do you have a closed system? Quake2 didn't support IPv6, but it did after the source was released. Before that one could use it using a IPv4 to IPv6 proxy, though on both the client and server side. It did allow one to play Quake2 over a network which didn't have IPv4 connectivity. > > 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. Ever re-coded an application, something more than a simple connect(), to support IPv6? I would say: enjoy the time and don't forget to read: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html getaddrinfo() makes it really easy, but many applications don't use that interface, even though it has been around for a long long time. > > > 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. TCP and UDP run over IPv4 and IPv6 (dual stack), the reason for you to need to update the application-protocol (l4) is because one is embedding IP (l2) into the l4 protocol. When the app supports both IPv4 and IPv6 one is fine of course, until you are trying to talk to an IPv6 only host from an IPv4 only one, or to IPv4 only one from an IPv6 one. Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part