How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")
rob at invaluement.com
Sat Oct 3 18:28:13 UTC 2015
On 10/3/2015 10:35 AM, Scott Morizot wrote:
> One of the points in having 64 bits reserved for the host portion of
> the address is that you never need to think or worry about individual
> addresses. IPv6 eliminates the address scarcity issue. There's no
> reason to ever think about how many individual addresses are available
> on any network. The answer is always more than enough. Instead you
> think about networks and network size.
One thing that I thought was going to be a huge help with sending-IP
blacklists in the IPv6 world... was perhaps shifting to tighter
standards and greater reliance for Forward Confirmed rDNS (FCrDNS). For
example, already in the IPv4 world, not having a PTR record means that
lots of your mail won't get delivered. And not having a PTR record puts
a "hair trigger" on your IP as far as getting blacklisted. Furthermore,
having a dynamic-formatted PTR record is also a red flag. In contrast, a
properly formatted PTR record, that ends in your primary domain name,
does two HUGE things: It conveys both IDENTITY and REPUTATION upon that
IP. Then FCrDNS follows that up by proving that the PTR record is authentic.
Sadly, some very legit sources of e-mail that frustrate customers when
blocked.. don't follow these rules... even a few senders with *no* PTR
records. Fortunately, those are rare, and are generally handled with
whitelistings, etc.--once confirmed to be sending important/desired mail.
I was hoping that IPv6 could, if anything, tighten up these standards...
ideally, these standards WOULD/SHOULD tighten up... but it looks like
IPv6 is going to destroy these standards instead.
Why? Because if an anti-spam blacklist is operating according to so many
people's suggestions on this thread... and treating a /48 as if it were
one IP. (or even a /56 or /64)... and should "not worry about individual
addresses"... doesn't it remain true that in the IPv6 world... that PTR
records are assigned on an individual IP basis? Or am I wrong and there
is some kind of more generic PTR record lookup for a whole /64, or /48?
If they are assigned individually, then this this is yet another reason
that spam filtering for IP6 is thrown back into the dark ages (among
others I've mentioned--that have NOT been fully answered).
For example, if a spammer who has acquired a /48 is sending from
literally millions, perhaps billions, of DIFFERENT IPs on that /48, then
(a) the individual PTR records lookups would be prohibitively expensive
(no scaling) and DNS caches of those would fill up RAM and hard drives,
and (b) those actual PTR lookups could map back 1-to-1 to the spammers
distribution list and give the spammer valuable intel about spamtraps,
helping them "listwash", etc. (they would merely need to figure out the
sources of the anti-spam blacklist's PTR lookups... this isn't an issue
in the IPv4 world because they can't map that lookup to an individual
Losing that tool (PTR and FCrDNS) for tracking/identifying senders... is
a HUGE loss for spam filters and for anti-spam blacklists.. not just in
the ability to identify spammers, but also in their ability to minimize
false positives due to being able to more accurately identifying legit
senders. (especially legit sender's newly acquired IP ranges that they
deploy for mail sending)
And on a simpler level, if there are multiple DIFFERENT PTR records for
different IPs on that same /48 or /56 or /64 (different as in, ending
with a different domain)... which one should be used for identifying the
validity of the whole block?
Sure, IP whois info is another helpful source... but I find LOTS of
situations the IP4 world where IP whois doesn't drill down very far, and
MASSIVE numbers of very diverse and separate networks are under one
massive umbrella, where treating them all the same would cause massive
FPs or massive FNs. is IPv6 any (or much!) better? Or can that
too-large-umbrella happen with IPv6, too?
> Also, good luck trying to shove the IPv6 genie back into the bottle. I
> doubt you're going to have much success. I know my large organization
> has seen the percentage of email traffic on our edge MTAs using IPv6
> steadily grow since we dual-stacked them back in 2012. It's been a
> while since I checked with the organization responsible for them, but
> I believe it's somewhere north of 10% of all email traffic now.
You sound like you think I'm looking for a problem. But I'm actually
looking for solutions, and I think you're underestimating the problems.
I wonder if you read my posts. I'm all in favor of rapid adoption of
IPv6 for SMTP-Authenticated traffic from the client to server. And I'm
in favor of all non-mail rapid adoption of IPv6. The ONLY area where I
think IPv6 shouldn't be too fast is MTA-to-MTA communication, and where
we shouldn't eliminate IPv4 too fast for this reason alone.
when you say, "north of 10%"... I wonder, what is that percentage if you
don't include client-to-server SMTP-Authenticated traffic?
Also, since such a low percentage of mail servers currently accept IPv6
traffic, all my worst fears about spam filtering in the IPv6 world are
not going to be on display since the vast majority of spammers don't
send via IPv6. This a ticking time bomb if IPv6 mail server traffic is
pushed too fast. Just because it works now doesn't mean it will be
I DO have some solutions in mind, but at this point in the discussion...
it seems like a waste of time to even mention them when so many don't
take these problems seriously. I think many are underestimating how much
scarcity of IPs is helping ESPs and hosters try hard to keep their IPs
clean. I'm on the front lines in fighting the most sneakiest spam and in
dealing with grayhat ESPs who try to not send spam, but don't try that
hard and WOULD be more worried about making more sales that
month--EXCEPT that but don't want to see their *scarce* IPv4 IPs soiled.
When others who are not on the front lines blow these concerns off, I'm
reminded of the phrase, "let them eat cake".
More information about the NANOG