Subject: [v4v6interim] Potential interoperability issue

From: Fred Baker <[email-masked]>
Date: Thu, 2 Oct 2008 13:31:19 -0400

Sitting in your discussion of applications that may have issues  
through a translator. In the chat room, I asked:

> Dumb question from personal ignorance. SMTP opens with a HELO or  
> EHLO that has the IP address of the MTA in it. Does SMTP treat that  
> as a character string, or does it interpret the address? If it  
> interprets the address, it may have the same issue as FTP in a 6to4  
> environment

and James Woodyatt replied

> Some things interpret it as an address, e.g. rule processing engines  
> for deciding whether to require TLS.
> Or authentication.

That either calls for an ALG or appropriate code in the servers that  
can deal with an <> address even when the server doesn't have such an  
address. The simplest resolution might be to have the MTA have a leg  
in the IPv6 world and one in the IPv4 world. 
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: james woodyatt <[email-masked]>
Date: Thu, 2 Oct 2008 10:51:43 -0700

On Oct 2, 2008, at 10:31, Fred Baker wrote:
>> Some things interpret it as an address, e.g. rule processing  
>> engines for deciding whether to require TLS. Or authentication.

The EHLO message has a domain name.  In SMTP, the Domain grammar  
production includes a special case allowing for an IP address literal  
instead of a FQDN.  This domain name in the EHLO message is sometimes  
used to make decisions about TLS and AUTH requirements.  So, too, can  
the IP address of the connecting client be used for such decisions.

Whether an ALG is required to cope with this is a question I'm not  
prepared to answer.

> can deal with an <> address even when the server doesn't have such  
> an address. The simplest resolution might be to have the MTA have a  
> leg in the IPv6 world and one in the IPv4 world.

I would agree that this is the simplest way to handle SMTP servers.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2008 14:39:13 +1300

On 2008-10-03 06:51, james woodyatt wrote:
>>> Dumb question from personal ignorance. SMTP opens with a HELO or EHLO
>>> that has the IP address of the MTA in it. Does SMTP treat that as a
>>> character string, or does it interpret the address? If it interprets
>>> the address, it may have the same issue as FTP in a 6to4 environment
>>
>>> for deciding whether to require TLS. Or authentication.
> 

Yes. Incidentally, SMTP is listed in RFC 3027 among the "Protocols that
can work with the aid of an ALG", but the discussion seems rather
brief to me.

    Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 3 Oct 2008 16:46:00 +0200

> I would agree that this is the simplest way to handle SMTP servers.

Agreed as well. A proxy approach is always better (predictable, traceable) but then you need to proxy/intercept the DNS request for the MX record and change it on the fly.

Moreover, AFAIK, the optional IP address in the HELO message is just 'for information' only. It is mainly used in the Received: headers which are used for debugging (and can easily be forged as they are not part of the DKIM signatire).

-éric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 4 Oct 2008 00:17:38 +0200

On 2 okt 2008, at 19:31, Fred Baker wrote:

>> EHLO that has the IP address of the MTA in it.

[...]

> leg in the IPv6 world and one in the IPv4 world.

Right. I don't think we should create trouble where none exists in  
practice. Running an SMTP server behind a translator is not a good  
idea; using a dual stack SMTP server as a forwarder makes much more  
sense.

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Oct 2008 13:37:22 -0700

On Oct 3, 2008, at 3:17 PM, Iljitsch van Beijnum wrote:

> using a dual stack SMTP server as a forwarder makes much more sense.

Gee, you make it sound as if I were arguing against dual stack. I'm  
merely noting that dual stack isn't being deployed at the rate one  
would hope for and that my customers are looking for a translation  
solution.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 6 Oct 2008 10:36:00 +0200

> would hope for and that my customers are looking for a translation  

The thing that we have to make explicit is that it's necessary to  
deploy the right solution to a given problem, one size never fits all.

Dual stack is not a good solution for clients for two reasons: it  
requires running both IP versions throughout a network, which  
increases cost and complexity, and it uses up just as many addresses  
as just running IPv4.

But for servers, dual stack is the best possible solution, because  
it's way simpler than the alternatives as receiving incoming sessions  
through translation is a big hurdle and the address use and network  
complexity aren't as bad because the number of servers and presumably,  
the number of places they're present are limited.

In the case of SMTP it's also easy to simply put a dual stack server  
in the path if you have an IPv6 server.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Ed Koehler Jr" <[email-masked]>
Date: Mon, 6 Oct 2008 06:56:10 -0400

IMHO, any server based application should first be approached by dual
stack in the server if at all possible. Only then should one look to
alternatives. I have been running this way in my lab for a number of
years, there are very few server based scenarios where this does not
work. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Iljitsch van Beijnum
Sent: Monday, October 06, 2008 4:36 AM
To: Fred Baker
Cc: [email-masked]
Subject: Re: [v4v6interim] Potential interoperability issue

> would hope for and that my customers are looking for a translation 

The thing that we have to make explicit is that it's necessary to deploy
the right solution to a given problem, one size never fits all.

Dual stack is not a good solution for clients for two reasons: it
requires running both IP versions throughout a network, which increases
cost and complexity, and it uses up just as many addresses as just
running IPv4.

But for servers, dual stack is the best possible solution, because it's
way simpler than the alternatives as receiving incoming sessions through
translation is a big hurdle and the address use and network complexity
aren't as bad because the number of servers and presumably, the number
of places they're present are limited.

In the case of SMTP it's also easy to simply put a dual stack server in
the path if you have an IPv6 server.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim