Re: Ipv6 DNS and ipv4 host - Tranistion problem
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
Reply to: