Subject: (ngtrans) Re: ipv6-smtp-requirement comments?

From: Bob Fink <[email-masked]>
Date: Fri, 09 Nov 2001 08:15:27 -0800

Various SMTP list folk,

Itojun has issued the following in response to various comments on his 
"ipv6-smtp-requirement" I-D that was about to be forwarded to the IESG for 
Informational RFC.

The ngtrans chairs would like to forward this new -04 draft (see url below) 
to the IESG, but wish to have any response to this you may have first.

Please forward comments to the ngtrans list (cc'd above) by next Friday, 
November 16.

Thanks,

Alain Durand / Bob Fink / Tony Hain
ngtrans chairs

======
	Hello, this is about draft-ietf-ngtrans-ipv6-smtp-requirement.

	After getting comments from SMTP community (a couple of SMTP-related
	mailing lists), I have submitted a new revision of
	draft-ietf-ngtrans-ipv6-smtp-requirement (now 04).   It should be in
	the internet-draft repository as soon as editors do their thing.
	Comments and actions taken are summrized below.
	The changes are minor, and I don't think it necessary to go through
	ngtrans last call again.

itojun

- English needs to be improved
	the document went through proofread by a native English speaker
	(JJ Behrens of NTT MCL).
- the SMTP sender algorithm should be clarified a bit
	tweaked it a bit, added reference to relevant IPv4-only RFC
	(RFC2821) to make it clearer
- need to talk about situations where IPv4-only sender tries to deliver
   an email to IPv6-only MX
	added a little bit of text.

===
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group 
of the IETF.

	Title		: IPv6 SMTP operational requirements
	Author(s)	: M. Nakamura, J. Hagino
	Filename	: draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
	Pages		: 8
	Date		: 08-Nov-01
	
This document lists operational requirements for IPv6 SMTP and
IPv6-capable MX DNS records.  As IPv6 SMTP servers are deployed, it has
become apparent that certain configurations are necessary in
IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
operation.  This document clarifies the problems that exist in the
transition period between IPv4 SMTP and IPv6 SMTP.  It also defines
operational requirements for stable IPv4/v6 SMTP operation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt

-end

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 9 Nov 2001 10:50:19 -0600

----- Original Message -----
From: "Bob Fink" <[email-masked]>
> to the IESG, but wish to have any response to this you may have first.

Without a picture or diagram of the "Internet Architecture" being assumed,
it is hard to make comments in a context that may not shift from day to day.

Is it a side-by-side IPv4 and IPv6 cloud configuration ?
Is it an IPv6 cloud overlayed on the IPv4 cloud ?
Is it IPv6 islands all interconnected in a large VPN via the IPv4 transport
?
Is it a reliable-redundant architecture (ala IPv8|IPv16) where the clouds
are distinct ?

The IAB has been unable (or unwilling) to provide a picture of their
Architecture.
Why is that ?
Does the IAB have an Architecture ?

Jim Fleming
http://www.IN-ADDR.info
http://www.unir.com/images/architech.gif
http://www.unir.com/images/headers.gif
http://www.unir.com/images/address.gif

CC:
http://www.iab.org/iab/members.html
Harald Alvestrand -- [email-masked] -- --> -- IETF/IESG Chair
Ran Atkinson -- [email-masked]
Rob Austein -- [email-masked]
 Fred Baker -- [email-masked]
 Brian Carpenter -- [email-masked]
 Steve Bellovin -- [email-masked] -- Liaison to the IESG
 Jon Crowcroft -- [email-masked]
Leslie Daigle -- [email-masked] -- IAB Executive Director
 Steve Deering -- [email-masked]
 Sally Floyd -- [email-masked]
 Geoff Huston -- [email-masked]
 John Klensin -- [email-masked] -- IAB Chair
 Henning Schulzrinne -- [email-masked]
EX OFFICIO AND LIAISON
 Erik Nordmark -- [email-masked] -- Liaison from the IESG
 Erik Huizer -- [email-masked] -- IRTF Chair
 Joyce K. Reynolds -- [email-masked] -- Liaison from the RFC Editor
 Lynn St.Amour -- [email-masked] -- Liason from ISOC

---

From: Keith Moore <[email-masked]>
Date: Fri, 09 Nov 2001 17:01:34 -0500

okay, I have fairly extensive comments about this document.  most of them 
do not address specific text in the document, for reasons which I hope
will become apparent to those who are willing to wade through the text below.

executive summary: it's a very good idea to have a document like this, but
I recommend delaying the publication this document until it undergoes
some restructuring and/or having it co-edited by an email expert.

in the first place, you really need to allow for a mechanism by which
v4-only hosts can communicate with v6-only hosts in the absence of
MX records.  in the second place there are just too many subtleties 
involved in email routing to get this right by simple editing of the
current document.

---------------------------------------------------------------------------

1. in the "summary of IPv4 MX operation",
   both RFC 2822 section 5 and RFC 1035 should be referenced
   and the document should make clear to the reader that these 
   are the standard specifications for MX lookup.

   it is somewhat risky to re-state the algorithm in this document
   at all, because there are some subtleties to it.  and they only
   get worse when you add IPv6 in the mix.

2. because there is a lot of uncertainty about the relationship
   between IPv4 and IPv6, it would probably help if the document 
   were to state a few things up front:

   - IPv4 and IPv6 share a common domain name space.  a service
     or host named by a domain name may be reachable via IPv4,
     IPv6, or both.  subject only to differences in reachability,
     a service that is accessible via both IPv4 and IPv6 and which
     can operate using either, should not be affected by whether 
     it is accessed via IPv4 or IPv6.  since email can operate over 
     both IPv4 and IPv6 this principle holds for email -
     [email-masked] refers to the same recipient and mail box 
     regardless of whether the mail travels via IPv4 or IPv6 or
     a mixture of the two.

   - we explicitly assume that everybody wants to be able to send 
     mail to everybody, regardless of whether they are reachable
     via IPv4 or IPv6 or both.  to the extent that a sender or
     a receiver wishes to impose policy on who can send mail to whom, 
     we assume that IPv4 vs. IPv6 is not a factor in that policy.

   - we specifically want to make sure there are easy ways to
     exchange mail between IPv4-only and IPv6-only hosts.

     however, we should not assume that every mail domain that has IPv4
     access can get IPv6 access (even though with 6to4 this should be easy);
     nor should we assume that every mail domain that has IPv6 access
     can get IPv4 access.    

     it is therefore necessary to specify means by which IPv4-only
     hosts can send mail to domains that lack IPv4 connectivity;
     and by which IPv6-only hosts can send mail to domains that lack
     IPv6 connectivity.   

     it is worth remembering that the MX mechanism was created
     and originally used to handle a very similar case - providing
     a means for hosts without IP access to receive Internet email.
     for this reason, using MX to specify transit between IPv4 and 
     IPv6 turns out to be fairly straightforward.  however there
     are some subtle operational concerns that need to be mentioned. 

   - this specification can only apply to MTAs that implement it;
     it cannot affect pre-existing MTAs.  however it is permitted
     to affect new MTAs, even those that are run on IPv4-only hosts,
     and there are things that even an IPv4- or IPv6-only MTA can
     do to ease delivery to the other kind of host.

     in particular, 

     since IPv6 addresses can be looked up using IPv4 DNS queries, and
     IPv4 addresses can be looked up using IPv6 DNS queries, a new MTA
     can distinguish between "no addresses" and "no addresses
     which are reachable" and treat the two cases differently.
     
     the first is a DNS configuration error, and the second is the
     inability to find a route from source to destination.
     
     the IPv4- or IPv6-only MTA may wish to employ one or more external 
     "last resort" relays which can deliver to the other kind of MTA.

3. So here is (informally) how I would modify the MX routing algorithm:

    definitions:

    "relaying MTA" is the MTA which is attempting to relay a message

    "recipient domain" is the domain named in the recipient address

    "mail exchanger" or "MX" is a host which is listed in DNS as
    a mail exchanger for the recipient domain.  

    "remote MTA" is a message transfer agent running on a mail exchanger.

    "MX domain" is the domain name listed for a mail exchanger.

    "MX address" is any of the IPv4 or IPv6 addresses listed in DNS
     for an MX domain.

    so these are instructions for a relaying MTA:

   + if there are no MXes listed in DNS for the recipient domain  

     - an IPv4-capable relaying MTA SHOULD attempt to relay to each of
       the IPv4 addresses listed for the recipient domain (via A records), 
       until it finds one which will accept the message, or it gets a 
       permanent error from the remote MTA, or it times out.

     - an IPv6-capable relaying MTA SHOULD attempt to relay to each of the
       IPv6 addresses listed for the recipient domain (via AAAA or A6 
       records), until it finds one which will accept the message, or it 
       gets a permanent error from the remote MTA, or it times out.

     - a relaying MTA with both v4 and v6 connectivity SHOULD
       attempt to relay to each (v4 or v6) address listed in DNS for the 
       recipient domain (via A or AAAA or A6 records) until it finds one
       which will accept the message, or it gets a permanent error from
       the remote MTA, or it times out.

     - the order in which connections should be attempted within 
       a list of (v4 or v6) addresses obtained in this manner
       is unspecified, and MAY be a configurable parameter
       of the relaying MTA.

     - if a v4-only relaying MTA finds no v4 addresses, or a v6-only 
       relaying MTA finds no v6 addresses, the relaying MTA MAY relay 
       such traffic to an explicitly-configured "external" MTA which 
       has connectivity to the other kind of IP and which has agreed 
       to forward traffic from the sending host or network to recipients 
       using the other kind of IP.  if no external relay has been configured, 
       the message should be bounced with an "5.4.4" (unable to route) 
       error.  if the external relay were unreachable after several attempts 
       and the relaying MTA gave up, the message should be bounced with a 
       "4.4.1" (no answer from host) or "4.4.2" (bad connection) error,
       as appropriate.

     - if no addresses of any kind were found for the recipient domain, 
       this would be a "5.1.2" (bad destination system address) error.  
       (this is exactly what you should get in an IPv4-only world if you 
       try to send to a recipient at a domain without any MX or A records 
       listed for that domain.)

       note however a subtlety - if any of the A or AAAA or A6 lookups 
       failed for temporary reasons - such as no response from any DNS 
       server - the condition would be treated as a temporary error,
       and the MTA should retry at a later time until it decided to give
       up.  under such conditions the error should be "4.4.3 (directory
       server failure)"

   + if there is at least one MX listed in DNS for the recipient domain,

     - sort the MX list according to increasing preference

     - attempt delivery to each of the MX domains in order of
       increasing preference, until either
       
       - the list of domains is exhausted
       - the message is accepted by the remote MTA 
       - the message is rejected by the remote MTA with a permanent
         failure error.

    - for each domain in the ordered MX list the relaying MTA SHOULD
      attempt to contact an SMTP server at that domain using 
      all IPv4 or IPv6 addresses listed for the remote MTA which are 
      reachable by the relaying MTA.  within a particular domain on the 
      ordered MX list, the order in which the (IPv4 or IPv6) addresses 
      are chosen is unspecified, and MAY be a configurable parameter
      of the relaying MTA.   

      however, precedence SHOULD be followed.  so a relaying MTA which
      has both IPv4 and IPv6 connectivity SHOULD attempt to deliver
      to a MX domain with lower preference before attempting to deliver
      to an MX domain with higher preference, even if the one with higher
      preference has better connectivity or the one with lower preference
      lacks the kind of connectivity preferred by the relaying MTA.

    - if after exhausting the list of MX domains, a relaying MTA 
      with only IPv4 connectivity finds there were only IPv6 MX 
      addresses, or a relaying MTA with only IPv6 connectivity
      finds that there were only IPv4 MX addresses, the relaying MTA
      MAY relay the message to an explicitly-configured, "external" 
      MTA which has connectivity to the other kind of IP and
      which has agreed to relay such traffic for the sending host.
      if no external relay has been configured, the message should be
      bounced with an "5.4.4" (unable to route) error. if the external 
      relay were unreachable after several attempts and the relaying 
      MTA gave up, the message should be bounced with a "4.4.1" (no 
      answer from host) or "4.4.2" (bad connection) error, as appropriate.

    - if no addresses of any kind are available (meaning that 
      lookups on each of the MX domains return no address records
      of any kind), the "5.4.3" (directory server failure) error is 
      the closest defined code for this condition.  (this is a 
      misconfiguration of DNS rather than a malfunction, and 5.4.3
      is really intended for malfunctions.  ideally there would be 
      a separate code to distinguish directory misconfiguration from 
      directory server malfunction)

      "5.1.2" SHOULD NOT be used for this case.  If no MX records
      exist for a recipient domain, and no address records exist for 
      that domain either, then it can be assumed that the domain is not 
      intended for use in email addresses.  However, if one or more MX
      records exist for a recipient domain then it is reasonable to
      assume that the domain is intended to be valid for email addresses, 
      and that there has been a failure of the zone administrator to 
      provide address records for those MX domains.

4. with the above in mind, it is possible to construct operational 
   recommendations for senders and receivers to maximize the potential
   for exchanging mail between IPv4 and IPv6:

- all sites:

  it is RECOMMENDED that all sites employ MTAs which meet these
  recommendations for v4/v6 mail routing, even if the site only
  supports IPv4 or IPv6 connectivity.

  the primary burden on a site that wishes to be receive mail from 
  IPv4 hosts is to provide at least one MX with v4 connectivity and to 
  list those MXes and their IPv4 addresses in DNS.

  similarly, the primary burden on a site that wishes to receive mail
  from IPv6 hosts is to provide at least one MX with v6 connectivity
  and to list those MXes and their IPv6 addresses in DNS.  (note that
  any site with IPv4 connectivity and global IPv4 addresses can 
  establish IPv6 connectivity using 6to4 without needing to establish
  a separate  connection)

  any other means of routing mail between v4 and v6 sites should be
  considered a secondary, rather than a primary, mechanism.

- v6-only sites:

  it is RECOMMENDED that v6-only sites provide at least one MX
  for their recipient domains which is reachable via IPv4.
  this MX MAY be external to the recipient site.

  if it is desired to use this MX only when the sender has no v6 
  connectivity, the MX which accepts v4 traffic can be listed with 
  a higher preference than all other MXes.

  this MX *must* either have some reliable means to relay mail to the 
  primary MX server, or it must otherwise handle incoming mail equivalently 
  to the primary MX server.  the mechanism by which this is accomplished is 
  unspecified.  one mechanism which will work is to provide at least
  one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
  other mechanisms may also be feasible.

  it is RECOMMENDED that v6-only sites find some means of reaching 
  v4-only MTAs, by routing all externally-bound v4-only mail to an 
  external MTA which has agreed to relay such traffic.

  realistically, given the "head start" that IPv4 mail has had over 
  IPv6, it will generally be necessary for IPv6 sites to make arrangements
  for *both* incoming and outgoing IPv4 mail transfer.

- v4-only sites:

  it is RECOMMENDED that v4-only sites provide at least one MX
  for their recipient domains which is reachable via IPv6.
  this MX MAY be external to the recipient site.

  if it is desired to use this MX only when the sender has no v4
  connectivity, the MX which accepts v6 traffic can be listed with 
  a higher preference than all other MXes.

  this MX *must* either have some reliable means to relay mail to the
  primary MX server, or it must otherwise handle incoming mail equivalently 
  to the primary MX server.  the mechanism by which this is accomplished is
  unspecified.  one mechanism which will work is to provide at least
  one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
  other mechanisms may also be feasible.

  (note that any site with v4 connectivity and globally-usable addresses
  can establish Ipv6 connectivity for such an MX, without needing to
  set up a separate connection, using 6to4.)

- sites with both IPv4 and IPv6 connectivity

  it is RECOMMENDED that sites with IPv4 and IPv6 connectivity provide
  one or more MXes that are reachable by v4 and one or more MXes that
  are reachable by v6.  

  these MXes MAY be located on the same, or different, hosts.  however, 
  different hosts supporting MTAs SHOULD be listed under different 
  domains.  all of the v4 or v6 addresses listed for a particular MX 
  domain SHOULD reach same host.  (this is needed for fail-over from 
  one SMTP server to another to work correctly)

- ISPs

  ISPs are encouraged to provide mechansisms to:

  - allow their IPv4-only customers to send mail to IPv6-only sites
  - allow their IPv6-only customers to send mail to IPv4-only sites
  - allow their IPv4-only customers to receive mail from IPv6-only sites
  - allow their IPv6-only customers to receive mail from IPv4-only sites

  support for outbound mail (from the ISP's customers to sites that
  would otherwise be unreachable) MAY be implemented by the ISP
  providing one or more external MTAs which can relay mail from the 
  customer's network to a destination network which would otherwise be 
  unreachable by the customer.  due to spamming and other concerns, 
  such MTAs SHOULD NOT be configured (or expected) to handle traffic 
  from arbitrary sources to arbitrary destinations, but ONLY cross-realm 
  (v4 to v6 or vice versa) traffic from that ISP's customers.  it would 
  be reasonable for the ISP to require that a standard (non-proprietary) 
  SMTP AUTH mechanism be used to verify the customer's authenticity. 

  other mechanisms for providing that connectivity might also be feasable.  

  if an ISP provides outgoing cross-realm relaying for its customers,
  each customer must configure its own MTAs to use those relays.
  ISPs MUST NOT modify DNS responses to automatically include such MXes
  in the results seen by customers' MTAs.

  support for inbound mail (to the ISP's customers) can be provided by
  the ISP providing one or more MTAs that are willing to act as secondary 
  mail exhangers for the ISP's customers, and which the customer advertises
  in its DNS records.  these MTAs MAY be ordinary MTAs with dual-stack
  capability, or they MAY be v4-to-v6 (or vice versa) protocol translators
  which are explicitly configured to reach the customer's MTA.
  
  such MTAs SHOULD NOT be configured (or expected) to handle traffic from 
  arbitrary sources to arbitrary destinations, but ONLY cross-realm (v4 
  to v6 or vice versa) traffic destined for that ISP's customers.  
  in order to prevent this from being exploited by spammers, it would be 
  reasonable for the ISP to assign a separate address and domain per 
  customer to be used for such purposes, and or MTAs provided by the
  ISP to refuse to accept incoming mail that did not have the proper
  destination IP address for that customer.

  if an ISP provides incoming cross-realm MX relaying for its customers,
  each customer must configure its own DNS zones to use those MXes.
  ISPs MUST NOT modify responses from customers' DNS servers to automatically
  include such MXes.

--------------------------------------------------------------------------

*whew*

I don't claim to have all of the above details correct, but I think that
the *right* solution looks more-or-less like this.  and I do think we
need to specify about this level of detail.  

I don't think that we can expect all customers to provide their own MXes
for both IPv4 and IPv6, and I don't think we can come up with a 
"one size fits all" solution for connectivity.  ISPs will in some cases
need to bridge the gap, but they are often in a good position to know
what their customers need.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Nov 2001 21:17:31 -0000

>      "last resort" relays which can deliver to the other kind of MTA.

Under the RFC 2893 transition plan, hosts with IPv4 addresses can talk
to hosts with IPv6 addresses, so these SMTP relays are unnecessary.

Which makes more sense: configuring separate IPv6 relays for every
application, or configuring one relay for the network stack?

Apparently there is some dispute about the RFC 2893 transition plan. Are
IPv4 addresses going to be able to talk to IPv6 addresses, or is every
existing Internet site going to have to acquire IPv6 addresses?

I object to imposing IPv6 transition requirements on SMTP, or on any
other application, until these fundamental issues have been settled. I
am amazed that this group has not drawn a coherent picture of how the
IPv6 transition is supposed to work.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Sat, 10 Nov 2001 18:02:19 -0500

Dan,

IPv4-only hosts cannot communicate directly with IPv6-only hosts.
This should be obvious to anyone who has read the specifications:
the packet formats are completely different . An IPv4-only host
will not understand IPv6 packets without a software upgrade, and 
even if an IPv6-only host had a means of sending packets to IPv4
hosts, an IPv4-only host would not be able to reply to them.

Depending on the application, translation between IPv4 and IPv6 
may be possible at either the IP level (by translating individual 
packets in a manner similar to NAT-PT) or at the application level 
(as in a SMTP MTA on a host with both IPv4 and IPv6 connectivity,
a simple TCP-to-TCP gateway that speaks IPv4 on one side and IPv6
on the other, or a simple SMTP-aware shim similar to that provided 
by some firewalls).  Any of these works for SMTP.  But for for the 
same reasons that some protocols do not work in the presence of NAT, 
a completely general translation between IPv4 and IPv6 - one that 
works for all applications - is impossible.

For SMTP operation, the method by which translation is done is 
generally irrelevant - either a packet translator box or a 
TCP translator or a dual-stack firewall or a dual-stack MTA will 
work just fine.  The only caveats I have identified so far are these:

1. if packets are received via a translator, received headers
will show an incorrect source address.

2. if there are two addresses for an SMTP server - one which is
routed via NAT-PT and another which goes directly to the server,
those two addresses should be listed as alternate addresses for
the same domain, rather than as separate domains, for the following
reasons:

- if a dual-stack relaying MTA is trying to send to that server
  and it responds with a "temporary failure" error, the relaying
  MTA should not immediately attempt to retry to the same host,
  but it might reasonably try to relay the message to a different
  mail exchanger.  if the relaying MTA sees multiple addresses 
  for the same MX domain it will know to fail over to  another 
  mail exchanger, but if it sees separate domains in separate
  MX records it may well fail over to the same host.

- similarly, if the relaying MTA is using STARTTLS and authenticating
  the SMTP server, the domain that appears in the server certificate
  should match the domain under which that MTA appears in the MX record.
  if the NAT-PT address and the actual address are listed under separate
  domains, this will fail for one case or the other.

However, if the same host that is used for an SMTP server is also
used to serve applications that are incompatible with NAT-PT, it
would cause problems for such applications for both the IPv4 and IPv6
addresses to be listed under the same domain, if that domain was used
by those applications.  for this reason it may be necessary to list
the same host under multiple domains.  for instance:

multi-purpose-server.example.com	IN A xxx.xxx.xxx.xxx

mail-server.example.com			IN A xxx.xxx.xxx.xxx
					IN AAAA YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY

example.com				IN MX 10 mail-server.example.com.

in this example, multi-purpose-server and mail-server are the same
host.  a translator has been set up which will translate between IPv4 
and IPv6 packets for traffic forwarded to and from the IPv4 address 
of this host.  incoming mail will get routed to mail-server.example.com 
either directly or via the packet translator, which is fine since 
SMTP (modulo received headers) doesn't have any problems with address
translators.  however other applications that do not work in the
presence of packet translators will need to use the 
multi-purpose-server.example.com domain name.

> existing Internet site going to have to acquire IPv6 addresses?

Neither.  IPv4-to-IPv6 packet level translation will be used in some cases
but it requires someone to set up a translator, and is not a general 
solution that works for all applications.  Nor does anybody who has
thought much about the problem believe that "every existing Internet site"
will acquire IPv6 support - at least, not very soon.  (however 6to4 makes
this fairly easy for any host that already has a global IPv4 address - 
an OS upgrade is all that is needed - so IPv6 is easier to deploy than 
many seem to think).

My view is that there will be a long period of coexistence, and the 
choice of (probably NATted) IPv4 or (non NATted) IPv6 will often 
depend on the particular application being used.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Nov 2001 23:41:01 -0000

> IPv4-only hosts cannot communicate directly with IPv6-only hosts.

Irrelevant. The only hosts under discussion are hosts where the software
supports IPv6.

RFC 2893 explains how two of these hosts, one with an IPv4 address and
the other with an IPv6 address, can communicate with each other.

Naturally, the details include a mechanism for routing an encoded IPv6
packet through the IPv4 network to the IPv6 network. This is not rocket
science.

What you are proposing, whether you understand it or not, is a foolish
duplication of the same feature in every higher-level protocol, making
unnecessary work for application writers and system administrators.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Sat, 10 Nov 2001 20:02:00 -0500

> Irrelevant. The only hosts under discussion are hosts where the software

wrong.  we are talking about mechanisms which will allow IPv4-only
hosts to exchange mail with IPv6-only hosts, and the former
group includes hosts where *none* of the software (IP, TCP or 
application) supports IPv6.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Sat, 10 Nov 2001 19:38:16 -0600

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, November 10, 2001 7:02 PM
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?

> application) supports IPv6.

It might help to start with an Architecture (i.e. a picture or diagram)
for what you are trying to build. It is then easier to refer to the various
Architectural elements. Most engineering students learn to draw diagrams
in their early years. It is amazing the IETF does not seem to have a
drawing of its Next Generation Internet Architecture.

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Nov 2001 02:18:49 -0000

Keith Moore writes:
> *none* of the software (IP, TCP or application) supports IPv6

Funny. I thought we were discussing ``IPv6 SMTP requirements'': things
that every MTA is going to have to do as part of the IPv6 transition.

Apparently you have a different goal. You want to work with existing
MTAs. You want to work with MTAs that don't know anything about IPv6.

In that case, writing a spec is rather idiotic. You have to use the
_existing_ protocols. You have to work with what the MTAs do _now_. In
other words, you have to support IPv4.

Of course, as long as that's the situation, IPv6 is a failure. IPv6
addresses will be functionally identical to 10.* addresses. Users with
these second-class addresses aren't actually on the Internet; they need
application-level relays to talk to the Internet. Everyone will continue
to compete for real Internet addresses: connected IPv4 addresses.

---Dan

---

From: [email-masked]
Date: Sun, 11 Nov 2001 14:24:11 +0900

>involved in email routing to get this right by simple editing of the

	we specifically did not want to do this.  we believe:
	- it is necessary for IPv6-only sender to get some sort of IPv4
	  connectivity (either via translator service or whatever)
	  to deliver emails to IPv4 receiver
	- vice versa
	it is operators responsibility to ensure reachability from/to IPv4/v6
	destinations.  IPv6-only servers can only operate when the number of
	IPv4-only servers becomes negligible, or when 

	if we try to implement a "last-resort" relaying SMTP server to help
	IPv4-only and IPv6-only server to communicate, we are going to end up
	allowing some thirdparty to relay emails.  only FBI would be funding
	such a relaying service...

>   get worse when you add IPv6 in the mix.

	hmm.  i'm wondering how we can describe a new algorithm then...

itojun

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 09:00:30 -0500

> that every MTA is going to have to do as part of the IPv6 transition.

I realize a lot of people have been using the word "transition".
I personally don't think that's a very useful way to think about it, 
because I don't think that anyone who is using IPv4 is going to
make any firm plans to discontinue using IPv4 anytime soon.
I prefer the term "coexistence".

However I do think that folks are going to be begin using IPv6,
that some of them will not have IPv4 connectivity, and that folks 
using IPv6 will want to exchange mail to folks using IPv4, and 
vice versa.
 
> other words, you have to support IPv4.

Indeed.  But you don't have to support v4 at your own MTA if you can
find a MTA that is willing to be a mail exchanger for your incoming
v4 mail and one that is willing to relay your outgoing v6 mail.

One purpose of the spec is to describe what v6-only sites need to 
do to make this work well.  Another purpose of the spec is to 
describe how new MTAs (whether v4-only, v6-only, or dual-stack)
can work optimally given a mix of v4 and v6 MTAs. 

> to compete for real Internet addresses: connected IPv4 addresses.

For the forseeable future, everyone will need some way to get access
to the major services that are IPv4-based: email, web, etc.  Many sites 
are already doing this with IPv4 NATs and/or application-level proxies 
so it's not difficult to conclude that this will continue to happen.
I expect that for a very long time most sites will get at least one IPv4 
address which can be used for such NATs or proxies to support legacy
applications.  However, there will also be large numbers of hosts that 
can only be directly accessed via IPv6, precisely because the availability
of large numbers of IPv6 addresses will make it possible to network those
hosts in a standard way, when due to the address shortage it is not possible 
to do this with IPv4.    And there will be applications that require use
of IPv6 because they cannot work with NATted IPv4.

It's misleading to speak of IPv6 addresses as "second-class".  IPv6 has a 
different domain of applicability than IPv4.  IPv6 makes it possible to
network a great many more devices than IPv4, and it also makes it possible
to run new kinds of applications.  I think it likely that we will see large 
numbers of IPv6-capable "appliances" - cameras, power meters, game hardware,
security systems, cell phones - anything that would benefit by remote 
control, monitoring, or access.  

IPv6 is a failure only if you expect it to replace IPv4 in a short time.
It's quite clear to all of us that this isn't going to happen.  But 
due to the address shortage and the presence of NATs, IPv4 is getting
less and less flexible and more and more difficult to use for new 
applications.  IPv6 will be successful because it lets us do things
that cannot be done with IPv4.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 09:15:56 -0500

to me, this is a non-starter.   

first, because it's completely unnecessary for email;  

second, because it places an unreasonable burden on sites or networks that 
do not need both general IPv4 and IPv6 access (perhaps because they are 
only supporting a few services that can satisfactorily be provided by other
means) to expect them to have general IPv4 and IPv6 access.

third, because imposition of this burden would hinder deployment of IPv6;

fourth, because translators (whether packet-level or stream-level) are not 
a general solution and the imposition of translators in the IPv6 network 
would harm IPv6's ability to support new applications.

        destinations.  

that's true; however each operator should get to decide what is the 
best means to provide reachability for that operator's applications. 

	IPv6-only servers can only operate when the number of
        IPv4-only servers becomes negligible, or when

that's not true, because MX and last-resort relaying can make it possible
for IPv6-only servers to exchange mail with IPv4-only servers.    

I wasn't suggesting that "we" implement a last-resort SMTP server, or
that there be any central service of this type.  The model I had in mind 
was that ISPs could provide last-resort servers for their customers.  
Many of them already provide SMTP relays anyway; this would be an 
extension of that service.  

Keith

---

From: [email-masked]
Date: Mon, 12 Nov 2001 10:17:45 +0900

>best means to provide reachability for that operator's applications. 

	okay.

>for IPv6-only servers to exchange mail with IPv4-only servers.    

	if you can buy a relaying service from somewhere, that's okay.
	the following two setups are completely happy configuration for me:
	- an email server with IPv4/v6 dual stack reachability.

example.org.	IN MX 1	 mx1.example.org.
mx1.example.org. IN AAAA	3ffe:501:ffff::1
		IN A		192.0.2.1

	- an email server with IPv6-only reachability, and fallback MX record
	  to provide IPv4-to-IPv6 relaying service.

; assuming that relayingservice.com has IPv6 connectivity...
example.org.	IN MX 1	 mx1.example.org.
		IN MX 10 mx10.relayingservice.com.
mx1.example.org. IN AAAA	3ffe:501:ffff::1
mx10.relayingservice.com. IN A	192.0.2.1

>extension of that service.  

	yes, by purchasing relaying service from a service provider the problem
	is gone.  this is what I was trying to say.
	a domain should become reachable from both IPv6/v4, either by:
	- running dual stack email server by theirselves
	- purchasing relaying service from a (trusted) service provider
	for the latter case, the MX records for (IPv6-only) example.org will
	look like this:

; assuming that relayingservice.com has IPv6 connectivity...
example.org.	IN MX 1	 mx1.example.org.
		IN MX 10 mx10.relayingservice.com.
mx1.example.org. IN AAAA	3ffe:501:ffff::1
mx10.relayingservice.com. IN A	192.0.2.1

	our document is trying to ensure IPv6/v4 reachability for an MX, that's
	the point.  I don't think it necessary to document HOW.  some people
	can run dual-stack mail server on their own, some people can buy a
	service from (trusted) service provider.
	i don't understand what you are objecting.

itojun

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 20:56:44 -0500

our document is trying to ensure IPv6/v4 reachability for an MX,
	that's the point.  I don't think it necessary to document HOW.  

there are several modes via which incoming mail can be accepted,
other than a dual-stack MTA or a separate MTA listed as a separate MX.  
but there are different operational issues associated with the different 
operational modes, and there are also different error conditions that need
to be distinguished. we can't really talk about those operational issues 
or error conditions without describing the different modes of operation.

 	some people can run dual-stack mail server on their own, some 
        people can buy a service from (trusted) service provider.
        i don't understand what you are objecting.

I also don't think we can expect every site to provide both an IPv4 and an
IPv6 MX - or even (once v6 gets popular) to expect every site to provide 
an IPv4 MX.  in order to get good service during a period where both v4
and v6 are popular it may be necessary for MTAs to provide ability to send 
outgoing mail that would otherwise be unreachable via a trusted relay.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 11 Nov 2001 20:09:02 -0600

----- Original Message ----- 
From: <[email-masked]>
> mx1.example.org. IN AAAA 3ffe:501:ffff::1

It is good to start clarifying your situation with specific examples.
There may be some percentage of "V6 users" who are not
able/willing to route addresses with the 3ffe prefix. This is a remider
of the meeting this past year at Microsoft, where "V6 users" met,
and apparently found, their 3ffe prefix was not routable. They were
given an opportunity to use the 2002 address architecture.

http://www.unir.com/images/architech.gif
http://www.unir.com/images/headers.gif
http://www.unir.com/images/address.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

Do you use Windows 2000 or Windows XP ?

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: [email-masked]
Date: Mon, 12 Nov 2001 11:16:41 +0900

>or error conditions without describing the different modes of operation.

	how many different configurations do we really need to cover?
	i think you are talking about local configuration issues.
	it is not possible for us to every possible ways to configure SMTP
	servers.  i have no time/energy to do that.

>outgoing mail that would otherwise be unreachable via a trusted relay.

	so buy an outgoing relaying service from your service provider and
	make that SMTP server the last-resort outgoing SMTP destination.
	again, this is matter of local configuration.

itojun

---

From: Pete Resnick <[email-masked]>
Date: Fri, 9 Nov 2001 16:17:32 -0600

>    both RFC 2822 section 5 and RFC 1035 should be referenced

Typo: RFC 2821, not 2822.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102