Re: Ipv6 DNS and ipv4 host - Tranistion problem
On Thu, Sep 29, 2005 at 07:51:26PM +0200, Jeroen Massar wrote:
> On Thu, 2005-09-29 at 18:58 +0200, Wouter Verhelst wrote:
> > On Thu, Sep 29, 2005 at 06:23:52PM +0200, Jeroen Massar wrote:
> > > On Thu, 2005-09-29 at 17:56 +0200, Wouter Verhelst wrote:
> > > > A properly configured IPv6 network will not require as much work as is
> > > > the case for IPv4.
> > >
> > > Can you elaborate on this?
> > >
> > > Except for the fact that one will most likely get a /48, there really is
> > > not much of a difference in IPv4 versus IPv6.
> > >
> > > There exist DHCPv6 and DHCP (for IPv4), routing protocols are the same,
> > > DNS is the same. The only thing is that IPv6 addresses are longer and
> > > thus are more inconvienient to remember. For ther rest what will
> > > actually lighten the load?
> >
> > DHCPv6 exists, but is not required for a fully-functional IPv6 setup on
> > the network level (you can use route advertisement instead).
>
> But in a big network you don't want to use that as you want to be able
> to manage it and provide some extra settings, eg routing preferences and
> dns servers. There is actually not much of a difference in setting up a
> DHCP or an RA server, both still require one to install the software or
> to enable it.
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.
> > 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.
Since IPv4 does not have route advertisement, you could not have a
similar (anycast DNS + RA routing) setup there.
> 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 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.
> > > Note also that inplace prodedures for updating all IPv4 tools to also
> > > support IPv6 is not a lot of fun...
> >
> > No; however, the pain of moving from IPv4 to dual-stack is not larger
> > than the pain of moving from IPv4 to IPv6-only systems.
>
> Not true, one doubles the pain as suddenly you have to manage 2 separate
> systems, update 2 firewall sets, watch both of them, update both of them
> etc. It's the same as having 1 server to watch, or 2 seperate ones:
> double the trouble.
>
> > > > Note that IPv6 requires a working IPv4 stack to be present in order to
> > > > function properly.
> > >
> > > Why would a host require IPv4? That for instance Linux 'design' doesn't
> > > allow it because IPC uses IPv4 in some cases doesn't mean one have to
> > > have IPv6 on all platforms.
> >
> > I didn't say that. Don't be silly.
>
> But you did write it. Rephrase please what you did intend to write.
Uh, I'm not going to engage in a silly "did too!" "did not!" game,
sorry. I didn't even know there are cases where Linux IPC uses the IPv4
stack; I thought that was a "feature" of XFree86.
Fact is, you can't set up a compliant IPv6 box without some support for
IPv4.
> > > > 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 can only be promoted to STD status once enough
software implements whatever they define. But if nobody ever does that,
then nothing will ever end up being an STD. Given the (comparatively)
fairly recent status of IPv6, it's not surprising that not all IPv6 RFCs
have received STD status yet.
That doesn't mean such RFCs are useless.
> 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.
> The section you refer to states that the API _SHOULD_ support IPv4
> mapped/compat addresses.
Dude, get off the drugs.
3.7 Compatibility with IPv4 Nodes
The API also provides a different type of compatibility: the ability
for IPv6 applications to interoperate with IPv4 applications. This
feature uses the IPv4-mapped IPv6 address format defined in the IPv6
addressing architecture specification [2]. This address format
allows the IPv4 address of an IPv4 node to be represented as an IPv6
address. The IPv4 address is encoded into the low-order 32 bits of
the IPv6 address, and the high-order 96 bits hold the fixed prefix
0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows:
::FFFF:<IPv4-address>
These addresses can be generated automatically by the getaddrinfo()
function, as described in Section 6.1.
Applications may use AF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6-address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call. When applications use AF_INET6 sockets
to accept TCP connections from IPv4 nodes, or receive UDP packets
from IPv4 nodes, the system returns the peer's address to the
application in the accept(), recvfrom(), or getpeername() call using
a sockaddr_in6 structure encoded this way.
Few applications will likely need to know which type of node they are
interoperating with. However, for those applications that do need to
know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
provided.
Where does it say "SHOULD"?
Moreover, where in the _entire_ RFC are RFC2119-style keywords used?
Answer: nowhere.
Did you actually read it, or are you just selling bullshit? I suspect
the latter.
In any case, the above doesn't use
> A 'SHOULD' is not mandatory. Next to that even if it does support
> this, which is dead easy as one only has to parse a bit, there is no
> reason why the host must have an IPv4 stack as the packets can simply
> be sent onto the wire. A gateway can there handle the conversion to
> 'real' IPv4.
>
> This gateway indeed does have to be dualstacked.
Right.
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?
Yes, this is necessary -- there's a reason why your TRT example uses a
different address space for IPv6-mapped IPv4 addresses.
> 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.
I've had enough of this, really. Go read some standards documents,
please, and stop putting words in my mouth.
> then there are not many IPv6 compliant machines on this planet, as
> most do not do IPv6 IPSEC.
I didn't even mention IPSEC.
Gimme a break.
> > [...]
> > > There are really a lot more transition mechanisms than dual-stack, check
> > > for instance:
> > >
> > > http://www.join.uni-muenster.de/Dokumente/Howtos/Howto_TRT.php?lang=en
> > >
> > > > The day IPv6 can reach about 75% of the net, your plan might be viable.
> > >
> > > Not if one arranges gates to the IPv4 networks using eg the above.
> >
> > I thought we were talking about making things easier. Using a gateway
> > certainly is a possibility, but it hardly makes things easier.
>
> 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)
> 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.
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.
After a while (this may well be a few years), you'll end up with a
complex situation involving one or more gateways providing proxying
services for one or more network services. It's far easier to provide
both network protocols.
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. And
since they are so related, it's not a bad idea to use similar firewall
settings for both protocols (even if there will of course be /some/
differences, due do the fact that both protocols are, after all,
different, if only in the details).
> 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.
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.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: