On Fri, 17 Aug 2012, Michael Thomas wrote:
On 08/17/2012 05:02 PM, Paul Smith wrote:
On 17/08/2012 22:08, Daniel Feenberg wrote:
On Fri, 17 Aug 2012, Michael Thomas wrote:
On 08/17/2012 01:51 PM, Daniel Feenberg wrote:
Host operating systems -- all of them to my knowledge -- prefer v6 over
v4 if you have a public v6 address. So the mere existence of a AAAA
associated with the MX will cause the sender to pick the v6 destination.
I have a v6 mail system and got bitten because I had forgot to put up the
v6 reverse map. It will happen just as a natural consequence of people
enabling v6 on their infrastructure.
This sounds inconvenient. If I want to accept mail from one IPv6 host,
then all the IPv6 hosts will want to use IPv6, and unless I accept mail
from unknown IPv6 hosts, mail from hosts that would have been accepted
over IPv4 will be rejected?
This is a fair point. Given that IPv6 is rare at the moment and is really
an 'extension' to SMTP anyway, maybe we should be looking at a further
extension which allows an SMTP receiver to say 'retry on my IPv4 address'
Seriously, let's not go here. Any such extension would be DOA in the IETF
anyway.
If DNSBL's are the reason you would want to stay in v4 land, I'd suggest
the problem is with the way DNSBL's are engineered, not v6. Thislist being
How would you engineer a DNSBL for IPv6?
an IETF research group should just accept that v6 will arrive and not try
to roll back time.
The question isn't so much when IPv6 will arrive, there are lots of uses
for IPv6, but when IPv4 will depart. And I don't see any incentive for
our correspondents to establish IPv6 mtas when IPv4 mtas have much
greater acceptability to receivers. That is independent of the DNSBL
situation but the lack of an effective DNSBL further encourages mtas
not to accept IPv6 messages, a factor which strongly militates against
a gradual transition.
You could argue that new institutions will not be able to obtain IPv4
addresses, and therefore will be forced to adopt IPv6 for their mta. I
expect any significant email source will find an IPv4 address for their
mta, even if the rest of their servers are IPv6 only. The transition for
other services is much easier, since in other cases offering a dual
stack has no downside. It is only in the case of the mta that a dual
stack results in a significant lose of service. Therefore, no transition
without a flag day, and flag days are very difficult to arrange.
Another possibility is that an IPv6 DNSBL could be established, but
listing very broad address ranges, such as /32s. I don't know how
that would work out, but I would expect a lot of colateral damage from
such a broad listing.
daniel feenberg
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg