On Wed, 2007-08-01 at 10:41 -0300, Henrique de Moraes Holschuh wrote:
>
> Can we have a "enable IPV6 yes/no" question in the installer? That fixes all
> problems in one go. Then tweak the system's defaults for the answer.
Hardly. It fixes *your* problems, while making new ones for me. When I
turned on IPv6 on our LAN suddenly there were 86 more computers with
usable IPv6, whereas if there had been a configuration option for it I
guarantee most of the people installing those computers would have said
"IPv6? It'll never happen..." and chosen "No".
Without IPv6 turned on by default, are people ever going to write
patches like the one Mithrandir wrote for the kernel? Or expose the
configuration of the ordering of preference for responses to calls to
getaddrinfo, as /etc/gai.conf does?
Wouter's comparison with UTF-8 is a valid one! How many years has UTF-8
been around? How many years before we can lose non-UTF locales? We
need experience and exposure to make these changes, not head-in-the-sand
"I'll never want that newfandangled stuff".
Personally I have chosen to enable IPv6, rather than disable it. To
make it work, rather than redefine it as broken. Having taken that step
I discover that it has a lot to recommend it, and I am also going to
start recommending it to some of our clients, where there is some
benefit to be realised.
As a result of enabling it I have also discovered bugs in various pieces
of software that I have some responsibility for, and I have fixed them
> > dig @192.168.1.1 AAAA andrew.mcmillan.net.nz
>
> Wasted one extra second, here. And you bet it would blow up if something
> tried to actually use THAT to connect over ipv6, since I only have ipv4 :-)
That extra second (which wouldn't happen with the /etc/gai.conf change)
is mostly due to the fact that you are in Brazil and my nameservers are
in New Zealand and the network paths between us are tortuous in the
extreme. And of course the result will normally be cached after that
initial query, so you will have perhaps noticed an extra 1 second.
It's not the only query you could get an extra second out of... as of a
few months ago we enabled IPv6 nameservers for .nz, so both of:
dig AAAA ns1.dns.net.nz
dig AAAA ns2.dns.net.nz
are also responding with (and on :-) IPv6. Hopefully we haven't
completely screwed the world's access to the 300,000-odd domains in .nz!
> One second is a *lot* to waste on name queries. You do not even want those
> to be produced, in a IPV6-less box. Note: ipv4 box asking bind on a ipv4
> box, with bind configured to only deal with ipv4.
They won't be. The ability to ask for a specific response type is
something that you can do with DNS utilities, but not something that
libc will be doing unless there is some level of IPv6 enablement on the
box.
Without Mithrandir's patch 'enablement' means 'has an IPv6 address on
some interface', whereas with his patch it means 'has a globally scoped
IPv6 address on some interface'. This should *eliminate* any pain from
having ipv6 loaded, ready and waiting, other than for people who
(manually) configure some IPv6 in a broken manner.
> > In recent glibc installations the second problem *can* also be worked
> > around by editing /etc/gai.conf to give the highest priority to IPv4
> > responses. This will mean that the call to the resolver will return
> > when it receives the IPv4 address, without waiting to see if a higher
> > priority address may yet be received.
>
> Now, *that* is useful information! Thanks!
I'm afraid I would only reccommend it as a last resort, though perhaps
someone with some spare time could create a Debian package called
"prefer-ipv4-over-ipv6" which mucked with that file, so that people
could uninstall it if they ever did go IPv6, and so that some of the
IPv6 tools could conflict with it.
> > It seems to me that the patch Tolleff has written should remove that
> > inconvenience, so the effects of problem #2 will become invisible
> > (except to the poor people in such situations who try and actually use
> > IPv6 :-)
>
> Not completely, you still get extra name resolver delay unless you fix the
> resolver to prefer IPv4 (and maybe even then -- I didn't test). That also
> needs either to be documented, or to be enabled by default.
Really? My reading was that his patch changes the libc behaviour to
only do the 'AAAA' lookups if IPv6 is being used. It seemed to me from
reading it a few times through that IPv6 could be loaded, and you could
have an IPv6 localhost configured, and a link-local address, but unless
there was some actual IPv6 traffic around it would only do 'A' lookups.
Maybe I misread it though - I'm certainly no libc guru. Anyone else
care to comment on the exact effects? This seems to be the crux of it
here:
+++ sysdeps/unix/sysv/linux/check_pf.c 2007-04-02 21:39:46.000000000 +0200
@@ -130,7 +130,10 @@
*seen_ipv4 = true;
break;
case AF_INET6:
- *seen_ipv6 = true;
+ if (ifam->ifa_scope < RT_SCOPE_LINK)
+ {
+ *seen_ipv6 = true;
+ }
if (ifam->ifa_flags & (IFA_F_DEPRECATED
| IFA_F_TEMPORARY
It seems to me that will need a globally scoped address to be assigned
before it will consider that IPv6 is a happening thing and start sending
(or waiting on) AAAA lookups.
Cheers,
Andrew.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Excellent day for putting Slinkies on an escalator.
-------------------------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part