[Top] [All Lists]

Re: current usage of AAAA implicit MX?

2008-04-05 18:11:00

Russ Allbery wrote:
Hector Santos <hsantos(_at_)santronics(_dot_)com> writes:

IPv4 and IPv6 are very different and software NEEDS to change in order
to even BEGIN to thinking about supporting it.

I have to pick this nit.  The difficulty of supporting IPv6 in userspace
programs tends to be exaggerated.  At least on UNIX varients, programs
that use the new getaddrinfo and getnameinfo interfaces can frequently be
written to be entirely agnostic about which IP stacks they're using.

Hi Russ,

You raised a good point. For simple query applications, sure, level 2 socket commands can help in the migration. Changes are minimal, if any.

However, and I'm sure you know all this, so I just speaking in general, this is just one small part of the possibly necessary total change requirements.

1) Existing simple query programs may need to be updated to define which class results the want to get. For example, getaddrinfo() needs to be passed the AI_PASSIVE flag if you want to see either IPv4 or IPv6 addresses. (note, I'm not a unix wienie any more so I can't tell you if this a portable behavior on Unix).

2) For some OSes, I recall seeing in Windows 2008 beta (which is basically VISTA without the Vista graphics) a OS global ON and OFF command switch to enable or disable IPv6 results. This is because before existing applicatons may not be expecting IPv6 requests or operations.

3) This also assumes applications are using the socket level 2 getxxxxx()functions as oppose to using an in-house direct DNS client API library and/or the OS DNS API/library for queries. These API may not have been designed for IPv6 readiness or queries for desired IPv6 results.

But yes, developer to developer, I agree the design changes requirement complexity is over exaggerated. But for most, IMO, the design change requirements is part of a larger picture than just simple queries.

I've written code that works fine with IPv6 without even testing on an
IPv6-enabled system.  The code from my perspective as a programmer is
identical either way.

Ok, then you coded and designed it to operate in a passive mode where getaddrinfo() return either the IP address portion of the socket address structure prepared for IPv4 or IPv6 operations.

If you have not done that and/or a developer was specifically aware of this and only asked for IPv4 results, is not ready for IPv6.

In fact, from that perspective, it would be a bit annoying to write a
fallback to A without also writing a fallback to AAAA for hosts without an
MX record.  The obvious (at least with thirty seconds of thought, and I
may be missing gotchas) way of implementing resolution of a mail server is
to do an MX record lookup and, if that fails, call getaddrinfo on the RHS
and connect to the resulting addresses until one of them works.  This
would treat AAAA identically to A.

If you have a moment, please see my "How doe SMTP IPv4 and IPv6 work together" message post to the list earlier today.

The goal here is to highlight what I think is the obvious for maximize compatibility or minimum depending on your perspective.

2821bis should not, or rather I don't think it needs to add text that can change or implied a need for change for the existing IPv4 only expected behavior.

Consider a world where there is only IPv6 and everyone is talking IPv6 only. I believe we will have the same issues with missing MX record and a implicit MX AAAA lookup behavior for the domain.

The only way that AAAA fallback can be eliminated, is if we use the opportunity for an IPv6 only system to mandate proper MX record.

But I don't think we can mandate an MX for a pure IPv4 system simply because it was never required before in the IPv4 only whelm.

I just don't think we are ready to make any mandated MX claim yet for this 2821bis for either IPv4/6 protocal. We need more vetting about this.

I think the best what we can do for 2821bis at this point is to make sure there is text requiring what IPv6 systems to need to do if they wish to contact a IPv4 only domain and expects responses from this IPv4 system. The only way this is possibke if when the IPv6 offers dual stacks allowed the IPv4 only system to use the MX/A records or implicit MX domain A record.


Hector Santos, CTO