On 3/25/2014 10:31 PM, Cutler James R wrote:
Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP!
Please explain my misunderstanding on the following:
1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like).
2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations]
3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one’s own combat boots. And not particularly productive.
I look forward to furthering my education.
[applause] -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
On Tue, Mar 25, 2014 at 11:07 PM, Larry Sheldon <LarrySheldon@cox.net>wrote:
On 3/25/2014 10:31 PM, Cutler James R wrote:
2. SMTP is an Application Layer Protocol, supposedly independent of
Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge
[snip]
(1) Architectural layers are a protocol design construction, only, which assist with standardization. They are not a separation of responsibilities. A SMTP server has to take care to have an implementation of all layers. Further: A well designed SMTP server has to be built with some understanding of all layers involved, they are used to construct Received: headers, and a SMTP server cannot treat the application layer in isolation. It is a complete and utter fiction, to suppose that the layers can be treated in total isolation. (2) The IP protocol layer is not actually independent. Moving to IPv6 does in fact have effective new requirements for SMTP servers. (3) Abuse transcends all layers, and so does the administration of any service provided by an application. (4) When a major change will [by necessity] be made to any layer underlying the MTA application on the protocol stack, now is also a good time to look at the overall service as a whole. -- -JH
On 3/25/2014 10:41 PM, Jimmy Hess wrote:
(1) Architectural layers are a protocol design construction, only, which assist with standardization. They are not a separation of responsibilities.
Actually, they are specifically a separation of responsibilities. That the separation doesn't work adequately and all the time means that pragmatics requires wandering across layer boundaries. But pragmatics also dictate being extremely careful when choosing to do that.
A SMTP server has to take care to have an implementation of all layers.
There are two possible meanings to that sentence. The first prompts a 'duh' reaction, since SMTP (usually) runs over TCP/IP. So the server won't be very useful unless it 'has' an implementation of all layers. The other interpretation is that an SMTP package needs to have its own version of TCP and IP. This, of course, is silliness. SMTP packages do not typically implement TCP or IP. They might pay quite a lot of attention to those lower layers, but they don't implement them.
(2) The IP protocol layer is not actually independent. Moving to IPv6 does in fact have effective new requirements for SMTP servers.
Mostly, no. Not completely no, of course, but mostly. Language like #2 is leading quite a few folk to try to treat email over IPv6 as if it will be a separate service from the one currently running over v4. It won't be a separate service. Or, at least, it has better not be. The success of email has been through seamless, end-to-end integration, not through disparate silos with different service models. By way of example, please highlight which email packages require or even allow an author to dictate which version of IP to send over. For anything that someone thinks should be done for v6, pursue it instead as a change for the entire global service. It's fine for v6-related issues to /motivate/ global changes, but don't isolate the work to v6 platforms.
(4) When a major change will [by necessity] be made to any layer underlying the MTA application on the protocol stack, now is also a good time to look at the overall service as a whole.
Sure, but not 'also'. Rather 'only', except for relatively trivial layer convergence gluing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
participants (3)
-
Dave Crocker -
Jimmy Hess -
Larry Sheldon