--On Friday, 04 January, 2008 22:16 +0100 Iljitsch van Beijnum
<iljitsch@xxxxxxxxx> wrote:
> On 4 jan 2008, at 21:46, John C Klensin wrote:
>
>> If we are now making
>> decisions about IPv6 deployment that effectively force the use
>> of an ALG,
>
> Huh?
>
> What are you talking about?
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
(1) Some of the most attractive low-lying fruit for IPv6
deployment involves IPv6-only machines (whether by design or
configuration) running on IPv6-only networks. While I've
never considered it nearly as important an example as the IPv6
Forum has, if the 3G Wireless use of IPv6 is relevant to IPv6
deployment at all, it is precisely an example of IPv6-only
machines in an IPv6-only environment.
(2) IPv6 is not plausible as a network technology -- as distinct
from an IPv4 extension technology -- unless one can run
IPv6-only networks. How much, and for how long, such networks
would have to be able to access applications and resources in
the IPv4 network(s) is a separate question. As an IPv4
extension technology -- e.g., a mechanism for using 30 or so
bits of the IPv4 address space as a network identifier [prefix]
and putting the LAN-local address somewhere else, IPv6 is far
too complicated for its likely marginal value.
(3) As Keith Moore has pointed out repeatedly for the general
case and as I and others have pointed out for more specific ones
(including today's mail-and-DNS case), dual stack is a nice
thing to do if one is developing operating systems and maybe if
one is developing servers. But any form of "the application has
a choice of multiple addresses or interfaces and must choose"
puts the application into the routing business. It must have
all of the information that a router would normally have, and
maybe more, in order to make those interface decisions. Even
then, its doing so is a serious layer violation in people and
skill-layering, not just network layering (that translates into
English as "if you expect the typical application-writer to be
able to understand topology and metric information and translate
that understanding into the application code, you are going to
be sadly disappointed".
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. With most SMTP senders, such things can be
configured, but the IETF has published approximately zero advice
as to how to configure them (there actually is some reasonable
advice in RFC 3974, but that isn't an IETF document and it bears
one of the stronger forms of a "you really shouldn't pay any
attention to this" disclaimer from the IESG.
> 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.
> The fact that an IPv6 host can't talk to an IPv4 host is
> unavoidable because the fact that IPv4 hosts can't talk to
> systems with addresses longer than 32 bits is exactly the
> reason why IPv6 was created. Hopefully we can take the edge
> off of that with a better version of NAT-PT. In the mean time,
> you'll want to run dual stack, not IPv6-only.
Even with a better version of NAT-PT (or some other variety of
magic), suppose I have an enterprise that is running IPv6
(rather than lots of NAT and private address space). That is
something we want to encourage, right? Intra-enterprise
communications, including communications with the enterprise
SMTP and Mail Submission servers, are going to occur over IPv6.
Unless we force the enterprise into running split-horizon or
other tricks with a fake local DNS root, DNS queries are going
out, onto the network, over IPv6 because that is how the DNS
works. If the IPv6 hosts within the enterprise are going to
send mail to IPv4 hosts, either the Submission server that
accesses the "outside" systems needs to be dual-stack (and
probably carefully configured) or, as Bill suggests, one needs
an ALG somewhere in the network. Similar comments would apply
to web proxies and middleboxes for other applications. But
there is no requirement that all of the hosts within the
enterprise LAN be dual-stack or even that they ever see an IPv4
packet. At least I hope not because
(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.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf