Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 13:42:56 -0400

On Jul 22, 2011, at 12:37 PM, Joe St Sauver wrote:

> I think it's great for providers to add support for IPv6 for:
> 
> -- web email
> -- Authenticated secure IMAP
> -- Authenticated secure POP
> -- Authenticated secure message submission
> 
> In all of those cases, because users *are* authenticating, you know who 
> your users are, regardless of how or from where they connect. If they
> begin to spew, you'll know who it is and you can deal with them/their 
> compromised machine.
> 
> At this point, though, I'd be wary of fielding Internet-accessible 
> IPv6-enabled SMTP servers.
> 
> Why? Spam management solutions simply aren't yet where they need to be...

One of the things that I've been wondering is whether IPv6 provides a good excuse/lever to have all email that crosses administrative domain boundaries over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP servers using client certificates.   Ideally it would use DNSSEC to authenticate the client certs instead of relying on trusted CAs.  But I think all of the protocol work should be defined, it just needs to be profiled.   This seems like it might be  an opportunity to raise the level of email security in general and also raise the bar for spammers.

Keith

---

From: "Joe St Sauver" <[email-masked]>
Date: Fri, 22 Jul 2011 09:37:26 -0700 (PDT)

Gert commented:

#On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote:
#> My initial comment to Michael, when he pointed the draft out to me, was
#> that email seems like the poster child of an easy application to add IPv6
#> to, as the applications (SMTP, POP, and IMAP) mostly support it already
#> and the current OS's support IPv6.
#
#Seconded.  Plus, if mail gets delayed by a few minutes due to IPv6 breakage,
#it helps *noticing* problems without impacting user experience in a very
#massive way (like for IPv6 HTTP running into timeouts).

Let me just jump in for a second on this.

-- web email

Yeah, if you're lucky, maybe you won't see any spam via IPv6 connections,
or maybe you can clean it up with a purely content-oriented anti-spam 
solution (such as SpamAssassin or a Baeysian approach), but if you want 
to use traditional blocklists or you want to use some of the major 
commercial anti-spam appliances, what you'd want is simply not available.

Regards,

Joe

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 22 Jul 2011 11:24:54 -0700

> Why? Spam management solutions simply aren't yet where they need to be...

Well, there's the other observation to make. which is you and I have been running ipv6 enabled mailservers since sometime in 2001 and yes we receive spam from over ipv6 but the world pretty much hasn't ended either. now in neither case we we dependent on some rock in a box spam appliance that we forgot to renew the annual maintenance on, but at the same time we're not running that much that isn't off the shelf software.

> Regards,
> 
> Joe
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Jul 2011 19:28:17 +0100

On 22/07/2011 18:42, Keith Moore wrote:
> One of the things that I've been wondering is whether IPv6 provides a
> good excuse/lever to have all email that crosses administrative domain
> boundaries over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP
> servers using client certificates.   Ideally it would use DNSSEC to
> authenticate the client certs instead of relying on trusted CAs.

Keith,

Summarising this and previous emails, you're suggesting that:

1. the authors should add a quickie paragraph to mandate that all
interdomain ipv6 SMTP be authenticated via PKI,

2. provider MTA/MSA services are being held up by lack of automatic tunnelling,

2.1 ... implying that it's even remotely appropriate to host production
services on service provider networks using ipv6 transition mechanisms,

3. this document "threatens to marginalize small players",

4. the time-frames mentioned in this document are "completely disconnected
from reality",

5. that this document can or should attempt to deal with the tiny
proportion of users on the internet who host mail servers on the last mile, and

6. "There's really little point to upgrading mail to use IPv6 until most of
the net has IPv6 access".

Speaking as an operator, I do not see any credible basis for any of these
positions.

Nick

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 15:47:27 -0400

> interdomain ipv6 SMTP be authenticated via PKI,

I don't think it's a "quickie paragraph", but I do think it's the same general topic and might should be part of the discussion.  I don't think this is something that should be decided quickly, and certainly not entirely in v6ops.

> 2. provider MTA/MSA services are being held up by lack of automatic tunnelling,

Not "provider" services.   But if you want to write a document that specifies how to do email over IPv6, it's important to not marginalize those who don't have IPv6 yet.

> services on service provider networks using ipv6 transition mechanisms,

No, I implied the opposite... at least when using current transition mechanisms.

> 3. this document "threatens to marginalize small players",

The idea, expressed here, that email services shouldn't be run in enterprise networks on the edge, does threaten to marginalize small players, where "players" include enterprises running their own mail. 

> 4. the time-frames mentioned in this document are "completely disconnected

..unless you somehow limit who is expected to follow those guidelines to "major players"

> proportion of users on the internet who host mail servers on the last mile, and

...or maybe, the document just needs to be clearer about its scope.

> the net has IPv6 access".

There's a point if you want to gain experience with SMTP over IPv6 and spam countermeasures in that world.  But there's no functionality to be gained by doing so.   The basis for interoperability of email is going to continue to be IPv4 for a long time, *unless* large operators somehow manage to marginalize small ones.  And that's not desirable from my POV, nor appropriate for IETF to encourage.

> Speaking as an operator, I do not see any credible basis for any of these

That's probably because you're an operator, and therefore have a different view of the world.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jul 2011 20:10:04 +0000

> Well, there's the other observation to make. which is you and I have been running ipv6 enabled mailservers since sometime in 2001 and yes we receive spam from over ipv6 but the world pretty much ha…

I have a v6-only SMTP server for a domain that I don't need to depend on, and it has not received a single item of spam since I set it up.   Of course, if all the mail servers out there worked with IPv6, that would change.

I think that it might be worth differentiating between listening on IPv6 and sending on IPv6.   Listening on IPv6 requires that you have an answer for spam.   Sending on IPv6 does not.   Sending on IPv6 would make it possible to deliver to sites that can originate IPv4 SMTP connections over a NAT link, don't have a globally-routable IPv4 address, but do have a globally-routeable IPv6 address.   Consequently, I'd really like to see people enable transmission of mail over IPv6, even if they don't enable reception.

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 23:15:01 +0200

Hi,

> Why? Spam management solutions simply aren't yet where they need to be...

... in which case, gratuitous amounts of pressure needs to be applied
to anti-spam vendors that are not there yet.

We use an anti-spam appliance from one of the big vendors that make
videos how important IPv6 is, but that still doesn't have IPv6 yet - so
we had to setup a parallel IPv6-only MX that will wash the e-mail in
a different way.  Ugly as hell, but all this stalling "we can't do IPv6
because *this* is missing and *they* are not there either" is really
something that needs to go away.  Quickly.

> commercial anti-spam appliances, what you'd want is simply not available.

I won't go into the details of the various anti-spam options - but there's
enough that operate on the sender's IPv* address and handle v6 fine.

Others, like SpamAssassin, use the IP address only for scoring among
other algorithms, and also handle IPv6 just fine.

BTDT, since way too many years to not get impatient over time.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Jul 2011 22:26:42 +0100

On 22/07/2011 20:47, Keith Moore wrote:
> [lots of stuff]

I was going to reply to this email point by point, but decided against as
there appears to be little or no common ground between us.  Continuing the
conversation would just end up in a shouting match, with little chance of
meaningful discussion.  And it would do nothing but distract attention from
the substantial issues in the draft.

Nick

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:04:03 +0200

> Well, there's the other observation to make. which is you and I have 
> been running ipv6 enabled mailservers since sometime in 2001 and yes we 
> receive spam from over ipv6 but the world pretty much hasn't ended either.

I've been running an IPv6 listener for a while, and the only spam I see is 
stuff from compromised web servers and stuff that leaks through 6to4.

Botnets do not send spam to IPv6 yet.  When they do, expect a lot of v6 
mail servers to fall over, since for a variety of reasons I can explain if 
you're not familiar with them, IPv4 filtering techniques don't work in 
IPv6. In v4, DNSBLs catch 80-90% of bot spam, and it will be really bad 
if v6 servers have to handle 5x to 10x the load of spam to body filter.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:15:28 +0200

> to anti-spam vendors that are not there yet.

That is a phenomenally naive and unhelpful suggestion.

The vast size of the IPv6 address space means that a lot of stuff that 
worked in IPv4 simply doesn't work in IPv6.  Most notably, we have to 
assume that bad guys (or even misguided good guys) will use a different IP 
address for every single messge.  This means that any per-message DNS 
lookup, even an rDNS lookup, can make your DNS cache explode.

The abuse management community has been thinking about this for quite a 
while.  If you think there are easy solutions, that means you don't 
understand the problem.

Regards,

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 19:19:20 -0400

> the substantial issues in the draft.

I certainly agree that there's a large disconnect, and there's no point in repeatedly talking past each other.   

I don't know how to get people to see things from a perspective other than their own, when they're apparently hostile to such input.

Keith

---

From: Sander Steffann <[email-masked]>
Date: Sat, 23 Jul 2011 01:16:43 +0200

Hi Ted,

> I think that it might be worth differentiating between listening on IPv6 and sending on IPv6.   Listening on IPv6 requires that you have an answer for spam.   Sending on IPv6 does not.   Sending on…

+1

I think this is very good advise.
Sander

---

From: Sander Steffann <[email-masked]>
Date: Sat, 23 Jul 2011 01:22:27 +0200

Hi,

> The vast size of the IPv6 address space means that a lot of stuff that worked in IPv4 simply doesn't work in IPv6.  Most notably, we have to assume that bad guys (or even misguided good guys) will use a different IP address for every single messge.  This means that any per-message DNS lookup, even an rDNS lookup, can make your DNS cache explode.
> 
> The abuse management community has been thinking about this for quite a while.  If you think there are easy solutions, that means you don't understand the problem.

The solutions don't have to be easy. Gert made a comment about anti-spam *vendors*. They make money by providing anti-spam solutions. It's their job to work on this. That is what we pay them for... They need to understand that products without IPv6 support will not sell very well.

If it was easy I would do it myself ;)
- Sander

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Jul 2011 10:51:03 +0200

Hi,

On Sat, Jul 23, 2011 at 12:15:28AM +0200, John R. Levine wrote:
> you don't understand the problem.

You've made that abundantly clear, and thanks for that enlightenment.

Indeed I've never run one of the 100 biggest mail servers in the world,
and there are people much better qualified than I that are doing that.

And those tell me "it can be done" - strato.de and t-online.de are two
of the top 10 mail providers in germany, and both feel confident that
their anti-spam solutions can handle spammers using IPv6.

So why should I believe otherwise?

Regarding DNSBLs and "spammers will use a different source address 
per connection and kill your DNS cache" - well, indeed, it will not
work by applying IPv4 techniques 1:1 and not adjusting the mechanics
for IPv6.  So new concepts need to be thought out and tested - and if
it turns out that they don't work, then turn off IPv6 on the MX for 
a month and come up with new ideas in the mean time.  (Which is mostly
what the draft is saying - "trial now, be ready next year")

*Not* deploying IPv6 "just because it might not work" is not going to
help solving the problem either.

Feel free to tell me a few more times that I don't understand your 
problem.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Jul 2011 10:51:50 +0200

>while.  If you think there are easy solutions, that means you don't 

Of course there are easy solutions. Thinking for just 5 minutes about this
problem gives you a couple of easy solutions.

But, v6ops is in my opinion not the right place to discuss anti-spam measures.
So, I will leave at at that.

---

From: "t.petch" <[email-masked]>
Date: Sat, 23 Jul 2011 12:29:19 +0200

----- Original Message -----
From: "Sander Steffann" <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>
Sent: Saturday, July 23, 2011 1:22 AM
> > The vast size of the IPv6 address space means that a lot of stuff that
worked in IPv4 simply doesn't work in IPv6.  Most notably, we have to assume
that bad guys (or even misguided good guys) will use a different IP address for
every single messge.  This means that any per-message DNS lookup, even an rDNS
lookup, can make your DNS cache explode.
> > The abuse management community has been thinking about this for quite a
while.  If you think there are easy solutions, that means you don't understand
the problem.
>
> The solutions don't have to be easy. Gert made a comment about anti-spam
*vendors*. They make money by providing anti-spam solutions. It's their job to
work on this. That is what we pay them for... They need to understand that
products without IPv6 support will not sell very well.

I think that you have just argued for the abolition of the IETF and IRTF.
Having vendor-independent standards has, on occasions, helped the development of
the Internet.  On this particular topic, the asrg has been wrestling with this
issue for a long time, and, as John says, there are no easy solutions.

And any figures about current IPv6 usage are irrelevant.  Spammers follow the
traffic and as - if? - and when IPv6 has substantial traffic, then we will see
the 90+% levels of spam that we currently see reported on IPv4

Tom Petch

---

From: Sander Steffann <[email-masked]>
Date: Sat, 23 Jul 2011 14:01:35 +0200

Hi,

> I think that you have just argued for the abolition of the IETF and IRTF.

No I didn't :)

> issue for a long time, and, as John says, there are no easy solutions.

I didn't say that the anti-spam vendors should work outside the IETF. Although I don't see a big problem as long as they speak SMTP on the outside :)

- Sander

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 18:47:11 +0200

> So why should I believe otherwise?

I know other mail systems at least as large who are much less optimistic.

> what the draft is saying - "trial now, be ready next year")

Um, has anyone read draft-levine-iprangepub?  It's a different way to do 
DNSBLs that I've been experimenting with since December.

Regards,

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Jul 2011 20:32:48 +0200

Hi,

> I know other mail systems at least as large who are much less optimistic.

I've observed IPv6 non-deployment for about 14 years now, mostly because
people were "less optimistic".

There's a great saying about those that don't believe something can be
done not standing in the way of those that are busy *doing* it...

> DNSBLs that I've been experimenting with since December.

Thanks for bringing forward new ideas.

So maybe you could explain your point again why people cannot do IPv6
deployment on their MXes, not even for trials?  Indeed I do not understand.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Jul 2011 19:03:15 +0000

On Jul 23, 2011, at 6:29 AM, t.petch wrote:

No.   The IETF is not in the business of tactical responses to abuse.   We are to some degree in the business of strategic responses, in the sense that if we can design our protocols so that they are hard to abuse, then tactical responses will be less necessary.   SMTP is a cat already out of the bag, however.   For the purposes of the current discussion, it is entirely fair to say that anti-spam vendors will deal with the hard aspects of the filtering problem, and for us then to simply talk about the actual problems of deployment.   We can acknowledge that a spam solution is needed, without ratholing endlessly on what that solution might be.

---

From: "George, Wesley" <[email-masked]>
Date: Sun, 24 Jul 2011 00:03:37 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Saturday, July 23, 2011 4:52 AM
To: John R. Levine
Cc: [email-masked]
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

>So, I will leave at at that.

Which is sorta why I suggested in my last message (lost in the noise) that the draft be broken up to deal with the abuse problem as a completely separate issue, because it's clearly clouding the discussion as a single draft.

The argument this thread has come to represent demonstrates admirably that there are plenty of folks who don't see IPv6 email spam/abuse as a big problem and therefore (I think) see value in a draft that covers the other considerations and transition steps to enable IPv6 on a mail server for client to server and server to server communications over IPv6 transport. It also demonstrates that there are folks who believe that there is a looming IPv6 mail abuse/scaling problem that the IETF needs to be considering protocol action to address (and that hopefully some of them will want to help solve it).

The latter likely does not belong in v6ops, other than some sort of a gap analysis, and even that I'm not totally certain belongs here. The former likely does.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: David Farmer <[email-masked]>
Date: Mon, 25 Jul 2011 00:58:13 -0500

> begin to spew, you'll know who it is and you can deal with them/their

Yep these should be fairly easy and safe to do IPv6 for and everyone 
should start working on these.  And these are the services that an IPv6 
only user agent will need.

> commercial anti-spam appliances, what you'd want is simply not available.

I'm defiantly wary of doing IPv6 MTA to MTA email transport, and any one 
who understand anything about the issue should be wary.  However, the 
word wary doesn't and shouldn't mean don't do it at all. Nor, should it 
mean dive in head first.  It should mean find ways to proceed forward 
carefully and cautiously.  I think that is what the draft is all about, 
moving forward with IPv6 email carefully and cautiously.

A little context, I don't actually run email servers, I'm an Internet 
plumber, not an Internet postman.  And, the University is migrating most 
of its email users to Google, but that is a whole other discussion. 
However, since only most and not all email users will be migrated to 
Google, the University will continue to run its own MXes.

As I read the draft, the primary objective is not the transition of 
transport for most email to IPv6.  But, preparing for the day when IPv6 
only MTAs start to become necessary in the Post-Transition Phase it 
describes.  It accomplishes this by calling for current MTAs to 
implement Dual-Stack to ensure reachability to and from these IPv6 only 
MTAs when they become necessary.

While I support this objective and believe it is necessary to enable 
Dual-Stack on all current MTAs. Realistically, it will also be necessary 
for service providers to provide their IPv6 only customers that 
want/need to run their own MTAs access to an authenticated Dual-Stack 
Relay and Dual-Stack MX services in order to reach and be reached by 
lagging IPv4 only MTAs.

But back to the Draft, If the intent is to allow for IPv6 only MTAs and 
not necessarily transition email transport to IPv6 then maybe we should 
be thinking about how to enable IPv6 but still prefer IPv4 for email 
transport.  Therefore, I would like to see the draft discuss the 
interactions of MX priority, AAAA records, Address Selection based on 
RFC3484-bis, and maybe prioritizing IPv4 over IPv6.  Also, probably 
discussing interactions with, and Dual-Stack variations of, techniques 
like Nolisting and Greylisting to push traffic to prefer IPv4 over IPv6, 
basically use IPv6 as a last resort for email transport.

So, I'm thinking of talking to our email guys about going to two tiers 
of MXes that are Dual-Stacked.  With the first tier only having SMTP 
bound to IPv4 and explicitly denying SMTP over IPv6, proving a kind of 
IPv6 Nolisting and pushing email traffic to IPv4 even if the remote 
server is Dual-Stack enabled. Then the second tier doing the opposite, 
SMTP bound to IPv6, denying IPv4, and doing IPv6 Greylisting with other 
purely content-oriented anti-spam solutions (such as SpamAssassin or a 
Baeysian approach).  Also if IPv6 reputation based solutions emerge they 
can be used in the second tier too.

Also, our email guys require reverse DNS for IPv4 email servers, this 
causes a few false positives, but catches a bunch of spam before it 
makes on to DNSBLs.  That solution should adapt well to IPv6 if 
legitimate IPv6 email servers provide reverse DNS for IPv6.  We also 
provide a bounce back allowing a real user to request access with 
individualized white-listing for each users email box.

Additionally, It should be possible to adapt the current IPv4 reputation 
based solutions for some of the IPv6 transition technologies as well. 
With 6to4, Teredo, and ISATAP the IPv4 address that is embedded in the 
IPv6 address can be extracted and used as an IPv4 address to be 
looked-up in DNSBLs.

6to4 is trivial;
2002:[IPv4 Address]::

Teredo is a little trickier;
2001:0:[Teredo Server IPv4 Address]:[16 bit Flag field]:[16bit External 
UDP Port hash]:[Obfuscated External IPv4 Address].

The Teredo Server's IPv4 Address is irrelevant, the Obfuscated External 
IPv4 Address is what you want.  But you will need to reverse the 
obfuscation, which should be easily accomplished by XORing it with 
0xFFFFFFFF.

ISATSAP again is fairly trivial;
[IPv6 /64 Prefix]:200:5EFE:[Public IPv4 address]
[IPv6 /64 Prefix]:0:5EFE:[Private IPv4 address]

The ISATAP IPv6 address is only useful if it contains a Public IPv4 
address, that is probably not going to be that common.  But its probably 
still worth doing if someone gives you a Public IPv4 address.

I don't know how useful this would really be, but it probably wouldn't 
hut anything more than the current IPv4 reputation based solutions do 
already.

Finally, I agree it is time to get moving on IPv6 email, and this 
discussion has gotten me thinking about how to get it rolling in my 
organization and hopefully this draft will do the same for others.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 25 Jul 2011 06:43:53 -0400

On Jul 25, 2011, at 1:58 AM, David Farmer wrote:
> 
> Additionally, It should be possible to adapt the current IPv4 reputation based solutions for some of the IPv6 transition technologies as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded in the IPv6 address can be extracted and used as an IPv4 address to be looked-up in DNSBLs.

I am rather unclear on the advisability and for some reason really wary of using transition technologies in the addressing of servers.

> 2001:0:[Teredo Server IPv4 Address]:[16 bit Flag field]:[16bit External UDP Port hash]:[Obfuscated External IPv4 Address].
> 
> The Teredo Server's IPv4 Address is irrelevant, the Obfuscated External IPv4 Address is what you want.  But you will need to reverse the obfuscation, which should be easily accomplished by XORing it with 0xFFFFFFFF.
> 
> The ISATAP IPv6 address is only useful if it contains a Public IPv4 address, that is probably not going to be that common.  But its probably still worth doing if someone gives you a Public IPv4 address.
> 
> I don't know how useful this would really be, but it probably wouldn't hut anything more than the current IPv4 reputation based solutions do already.
> 
> Finally, I agree it is time to get moving on IPv6 email, and this discussion has gotten me thinking about how to get it rolling in my organization and hopefully this draft will do the same for others.
> 
> --

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jul 2011 15:32:39 +0100

> I am rather unclear on the advisability and for some reason really wary of using transition technologies in the addressing of servers.

I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be used for MXes, or indeed any of our internal enterprise infrastructure.

While you can identify 6to4 and Teredo prefixes, you can't do so with ISATAP, as we noted in 3484-bis.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 Jul 2011 18:35:07 +0200

In your letter dated Mon, 25 Jul 2011 06:43:53 -0400 you wrote:
>> Additionally, It should be possible to adapt the current IPv4 reputation bas
>ed solutions for some of the IPv6 transition technologies as well. With 6to4, 
>Teredo, and ISATAP the IPv4 address that is embedded in the IPv6 address can b
>e extracted and used as an IPv4 address to be looked-up in DNSBLs.
>
>I am rather unclear on the advisability and for some reason really wary of usi
>ng transition technologies in the addressing of servers.
>
>> 6to4 is trivial;
>> 2002:[IPv4 Address]::

>From the context I assumed this would be about blacklists. And in that
case, spammers don't care whether we think it is advisable to use transition
technologies for sending e-mail.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Jul 2011 13:20:57 -0400

> I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be used for MXes, or indeed any of our internal enterprise infrastructure.

For the purposes of this argument, it doesn't really matter whether these addresses are used for inbound mail (MXes); what matters is whether they're used for outbound mail.
 
I'm sure that a few people will want to source or sink mail using 6to4, or Teredo.  But I guess I'd be surprised if it became a common enough practice that it was worth the trouble to try to leverage IPv4 address reputation services to evaluate incoming IPv6 mail from those kinds of addresses.

Keith

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jul 2011 18:46:31 +0100

> I'm sure that a few people will want to source or sink mail using 6to4, or Teredo.  But I guess I'd be surprised if it became a common enough practice that it was worth the trouble to try to levera…

I meant both inbound and outbound.  Enterprises will tend to force SMTP through its own relays regardless.

Tim

---

From: David Farmer <[email-masked]>
Date: Mon, 25 Jul 2011 18:33:45 -0500

On 7/25/11 12:46 CDT, Tim Chown wrote:
>>>>> Additionally, It should be possible to adapt the current IPv4
>>>>> reputation based solutions for some of the IPv6 transition
>>>>> technologies as well. With 6to4, Teredo, and ISATAP the IPv4
>>>>> address that is embedded in the IPv6 address can be extracted and
>>>>> used as an IPv4 address to be looked-up in DNSBLs.
>>>>
>>>> I am rather unclear on the advisability and for some reason really
>>>> wary of using transition technologies in the addressing of servers.
>>>
>>> I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be
>>> used for MXes, or indeed any of our internal enterprise infrastructure.
>>
>> For the purposes of this argument, it doesn't really matter whether
>> these addresses are used for inbound mail (MXes); what matters is
>> whether they're used for outbound mail.
>> I'm sure that a few people will want to source or sink mail using
>> 6to4, or Teredo. But I guess I'd be surprised if it became a common
>> enough practice that it was worth the trouble to try to leverage IPv4
>> address reputation services to evaluate incoming IPv6 mail from those
>> kinds of addresses.
>

I probably agree that it is not advisable to IPv6 transition 
technologies for email delivery, especially  6to4, Teredo, and ISATAP. 
However, the discussion of IPv6 transition technologies being used to 
deliver email is explicitly brought up in the draft, further 6to4, 
Teredo, and ISATAP are not explicitly excluded.  So, If we really think 
it is NOT advisable to use IPv6 transition technologies in general, or 
that some are OK, like managed tunnels and 6rd, while others are not 
like 6to4, Teredo, and ISATAP.  Then the draft should say that and not 
what it currently says;

 From Section 5;
"IPv6-based email services MAY be provided via IPv6 transition 
mechanisms (such as those described in [RFC4213], for example) or via 
native IPv6 network service."

 From Section 6;
"IPv6-based email service SHOULD be via native IPv6 network service but 
MAY be via IPv6 transition mechanisms if necessary"

Additionally, if we really think it is not advisable to use specifically 
6to4 and Teredo, since they use generic IPv6 prefixes.  Then we should 
probably suggest blacklisting email from the 2002::/16 and 2001::/32 
prefixes in the draft as well.  Because, I have the suspicion that they 
are going to be especially problematic if you don't out and out 
blacklist them or at least use DNSBL on the associated IPv4 address as I 
discussed in my previous post.

As was mentioned in another reply;

 > technologies for sending e-mail.

+1 to that.

There was a suggestion to move the abuse issues out of this draft, I'm 
neutral on that one way or the other.  However, even if the more general 
email abuse issues for IPv6 are move to another draft, I think the 
specific issue of IPv6 transition technologies, and possibly 
blacklisting the 6ro4 and Teredo prefixes should probably remain in this 
draft.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Jul 2011 20:25:16 -0400

On Jul 25, 2011, at 7:33 PM, David Farmer wrote:
> 
> I probably agree that it is not advisable to IPv6 transition technologies for email delivery, especially  6to4, Teredo, and ISATAP. However, the discussion of IPv6 transition technologies being used to deliver email is explicitly brought up in the draft, further 6to4, Teredo, and ISATAP are not explicitly excluded.  So, If we really think it is NOT advisable to use IPv6 transition technologies in general, or that some are OK, like managed tunnels and 6rd, while others are not like 6to4, Teredo, and ISATAP.  Then the draft should say that and not what it currently says;
> 
> From Section 5;
> "IPv6-based email services MAY be provided via IPv6 transition mechanisms (such as those described in [RFC4213], for example) or via native IPv6 network service."
> 
> From Section 6;
> "IPv6-based email service SHOULD be via native IPv6 network service but MAY be via IPv6 transition mechanisms if necessary"
> 
> Additionally, if we really think it is not advisable to use specifically 6to4 and Teredo, since they use generic IPv6 prefixes.  Then we should probably suggest blacklisting email from the 2002::/16 and 2001::/32 prefixes in the draft as well.  Because, I have the suspicion that they are going to be especially problematic if you don't out and out blacklist them or at least use DNSBL on the associated IPv4 address as I discussed in my previous post.

I suspect that a wiser course of action is for this document to say as little as possible about transition technologies, because it's hard to tell what course v6 deployment will follow.   It is possible that at some point there will be significant portions of the network that have no effective IPv4 access and therefore must receive mail via IPv6, and that this will occur at a time that significant portions of the network still do not have IPv6 access.   If and when that happens, it might make sense for the IPv4-only portions to use IPv6 transition technologies to send mail to IPv6-only mail exchangers, and perhaps, to use transition technologies to receive mail from IPv6-only senders.

The point is, don't overconstrain the solution space.

Also realize that email is considerably more tolerant of delays and transient connectivity failures than, say, a person sitting at a web browser.  

> There was a suggestion to move the abuse issues out of this draft, I'm neutral on that one way or the other.  However, even if the more general email abuse issues for IPv6 are move to another draft, I think the specific issue of IPv6 transition technologies, and possibly blacklisting the 6ro4 and Teredo prefixes should probably remain in this draft.

Blacklisting 6to4 and Teredo is silly and inappropriate unless you have good reason to believe that they're sources of abusive mail.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 Jul 2011 10:14:45 +0200

In your letter dated Mon, 25 Jul 2011 20:25:16 -0400 you wrote:
>Blacklisting 6to4 and Teredo is silly and inappropriate unless you have =
>good reason to believe that they're sources of abusive mail.

I agree. If it really becomes a problem then somebody may just have to write
a small dnsbl server that extracts the IPv4 address from a 6to4 or Teredo
address and queries one or more IPv4 dnsbls for that address.

Otherwise, focus on getting generic IPv6 spam filtering to work without
making all kinds of exceptions.