IPv6 isn't SMTP

Thu Mar 27 00:07:09 UTC 2014

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