From: Tim Chown (tjc_at_no.spam)
Date: Tue Nov 13 2001 - 16:36:46 PST
On 13 Nov 2001, D. J. Bernstein wrote:
> Why should I do this manually? Why doesn't the software _automatically_
> give me an IPv4-compatible IPv6 address, as explained in RFC 2893?
If you do that, you're assuming that the host you want to communicate
with is also capable of handling automatic tunneling and thus has an
IPv4 compatible address. If the target is IPv6 native (a valid IPv6
target) then RFC 2185 suggests a relay method for reaching the target
but a) you would need a local "default" IPv6 router capable of handling
automatic tunneling and b) you have the problem of how the packet gets
routed back if the source address is IPv4-compatible (which RFC 2893
says it can be). Compatible addresses can add complexity. Anyway,
you need a v6 router if you want to talk to all v6 hosts.
Also, if of course you don't have a globally routable IPv4 address, you
can't use IPv4-compatible addressing for global tunneling. So anyone
behind a NAT wouldn't have any use for (off-site) compatible addresses
(you must have a few NATs over in Tonga? ;-)
If you have an architecture with end-to-end tunnels only, how are you
protecting your IPv4 network if you're firewalling, and you now have
IP-in-IP potentially to any host inside your network? Existing tunnel
brokers accept protocol 41 very trustingly. What's the tunneling
overhead, in performance, bandwidth, state, etc, where all hosts may
initiate many tunneled connections?
What's the DNS implication? A host indicates IPv4-compatible capability
by having an IPv4-compatible AAAA record, but it may also have native
or other connectivity (e.g. 6to4). Adds complexity when you're also
selecting the protocol to use in a dual-stack node anyway.
There are tools for IPv4-IPv6 and IPv6-IPv4, and for connecting IPv6
islands via IPv4 (6to4), but there seems to be little advocation for
flat end-to-end tunnelling. To an even greater extent than tunnel brokers,
a world of IPv4-compatible IPv6 doesn't promote "genuine" deployment. The
favoured direction seems to be 6to4. ISATAP is a new contender for
intra-site auto tunneling, perhaps behind a 6to4 router.
The single hop end-to-end model certainly doesn't allow multicast, though
6to4 has problems there too.
> Our system administrators are busy getting real work done. Do you expect
> them to waste time figuring out how to join a useless network?
I would hope v4 admins would be tracking and experimenting with new
technology (as "new" as v6 is). Making a deployment decision is up
to you, of course. There's a wide range of transition tools (which I
suspect is part of the "no big picture" problem).
> Some of our computers and routers already have IPv6 software. But we're
> not going to bother configuring those machines to talk to the global
> IPv6 network. If you want IPv6 addresses to be part of the Internet---if
> you want them to be reachable from machines like ours---then you have to
> give us software that does _not_ require extra configuration for IPv6.
There's a distinction between addresses and hosts. Plug and play is
a supposed advantage of IPv6, but that assumes you're on link and seeing
an advertised prefix. In potential consumer environments, that can be
hidden from the end user.
tim
This archive was generated by hypermail 2.1.7 : Fri Oct 06 2006 - 00:00:25 PDT