"Robert A. Rosenberg" <hal9001(_at_)panix(_dot_)com> writes:
Russ Allbery wrote about Re: current usage of AAAA implicit MX?:
It's not that it's technically difficult so much as that it's dubious
from a layering perspective, at least from where I sit. It requires I
introduce IPv6-specific code (and hence ifdefs for systems without IPv6
constants and so forth) into an application that otherwise would not
need any and would be entirely stack-agnostic.
OOPS. I was not considering the case where the code was being tailored
at assembly time. Looking at my flow I see only 1 (2 if you want to
ALWAYS set the flag in step 2) place where conditional code needs to be
inserted. This is in step 3 where the Test Flag and IPN code would only
get inserted IF IPv6 support is being generated.
I think you're missing the point. In order to implement your proposal, I
have to insert IPv6 knowledge into code that otherwise does not need any
to work on both IPv4 and IPv6 systems. If I don't have to care about IPv6
when it comes to processing the presence or absence of MX records, SMTP
clients honoring MX records can be written to be agnostic about the
networking stack that they're using. Indeed, they can be written and
tested by people with only IPv4 access and work on IPv6 without
modification, since all the portabliity work is done by the system
library.
This is exactly the sort of abstraction and generalization accomplished
via a good layering design, and layering violations are bad precisely
because they don't allow this sort of clean separation of duties. A lot
of work went into designing IPv6-friendly APIs so that clients using the
modern networking API and some additional bits of glue such as
sockaddr_storage can use the same code with both IPv4 and IPv6 without
ugly #ifdef hacks or following different code paths based on the protocol.
Let's not undo that.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>