> On 6 jan 2008, at 11:21, John C Klensin wrote:
>
> >> The basic theory is supposed to be that faced with
> >> a mixture of A and AAAA responses, the host will
> >> by default prefer IPv6 and by default use RFC 3484
> >> to choose among multiple IPv6 addresses. As far as
> >> I know, that's running code for many SMTP servers.
>
> > But, in general, SMTP servers don't choose addresses. SMTP
> > clients do. The number of them that are 3484-compliant is not,
> > in my experience, large
>
> Not sure what you mean here by "SMTP clients"... Would that be client
> computers such as the one I'm typing this message on? But those don't
> look at MX records, unless I'm very much mistaken.
>
> However, it's not the applications that have to be aware of RFC 3484,
> but the OS. The only thing the application needs to do is use a
> network API that supports IPv6 and the OS will take care of selecting
> a list of appropriate addresses and try to order them in descending
> order of preference. (For instance, Apple's Mail can work over IPv6
> but it only tries the first address so if there is non-working IPv6 I
> can't get at my mail.)
Apple's Mail is not RFC 1123 compliant then. I seriously
doubt that Apple can produce the design documentation that
proves that they even thought about this. If they can I'd
like to see the justification. It would be a interesting
read.
* "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing
a different course.
2. GENERAL ISSUES
[snip]
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
success is obtained. More specific requirements for SMTP are
given in Section 5.3.4.
> > As far as the default IPv6 preference is concerned,
> > trying something, waiting for it to get a "not reachable" or,
> > much worse, time out, and then trying something else takes
> > sufficiently long that, until IPv6 reaches some critical mass,
> > configuring a 3484 sequence to prefer IPv6 in a production
> > environment just doesn't make a lot of sense right now.
>
> No, the part that doesn't make sense is enabling IPv6 but then
> preferring IPv4. That way, you don't get to find out what works and
> what doesn't work.
And the longer people leave it the more likely it is that
the service will be swamped as more and more clients have
IPv6 transports.
> It is true that enabling (and thus preferring) IPv6
> can have downsides. In my case it means the IETF website is
> excruciatingly slow because there doesn't seem to be any routing from
> the IETF to my ISP's IPv6 addresses. This is something that doesn't
> generate ICMP errors for me so I have to suffer TCP timeouts and
> fallback to IPv4. But fortunately, this type of issue is rare these
> days. However, operators aren't yet as responsive to these issues as
> they are to IPv4 reachability problems.
>
> >> It's also obviously that case that if an FQDN has both
> >> A and AAAA records, all applications servers reached
> >> at those addresses must support IPv4 and IPv6
> >> respectively. No exceptions.
No. There is no such requirement. Just make sure the
server sends ICMP or RST. The client should move on
to the next address after one RTT.
UDP based applications may be more problematic but not
always.
> > It may obviously be the case, but the implication of this is
> > that I dare not put an AAAA record up for a host that serves out
> > several protocols until all of those protocols are IPv6-ready.
>
> That's just silly. You can create different names where one has only
> IPv4 and one also has IPv6.
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf