Russ Allbery wrote:
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, you seem to have a good handle of IPv6 with practical experience
and using the various RFCs specifically 3484.
I'm catching up now with the various RFCd and I would like get a
confirmation of what I am seeing as far the the intention and/or
methodology.
It appears to me that Microsoft wishes virtualize IPv6 (and IPv4) from
an application viewpoint. i.e, separate the communication layer.
When its all said and done, an SMTP client would never need to know
about MX, A or AAAA records or any other record current or future for
that matter.
If you want to send mail or even just check for SMTP hosting, all you
need is two variables possible three, and the getaddrinfo() function call.
- host name
- service port
- flags for IPv4 only, IPv6 or both (passive mode).
If done correctly, ideally the SMTP client will never need to worry
explicit MX or implicit MX records.
Am I on track?
If so, my next question has to do with what are the requirements to make
it work.
More specifically, right now our smtp code is using level 1 socket
commands. We have our own DNS resolver.
Would a first step be to port over to level 2, and removing or rather
replace our GetDNSRecord() function with getaddrinfo() but use a IPv4
only flag?
The goal would be to get the code switch over but still make it work for
customers under IPv4 with no lost or extra IPv6 stack requirements.
Or should I go ahead and make it passive, and we will still not have
problems if the customer has an OS with no IPv6 stacks installed?
From some of my readings, this could be problematic when there is no
IPv6 stacks.
Thanks
PS: if you prefer to go offlist, I wouldn't mind that. :-)
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com