On 5 jan 2008, at 1:57, John C Klensin wrote:
We may have a philosophical difference of opinion here. If we
do, the IETF list is probably not the right place to resolve it.
However, in the interest of explanation, not debate, I believe
that
It seems we're actually mostly in agreement: for IPv6 to be useful, it
must be possible to run IPv6-only in at least some places.
But any form of "the application has
a choice of multiple addresses or interfaces and must choose"
puts the application into the routing business.
Well, someone has to do the dirty work... My years in multi6 taught me
that the people at each layer would be much happier if the complexity
happened at one of the other layers. Unfortunately, the routing layer,
which can solve this problem in small networks, can't do the same in
large networks because of scaling issues. (And our protocols aren't
especially smart: BGP knows how to avoid bad paths successfully in
most cases, but it isn't very good at picking the best path.) Even
today we have scaling issues even though a single entry in the routing
tables is the aggregated information pertaining to hundreds or
thousands of hosts. It would be possible to make a transport protocol
that handles this issue, but that won't happen until we actually do
the work to make that protocol, because TCP isn't it: it can't even
migrate to a different address if the current address doesn't work.
SCTP can do that but current implementations are limited to finding a
working address, not the best one or even a good one from the set of
working addresses and switching from TCP to SCTP is just as bad as
moving from IPv4 to IPv6. This means that all applications that use
TCP in an environment where there is the possibility that there are
multiple addresses must be prepared to retry a session setup attempt
until one works using in succession the addresses returned by the name-
to-address mapping (= DNS).
(And IPv6 is a multi-address environment by design even without
recognizing that running dual stack obviously requires two addresses.)
The selection of the best address is currently under the purview of
RFC 3484, which doesn't have the tools to solve this issue
satisfactory but at least keeps the issue out of the applications,
except for trying addresses until one works. Really solving this means
communicating preference values and doing reachability tests and QoS
measurments, which is currently a research topic rather than an
engineering topic.
Even the trivial example that Jeroen and Phillip used may be
problematic, especially if there are multiple IPv4 and multiple
IPv6 addresses. There are no MX rules at all about which
address must be tried first and some handwaving in RFC 2821
about how many addresses at a given preference level need to be
tried at all.
Well, this is what I have:
IN MX 100 sequoia.muada.com.
IN MX 200 mailv4.muada.com.
sequoia has both IPv4 and IPv6 addresses and the choice between those
should happen using RFC3484, which, AFAIK, is generally implemented by
ordering getaddrinfo() (successor to gethostbyname()) results. mailv4
doesn't have an IPv6 address in order to avoid triggering bugs, which
was a consideration a few years ago.
RFC 3484 suggests the use of a policy table that lets administrators
set the relative preference of certain address ranges (IPv4 or IPv6).
By default, IPv6 is preferred over IPv4, but with the policy table,
this is easily reversed in the general case or for certain address
ranges. Note also that applications can either ask for IPv4 addresses,
IPv6 addresses or "any" type, with the latter generally resulting in
the subset of available addresses for a name that is presumed
reachable from the availability of IPv4 and/or IPv6 addresses and
default routes on the system. I.e., if the application simply asks for
"any" then it doesn't have to worry about IP versions.
I can't think of any application that would need to query for
NS records for the root. This is the only place where stuff is
going to change. AAAA records have been popping up all over
the rest of the DNS hierarchy for years so this is something
that applications should be used to by now.
It would need to have AAAA records for the root available if it
needed to query the root servers over IPv6. And it would need
to do that if it, or the network on which it operated, was
IPv6-only.
Like I said, I don't know of any application that needs to do that.
Also, obviously the addition of AAAA records can only help hosts that
are IPv6-only.
(4) If we conclude that having an IPv4 address (direct or via
some NAT arrangement) is a requirement for every host that we
expect to run IPv6, and such addresses are necessary and
sufficient for those hosts to communicate with the network, then
we will have demonstrated that IPv6 serves no useful function.
I don't think that is true and I don't think you want to go
there.
Well, any proxy or ALG that allows IPv6 hosts to talk to IPv4 hosts
involves and IPv4 address that the IPv4 hosts perceive as their
correspondent's address, and the IPv6 host in this communication could
be perceived to "have" this IPv4 address. I don't think the presence
of a very limited number of such addresses can reasonably be taken as
an indication that IPv6 has failed. The current situation is that
about 0.1% of the internet is reachable over IPv6. If no further
progress is made, we can qualify this as failure, even if I can turn
off IPv6 and still get work done through proxies etc. But as the
original message in this thread shows, we're still making progress.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf