imported as reference

6 files changed, 3521 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt b/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt
new file mode 100644
index 00000000..83381ea3
--- /dev/null
+++ b/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt
@@ -0,0 +1,286 @@
+                                                                [Page 1]
+
+INTERNET-DRAFT
+File Name: draft-bose-smtp-integrity-00.txt              Author: R. Bose
+Expires on: 4th October,2001
+
+
+        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
+
+   Status of this memo:
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.
+   Note that other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other documents 
+   at any time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Abstract:
+
+   This Internet Draft describes an extension to the SMTP Services which
+   will enable an SMTP Server/Client to check the Integrity of Mails
+   received by it and immediately request for the Mail to be resent if
+   it is found to be corrupted during that particular transaction.
+
+   This extension is meant to apply to both SMTP Clients and Servers as
+   described in detail below.
+
+1. INTRODUCTION
+   
+   As of now there is NO provision in the Simple Mail Transfer Protocol
+   for error checking of messages while they are being transported from
+   client to server OR server to server.This sometimes results in the
+   recipient getting corrupted or truncated messages.And inspite of the
+   speed of the E-Mail delivery system a lot of time is wasted while the
+   recipient informs the original sender about the corruption of the
+   message and waits for the receipt of the uncorrupted message.
+
+   This time delay becomes even more prominent when attachments of
+   significant size (binary or otherwise) are included in the message.
+
+   Hence, an Error Checking provision like the one described below is
+   necessary.An effort has been made so that if the features described
+   below are implemented then only a minimum amount of change has to be
+   done to the current SMTP Server/Client softwares.
+
+
+draft-bose-smtp-integrity-00.txt                                [Page 2]
+
+
+2. INCLUSION OF CHECKSUM IN MESSAGE BODY OF MAIL
+   
+   In order to check the integrity of a message (including any
+   attachments in it) the checksum of the message should be calculated
+   and appended to the beginning of the message.The message then will
+   look like as follows:
+
+   <CHECKSUM TYPE=XX>checksum_string_here<CHECKSUM>
+   ................................................
+   ................................................ 
+   ................................................
+   .......[MESSAGE BODY IS CONTAINED HERE].........
+   ................................................
+   ................................................
+   ................................................
+   ................................................
+
+   The Dotted lines indicate the original message body
+   as inputted by user of Mail Client.
+
+   The Checksum as seen above is stored in the Checksum Header:
+   <CHECKSUM TYPE=XX>checksum_string_here<CHECKSUM>
+   The Checksum Header should be stored as the first line of the mail
+   body with the original mail message starting from the second line.
+
+   The Tag "TYPE" indicates the type of checksum used.Therefore, if:
+
+   Checksum Type     XX
+       16 bit        16
+       32 bit        32   
+ 
+   This will enable the SMTP Server/Client to calculate the appropriate
+   Checksum value in order to compare it with the Original Value stored 
+   in the Checksum Header.But, it is proposed that a 32 bit checksum be
+   used by all SMTP Servers/Clients to check Mail Integrity.
+
+3. CALCULATION/VERIFICATION OF CHECKSUM BY SMTP CLIENT/SERVER
+   
+NOTE: In Sections 3 and beyond, the term "Sender Server" is used for 
+      the SMTP Server which initiates the connection and
+      "Recipient Server" for the SMTP Server to which the mail is being
+      relayed at that stage.
+      "Sender Client" is the SMTP Client who sends the original message 
+      and "Original Recipient Client" is the SMTP Client to whom the 
+      "Sender Client" is sending the Mail.
+ 
+   In this section, the entire process of sending a mail, calculation
+   of it's checksum & it's verification during each stage of transport
+   till it reaches the intended recipient is described.
+
+
+
+
+
+
+draft-bose-smtp-integrity-00.txt                                [Page 3]
+
+                  DIAGRAM OF AN EXAMPLE SMTP TRANSACTION
+
++------+      +-------------+      +---------+     +------------------+
+|Sender|----->|Sender Server|----->|Recipient|---->|Original Recipient|
+|Client| (a)  |             | (b)  | Server  | (c) |    Client        | 
++------+      +-------------+      +---------+     +------------------+
+      
+ a)When the Sender of a Mail has inputted his/her message, the Sender
+   Client will calculate it's checksum and append it to the beginning of
+   the message in the format described in Section 2 above.Then it will
+   send the message in the usual way to the SMTP Server by using the
+   "DATA" command.
+
+ b)When a Recipient Server receives the message body of a Mail from 
+   Sender Client or Server it will immediately extract the first line 
+   from the message body and parse it to extract the values of the 
+   Checksum and the Checksum Type(given by the Tag TYPE).Then it will 
+   calculate the checksum accordingly and compare it to the Original 
+   Checksum which was extracted from the message body.
+   
+   Possible Numeric Replies by the Recipient Server:
+
+   250 OK, Requested mail action okay, completed
+   453 Checksum does not match, resend data
+
+   453 is a new proposed Numerical Error Reply.For maintaining
+   compatibility and dealing with Servers without the checksum 
+   features (which will not be supporting this New numerical reply) 
+   refer to Section 4 (b).
+
+
+   On receiving the 453 numeric reply,the Sender client/server should
+   resend the message body again.If the number of requests to resend
+   message exceeds a user specified number of times(ideally 2-4 times)
+   i.e. if the checksum error occurs persistently then the Sender
+   client/server should simply remove the Checksum Header and then send
+   the message body allowing the Recipient SMTP Server to act in the
+   manner described in Section 4 (a).
+  
+ c)When the Original Recipient Client downloads the message from the
+   Mail Server (for e.g., it is a POP3 Server) it will also immediately
+   extract the first line from the message body and parse it to extract
+   the values of the Checksum and the Checksum Type  (given by the
+   Tag TYPE).Then it will calculate the checksum accordingly and compare
+   it to the Original Checksum which was extracted from message body.
+
+   Possible Actions of the Recipient Client:
+
+    (i)If the Checksum matches then no further action is required.
+
+   (ii)If the Checksum DOES NOT match then the Client should again try
+       to download the message.If Checksum error occurs persistently
+       then it will be prudent for the client to try downloading the
+       message only a user specified number of times(ideally 2-4 times).
+
+
+draft-bose-smtp-integrity-00.txt                                [Page 4]
+
+NOTE: The Concepts mentioned in the Sections 4(b),4(c) and 5 should
+      eventually lose their relevance if the features mentioned in this
+      document are widely accepted and implemented.
+    
+4. MAINTAINING COMPATIBILITY WITH OLDER VERSIONS OF SMTP SERVERS/CLIENTS
+ 
+   In order to maintain backwards compatibility with older versions of
+   SMTP Servers and Clients the procedures described in this section
+   should be used.
+
+(a)If a Recipient Server on receiving a Message Body from the Sender
+   Server/Client tries to extract the Checksum and Checksum Type but
+   fails then the reason for failure can be attributed to the fact that
+   the Sender Server/Client does not have the Checksum facility
+   implemented or a situation has occured like the one described in
+   Section 3 (b).
+
+   If this is the case, then the Recipient Server itself should simply
+   calculate the Checksum and append it to the beginning of the Message
+   Body in the manner described in Section 2 above, so that atleast the
+   integrity of the message can be checked in subsequent transactions.
+
+(b)It is quite possible that during the relaying of a Mail, one of the
+   servers in the middle of the link may not have the checksum features
+   so if the recipient server encounters a Checksum Error during such
+   kinds of transaction it should act in the manner described in 
+   Section 5.
+
+(c)If the Original Recipient Client on receiving a Message Body from 
+   the Mail Server tries to extract the Checksum and Checksum Type but
+   fails then it should simply accept the message download without
+   any comments on it's checksum.
+   
+5. CHECKSUM COMMAND
+
+   It is proposed that a new command be added to the SMTP Commands
+   list to enable the Sender Server to inform the Recipient Server 
+   whether the Sender Server supports the checksum features described 
+   in this document or not.Therefore, every Sender Server **must** send
+   the CHECKSUM Command to the Recipient Server before sending the Mail
+   data by invoking the DATA Command.
+
+   Command Name: CHECKSUM
+   Usage Syntax: CHECKSUM
+   Possible Replies:  250 OK, Requested mail action okay, completed
+                      502 Command not implemented
+
+   Example:
+
+   (1)    Sender Server: CHECKSUM
+       Recipient Server: 250 OK, Requested mail action okay, completed
+
+   (2)    Sender Server: CHECKSUM
+       Recipient Server: 502 Command not implemented         
+ 
+
+draft-bose-smtp-integrity-00.txt                                [Page 5]
+
+   Unlike most SMTP commands, the reply for this command sent by the
+   Recipient Server to the Sender Server is immaterial since this 
+   command is for the benefit of the Recipient Server only, as 
+   given below.
+
+   If the Recipient Server receives the CHECKSUM Command before the 
+   DATA command then only it should send the 453 Numerical Error Reply,
+   when a Checksum Error is encountered.
+
+   If the Recipient Server does not receive the CHECKSUM Command during
+   an SMTP Transaction then it should assume that the Sender Server 
+   does not support the Checksum features mentioned in this document.
+   Therefore, on encountering a Checksum Error,it should simply 
+   recalculate the Checksum of the Mail and replace the old value of the
+   checksum in the Checksum Header which is already present as the first
+   line of the Message Body.
+
+   If the Recipient Server itself does not support the Checksum features
+   mentioned in this document it will simply send a 502 Error to the
+   Sender Server. But the receipt of this Numerical Error Reply does not
+   require any action on the part of the Sender Server.
+
+
+6. REFERENCES
+  
+   1) RFC 821: Simple Mail Transfer Protocol
+      Jonathan B. Postel,
+      Information Sciences Institute,
+      University of Southern California,
+      August 1982.
+    
+   2) RFC 822: Standard for the Format of ARPA Internet Text Messages
+      D. Crocker,
+      Department of Electrical Engineering,
+      University of Delaware,
+      August 1982.
+
+
+7. CONTACT ADDRESS OF AUTHOR
+
+Postal Address: Raja Bose
+                D-4/3,Vasant Vihar,
+                New Delhi - 110057,
+                India.
+
+E-Mail: alokebose@bol.net.in
+
+Telephone: (+91) (011) 614-4638 & 615-1930
+                                                                    
+
+This Internet Draft expires on: 4th October,2001
+
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt
new file mode 100644
index 00000000..1bddc91b
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt
@@ -0,0 +1,151 @@
+
+Internet Draft                              Paul Hoffman
+draft-hoffman-legis-smtp-banner-00.txt       Internet Mail Consortium
+August 25, 1998                             John Levine
+Expires in six months                       IECC
+
+                Anti-UBE and Anti-UCE Keywords in SMTP Banners
+
+Status of this memo
+
+This document is an Internet-Draft. Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time. It
+is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
+(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
+Coast).
+
+1. Introduction
+
+Legislators writing laws that would limit or prohibit the sending of
+unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have
+begun to include rules that require mail servers to include particular
+wording in the SMTP banner. To date, this wording has had two distinct
+purposes: to warn senders that they may not send UBE or UCE to that SMTP
+host, and to state the physical location of the host so that the sender may
+know which laws apply.
+
+This document is meant to help clarify how such legislation might be
+worded, and to help increase interoperability of various laws. It is not
+meant to be a standard of any kind, but is meant only for its informational
+value.
+
+2. The SMTP Banner
+
+SMTP, as defined in [RFC821], is a client-server protocol that runs over
+TCP/IP. When the SMTP client connects to the SMTP server, the server TCP
+immediately emits a banner, also called an "opening message" or "connection
+greeting". The contents of this banner must be in the ASCII character
+set, and the banner must be no longer than 512 characters, including the
+response code, separator, and <CRLF> at the end of the banner.
+
+The banner normally contains software and version information, and often
+contains other useful debugging information. Most SMTP server products
+allow the system administrator to specify the contents of the banner. The
+banner must start with a three-digit status code followed by a space, but
+the rest of banner is not specified by any existing standard.
+
+3. Rationale for Using the SMTP Banner for Anti-UBE and Anti-UCE Messages
+
+There has been some debate about whether or not the SMTP banner is the best
+place to put notices to UBE senders.
+
+The arguments in favor of using the SMTP banner include:
+
+- A potential UBE sender uses almost no resources on the part of the SMTP
+  server to find out that UBE is not allowed.
+
+- It is very easy to describe in legislation, and thus is most likely to be
+  upheld in courts if challenged.
+
+- An SMTP client who wants to send UBE does not need to identify itself
+  before determining if the SMTP server will accept such mail.
+
+- It is easy for a mail system administrator to configure and check the
+  SMTP banner.
+
+- Existing banners are typically much shorter than 512 characters, so the
+  addition of a short phrase is unlikely to violate any standard limits.
+
+The arguments against using the SMTP banner include:
+
+- This overloads the semantics of the banner contents.
+
+- This could instead be done with an ESMTP extension.
+
+4. Suggested Wording for Legislation Restricting UBE and UCE
+
+Legislation that requires wording in the SMTP banner to indicate that UBE
+or UCE is not allowed or is restricted on the server should include the
+exact phrase used. That phrase should be short, succinct, and must not be
+required to be in a particular position in the SMTP banner. We recommend
+the phrase "NO UBE" or "NO UCE", in all uppercase characters.
+
+Note that such a phrase will be human-readable, but it is also easily
+machine-readable if the exact phrase is specified in the legislation. Using
+such a machine-readable phrase makes it easier for potential UBE senders to
+avoid problems by having a program check whether or not the mail server
+accepts UBE before sending the mail. Although the banner phrase should be
+in uppercase characters, clients should recognize the phrase in any
+combination of upper- and lowercase characters.
+
+It should also be noted that most languages around the world require
+characters outside the ASCII character set, but these characters must not
+be used in an SMTP banner. In such cases, the legislation might choose a
+phrase for the SMTP banner which does not make sense in the native language
+of the area in question but is unlikely to appear in a banner for other
+reasons.
+
+5. Suggested wording for Legislation Stating Server Location
+
+Legislation that requires a server administrator to state the location of
+the server should use standardized abbreviations for countries and local
+states or provinces. These locations should be easy to pick out from other
+information in the SMTP banner.
+
+Legislation that requires that the server identify the country that it is
+in should use "C=" followed by the official two-letter country code defined
+in [ISO3166]. Legislation that requires the server identify states or
+provinces should use "L=" followed by an officially-accepted abbreviation
+(if any) for the state or province name. For instance, in the state of
+California, such legislation might require the phrase "C=US L=CA" to be
+included in the banner. (The "C" for country and "L" for location come from
+the widely-used X.500 directory standard.)
+
+6. Security Considerations
+
+Forcing a mail server to state its location can possibly cause an attacker
+to gain valuable information about the server or its characteristics.
+
+7. References
+
+[RFC821] RFC 821, Simple Mail Transport Protocol.
+
+[ISO3166] ISO 3166:1988, Codes for the representation of names of
+countries.
+
+8. Authors' Addresses
+
+Paul Hoffman
+Internet Mail Consortium
+127 Segre Place
+Santa Cruz, CA  95060
+(831) 426-9827
+phoffman@imc.org
+
+John Levine
+IECC
+PO Box 727
+Trumansburg, NY 14886
+johnl@iecc.com
+
+
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt
new file mode 100644
index 00000000..bd4c59e7
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt
@@ -0,0 +1,153 @@
+
+Internet Draft                              Paul Hoffman
+draft-hoffman-legis-smtp-banner-01.txt      Internet Mail Consortium
+September 10, 1998                          John Levine
+Expires in six months                       IECC
+
+                Anti-UBE and Anti-UCE Keywords in SMTP Banners
+
+Status of this memo
+
+This document is an Internet-Draft. Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time. It
+is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
+(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
+Coast).
+
+1. Introduction
+
+Legislators writing laws that would limit or prohibit the sending of
+unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have
+begun to include rules that require mail servers to include particular
+wording in the SMTP banner. To date, this wording has had two distinct
+purposes: to warn senders that they may not send UBE or UCE to that SMTP
+host, and to state the physical location of the host so that the sender may
+know which laws apply.
+
+This document is meant to help clarify how such legislation might be
+worded, and to help increase interoperability of various laws. It is not
+meant to be a standard of any kind, but is meant only for its informational
+value.
+
+2. The SMTP Banner
+
+SMTP, as defined in [RFC821], is a client-server protocol that runs over
+TCP/IP. When the SMTP client connects to the SMTP server, the server TCP
+immediately emits a banner, also called an "opening message" or "connection
+greeting". The contents of this banner must be in the ASCII character
+set, and the banner must be no longer than 512 characters, including the
+response code, separator, and <CRLF> at the end of the banner.
+
+The banner normally contains software and version information, and often
+contains other useful debugging information. Most SMTP server products
+allow the system administrator to specify the contents of the banner. The
+banner must start with a three-digit status code followed by a space, but
+the rest of banner is not specified by any existing standard.
+
+3. Rationale for Using the SMTP Banner for Anti-UBE and Anti-UCE Messages
+
+There has been some debate about whether or not the SMTP banner is the best
+place to put notices to UBE senders.
+
+The arguments in favor of using the SMTP banner include:
+
+- A potential UBE sender uses almost no resources on the part of the SMTP
+  server to find out that UBE is not allowed.
+
+- It is very easy to describe in legislation, and thus is most likely to be
+  upheld in courts if challenged.
+
+- An SMTP client who wants to send UBE does not need to identify itself
+  before determining if the SMTP server will accept such mail.
+
+- It is easy for a mail system administrator to configure and check the
+  SMTP banner.
+
+- Existing banners are typically much shorter than 512 characters, so the
+  addition of a short phrase is unlikely to violate any standard limits.
+
+The arguments against using the SMTP banner include:
+
+- This overloads the semantics of the banner contents.
+
+- This could instead be done with an ESMTP extension.
+
+4. Suggested Wording for Legislation Restricting UBE and UCE
+
+Legislation that requires wording in the SMTP banner to indicate that UBE
+or UCE is not allowed or is restricted on the server should include the
+exact phrase used. That phrase should be short, succinct, and must not be
+required to be in a particular position in the SMTP banner. We recommend
+the phrase "NO UBE" or "NO UCE", in all uppercase characters. Legislation
+mandating either phrase should specify that the phrase must be preceded by
+a non-alphanumeric character, and followed by non-alphanumeric character or
+the end of the banner.
+
+Note that such a phrase will be human-readable, but it is also easily
+machine-readable if the exact phrase is specified in the legislation. Using
+such a machine-readable phrase makes it easier for potential UBE senders to
+avoid problems by having a program check whether or not the mail server
+accepts UBE before sending the mail. Although the banner phrase should be
+in uppercase characters, clients should recognize the phrase in any
+combination of upper- and lowercase characters.
+
+It should also be noted that most languages around the world require
+characters outside the ASCII character set, but these characters must not
+be used in an SMTP banner. In such cases, the legislation might choose a
+phrase for the SMTP banner which does not make sense in the native language
+of the area in question but is unlikely to appear in a banner for other
+reasons.
+
+5. Suggested wording for Legislation Stating Server Location
+
+Legislation that requires a server administrator to state the location of
+the server should use standardized abbreviations for countries and local
+states or provinces. These locations should be easy to pick out from other
+information in the SMTP banner.
+
+Legislation that requires that the server identify the country that it is
+in should use "C=" followed by the official two-letter country code defined
+in [ISO3166]. Legislation that requires the server identify the state or
+province that it is in should use "L=" followed by an officially-accepted
+abbreviation (if any) for the state or province name. For instance, in the
+state of California, such legislation might require the phrase "C=US L=CA"
+to be included in the banner. (The "C" for country and "L" for location
+come from the widely-used X.500 directory standard.)
+
+6. Security Considerations
+
+Forcing a mail server to state its location can possibly cause an attacker
+to gain valuable information about the server or its characteristics.
+
+7. References
+
+[RFC821] RFC 821, Simple Mail Transport Protocol.
+
+[ISO3166] ISO 3166:1988, Codes for the representation of names of
+countries.
+
+8. Authors' Addresses
+
+Paul Hoffman
+Internet Mail Consortium
+127 Segre Place
+Santa Cruz, CA  95060
+(831) 426-9827
+phoffman@imc.org
+
+John Levine
+IECC
+PO Box 727
+Trumansburg, NY 14886
+johnl@iecc.com
+
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt
new file mode 100644
index 00000000..ea97e5fb
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt
@@ -0,0 +1,162 @@
+
+
+Internet Draft                              Paul Hoffman
+draft-hoffman-legis-smtp-banner-02.txt      Internet Mail Consortium
+November 5, 1998                            John Levine
+Expires in six months                       IECC
+
+                Anti-UBE and Anti-UCE Keywords in SMTP Banners
+
+Status of this memo
+
+This document is an Internet-Draft. Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time. It
+is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
+(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
+Coast).
+
+1. Introduction
+
+Legislators writing laws that would limit or prohibit the sending of
+unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have
+begun to include rules that require mail servers to include particular
+wording in the SMTP banner. To date, this wording has had two distinct
+purposes: to warn senders that they may not send UBE or UCE to that SMTP
+host, and to state the physical location of the host so that the sender may
+know which laws apply.
+
+This document is meant to help clarify how such legislation might be
+worded, and to help increase interoperability of various laws. It is not
+meant to be a standard of any kind, but is meant only for its informational
+value.
+
+2. The SMTP Banner
+
+SMTP, as defined in [RFC821], is a client-server protocol that runs over
+TCP/IP. When the SMTP client connects to the SMTP server, the server TCP
+immediately emits a banner, also called an "opening message" or "connection
+greeting". The contents of this banner must be in the ASCII character
+set, and the banner must be no longer than 512 characters, including the
+response code, separator, and <CRLF> at the end of the banner.
+
+The banner normally contains software and version information, and often
+contains other useful debugging information. Most SMTP server products
+allow the system administrator to specify the contents of the banner. The
+banner must start with a three-digit status code followed by a space, but
+the rest of banner is not specified by any existing standard.
+
+3. Rationale for Using the SMTP Banner for Anti-UBE and Anti-UCE Messages
+
+There has been some debate about whether or not the SMTP banner is the best
+place to put notices to UBE senders.
+
+The arguments in favor of using the SMTP banner include:
+
+- A potential UBE sender uses almost no resources on the part of the SMTP
+  server to find out that UBE is not allowed.
+
+- It is very easy to describe in legislation, and thus is most likely to be
+  upheld in courts if challenged.
+
+- An SMTP client who wants to send UBE does not need to identify itself
+  before determining if the SMTP server will accept such mail.
+
+- It is easy for a mail system administrator to configure and check the
+  SMTP banner.
+
+- Existing banners are typically much shorter than 512 characters, so the
+  addition of a short phrase is unlikely to violate any standard limits.
+
+The arguments against using the SMTP banner include:
+
+- This overloads the semantics of the banner contents.
+
+- This could instead be done with an ESMTP extension.
+
+- Even though the load on the recipient's mail server is low, any type of
+banner still represents an admission that the sender is allowed to try to
+send mail that they know is most likely unwanted to the recipient at the
+recipient's expense.
+
+4. Suggested Wording for Legislation Restricting UBE and UCE
+
+Legislation that requires wording in the SMTP banner to indicate that UBE
+or UCE is not allowed or is restricted on the server should include the
+exact phrase used. That phrase should be short, succinct, and must not be
+required to be in a particular position in the SMTP banner. We recommend
+the phrase "NO UBE" or "NO UCE", in all uppercase characters. Legislation
+mandating either phrase should specify that the phrase must be preceded by
+a non-alphanumeric character, and followed by non-alphanumeric character or
+the end of the banner.
+
+Note that such a phrase will be human-readable, but it is also easily
+machine-readable if the exact phrase is specified in the legislation. Using
+such a machine-readable phrase makes it easier for potential UBE senders to
+avoid problems by having a program check whether or not the mail server
+accepts UBE before sending the mail. Although the banner phrase should be
+in uppercase characters, clients should recognize the phrase in any
+combination of upper- and lowercase characters.
+
+It should also be noted that most languages around the world require
+characters outside the ASCII character set, but these characters must not
+be used in an SMTP banner. In such cases, the legislation might choose a
+phrase for the SMTP banner which does not make sense in the native language
+of the area in question but is unlikely to appear in a banner for other
+reasons.
+
+5. Suggested wording for Legislation Stating Server Location
+
+Legislation that requires a server administrator to state the location of
+the server should use standardized abbreviations for countries and local
+states or provinces. These locations should be easy to pick out from other
+information in the SMTP banner.
+
+Legislation that requires that the server identify the country that it is
+in should use "C=" followed by the official two-letter country code defined
+in [ISO3166]. Legislation that requires the server identify the state or
+province that it is in should use "L=" followed by an officially-accepted
+abbreviation (if any) for the state or province name. Legislation mandating
+either type of location should specify that the "C=" or "L=" must be
+preceded by a non-alphanumeric character, and followed by non-alphanumeric
+character or the end of the banner.
+
+For instance, in the state of California, such legislation might require
+the phrase "C=US L=CA" to be included in the banner. (The "C" for country
+and "L" for location come from the widely-used X.500 directory standard.)
+
+6. Security Considerations
+
+Forcing a mail server to state its location can possibly cause an attacker
+to gain valuable information about the server or its characteristics.
+
+7. References
+
+[RFC821] RFC 821, Simple Mail Transport Protocol.
+
+[ISO3166] ISO 3166:1988, Codes for the representation of names of
+countries.
+
+8. Authors' Addresses
+
+Paul Hoffman
+Internet Mail Consortium
+127 Segre Place
+Santa Cruz, CA  95060
+phoffman@imc.org
+
+John Levine
+IECC
+PO Box 727
+Trumansburg, NY 14886
+johnl@iecc.com
+
diff --git a/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt b/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt
new file mode 100644
index 00000000..0b6f76f8
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt
@@ -0,0 +1,2478 @@
+
+
+
+
+
+
+
+IPNG Working Group                       DNS Discovery Design Team
+INTERNET-DRAFT                                 Dave Thaler, Editor
+Expires September 2001                               July 12, 2001
+
+
+
+
+
+       Analysis of DNS Server Discovery Mechanisms for IPv6
+        <draft-ietf-ipngwg-dns-discovery-analysis-00.txt>
+
+
+
+
+
+                       Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups. Note that
+other groups may also distribute working documents as Internet-
+Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time. It is inappropriate to use Internet- Drafts
+as reference material or to cite them other than as "work in
+progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+
+
+Copyright Notice
+
+Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+
+Abstract
+
+
+
+
+
+Expires January 2002                                      [Page 1]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+There are any number of ways that IPv6 hosts can discover
+information required to enable name resolution, in the absence of
+a DHCP server.  This document discusses the issues and provides a
+taxonomy of possible solutions, and evaluates them against various
+design criteria.  Finally, it provides recommendations as input to
+the standards process.
+
+
+1.  Introduction
+
+The function of name-to-address resolution (or vice versa) in IP
+is performed by the Domain Name Service (DNS) [RFC1034, RFC1035].
+Using DNS requires that at least one DNS Server be known and
+reachable by a device desiring to resolution.
+
+There is also underway, known as Multicast DNS (mDNS) [MDNS], on
+resolving names on the link in the absence of a DNS Server.  In a
+managed environment with DNS Servers, mDNS is typically disabled
+(via the domain search path).  As a result, it is required that a
+device be able to discover whether DNS Servers are available and
+discover its search path.  Thus, the mechanisms analyzed in this
+report do not conflict with, but actually support the mDNS work.
+
+In the absence of a DHCP server, the current IPv6 protocol suite
+does not yet provide a mechanism to discover DNS servers or search
+paths.  To solve this problem, a design team was chartered by the
+IPNG Working Group to investigate possible solutions and provide a
+recommendation as input to the working group.
+
+This document summarizes the approaches investigated, and provides
+an analysis of each, and describes its recommendations.  The
+design team participants are listed in the Authors' Addresses
+section below.
+
+
+2.  Requirements
+
+For a device to effectively resolve names, and potentially allow
+resolution of its name to be performed, the following information
+is required:
+
+ o One or more addresses of DNS servers.  If a list is obtained, a
+   client need only rediscover DNS servers if all addresses in the
+   list are unreachable.  However, if a list is obtained from a
+   single point, such as one of the DNS servers, then a
+
+
+
+
+
+Expires January 2002                                      [Page 2]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   requirement exists that the list of servers be up-to-date and
+   easily maintainable.
+
+ o Domain name
+
+ o Search path.  It is currently common practice, for the search
+   path to be computed by a device based on its domain name
+   obtained.  However, a DHCP option [DOMSEARCH] is being proposed
+   in the DHC WG, and so search path configuration is likely to be
+   a requirement in general.
+
+It is a further requirement that the above information be obtained
+without using a DHCP server.
+
+Automatic configuration of DNS servers, if no DNS servers exist
+within the IPv6 site, is not a requirement.  However, it is
+expected that there may be devices on site boundaries which will
+want to relay messages containing the above types of DNS
+information across site boundaries.  One such likely scenario
+would be a home gateway device, where a home is its own site,
+wanting to allow devices in the home to discover and use an
+external DNS server, provided by an ISP.
+
+
+3.  Criteria for Evaluation
+
+Each mechanism can be evaluated against a number of criteria:
+
+Scalability
+   Is the mechanism scalable to a huge number of devices within a
+   site?
+
+Security
+   Does the mechanism support authentication?  What pre-
+   configuration is assumed?
+
+Time to Deploy
+   Can the mechanism be deployed immediately?  What devices need
+   to have software updated to deploy the mechanism?  What devices
+   need to have additional configuration done with existing
+   software?
+
+Business Motivation
+   Do the parties required to implement any new code have a
+   business motivation to do so, in preference to other options?
+
+
+
+
+
+Expires January 2002                                      [Page 3]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   Do the parties required to deploy any new devices or software
+   have a business motivation to do so, in preference to other
+   options?
+
+Standardization
+   Does the mechanism require anything new to be standardized?  If
+   so, is the standardization within the realm of another Working
+   Group?
+
+Fate Sharing
+   If deployed, does the mechanism introduce dependencies on other
+   devices, protocols, or processes that would not normally be
+   required to perform name resolution?
+
+Convergence Time
+   Upon the failure of a DNS server, router, or link, how long
+   does it take for the mechanism to converge?
+
+Scenarios
+   Does the mechanism work in all scenarios?  Scenarios of note
+   include:
+
+   o  Isolated link with a DNS server but no routers
+
+   o  Site with routers, but no multicast routing enabled
+
+   o  Hosts connected over an NBMA link
+
+
+4.  Taxonomy
+
+Mechanisms can be categorized by their choice of transport
+mechanism (e.g., are the messages multicast or unicast?), and by
+their choice of packet format.
+
+Sections 5 and 6 cover these two axes, and describe the set of
+mechanisms evaluated.
+
+
+5.  Transport Mechanisms
+
+5.1.  Anycast for DNS server discovery only
+
+This method is based on the use of a well-known site-scoped
+anycast address which is used during DNS server discovery only.
+
+
+
+
+
+Expires January 2002                                      [Page 4]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+We assume that IANA defines a well-known site-scoped anycast
+address, which can be assigned one or more servers.  For optimal
+fate-sharing, we assume that these servers are DNS servers.  The
+aim is to provide a mechanism that allows DNS servers assigned the
+well-known anycast address to be reachable within a site.
+
+The proposal is based on a two-step discovery process.  First, a
+device sends, using a connection-less protocol, a server-discovery
+message with the anycast address as a destination address.  The
+message will eventually reach a topologically closest server with
+the anycast address.  The server will send a reply with a unicast
+address as the source address, containing a list of unicast
+addresses of valid DNS servers, plus the domain name and search
+path.  Thereafter, all communication for name resolution is done
+using one of the unicast addresses in the list obtained.  Only if
+all addresses in the list are unreachable does the device need to
+repeat the discovery process.
+
+Obviously, this requires that all IPv6 devices requiring DNS
+server discovery in the absence of a DHCP server must implement
+this mechanism.
+
+
+There are three immediate deployment options:
+
+a) Run the servers on routers, and configure them to inject host
+   routes for the anycast address into the site's routing
+   infrastructure.
+
+b) Run a routing protocol on the servers, and configure them to
+   inject host routes for the anycast address into the site's
+   routing infrastructure.  Note that this requires that a server
+   and its router(s) must run the same routing protocol, at least
+   for communication between the router(s) and the server(s) on
+   the link.  Note that, however, a server does not need to
+   participate fully in the routing protocol, it only needs to be
+   able to inject routes.  For example, RIPng [RIPNG], configured
+   for outbound advertisements only, would be sufficient.
+
+c) Run multiple servers on the same link(s), and configure their
+   local router(s) to inject host routes for the anycast address
+   into the site's routing infrastructure.  Running multiple
+   servers on the same link provides robustness to the failure of
+   a server, while routing provides robustness to the loss of
+   routers and other links.  There may still be some failures,
+
+
+
+
+
+Expires January 2002                                      [Page 5]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   however, such as a unidirectional failure of the router's
+   interface, which are not handled by this option.
+
+If new code can be added to the router, a fourth option is also
+possible:
+
+d)  Using Neighbor Discovery to track whether servers are present.
+    In this case a router will be configured to solicit certain
+    Site-scoped anycast addresses when booting. This can also be
+    done periodically.  Upon receiving a reply, the router will
+    have the true address of the server in its Neighbor Cache and
+    can inject a host route into the system for this Site-scoped
+    anycast address.  A variant of this option, which would not
+    require configuring the routers with the addresses to solicit,
+    would be to combine it with running a routing protocol on the
+    servers.  The router could then solicit whatever addresses
+    were advertised in host routes, and take advantage of neighbor
+    unreachability detection to quickly expire host routes.
+
+    Routers should have this feature and allow configuration to
+    enable or disable it. Also the Site-scoped addresses can be
+    configurable when enabling this feature. This is to ensure
+    that network administrators can add new Site-scoped addresses
+    without the need for new software.  On some links, it may be
+    required to not allow hosts to announce these services.  Hence
+    soliciting anycast addresses should not be enabled on those
+    links.
+
+    It should be noted that this option does not require any
+    protocol changes to ND, as it relies on the allocation of
+    Well-known site-scoped anycast addresses to the hosts.
+
+
+For a longer-term solution, a mechanism for communicating anycast
+group joins to routers is desired.  It is expected that this would
+be done as an extension to the Multicast Listener Discovery [MLD]
+protocol, and the sockets API for joining multicast groups.  There
+is now work in progress [HOST-ANYCAST] in this regard.
+
+More details on generic anycast issues are available in [ITOJUN-
+ANYCAST].
+
+
+
+
+
+
+
+
+
+Expires January 2002                                      [Page 6]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+5.1.1.  Evaluation
+
+Scalability
+   The use of anycast can scale up to an arbitrarily large number
+   of devices within the site, since to perform DNS server
+   discovery, devices will only contact their closest server.  As
+   a result, scalability can be achieved by adding more servers as
+   the number of devices increases.  Since all traffic is unicast
+   traffic, no extra bandwidth is consumed on links other than
+   those between a device and its closest server.
+
+   A large number of servers can also be supported easily, if
+   desired, since only a single server is contacted to obtain a
+   list of DNS servers, and the list obtained need not contain all
+   DNS servers in the site.
+
+
+Security
+   The use of anycast is vulnerable to the same attacks as
+   unicast.  This mechanism can best be authenticated by having
+   the content signed via a content-specific mechanism.
+
+   It may be possible to use IPsec to authenticate the discovery
+   messages, but IKE cannot be used for anycast transmission, as
+   RFC 2373 does not allow an anycast address to be used as the
+   source address of packets.  As a result, barring future
+   research and development of other key distribution protocols,
+   using IPsec instead of a content-specific mechanism would
+   require manual keying.
+
+   In addition to securing discovery messages, it is also
+   necessary to secure the mechanism used to communicate anycast
+   joins from DNS servers to routers.  Without such
+   authentication, the possibility would exist for a rogue server
+   to redirect traffic to itself, and away from valid servers.
+
+   In option (a), this is easy since the server is on the same
+   machine as the router.  Likewise, in option (c), joins are done
+   by manual configuration which is easily securable.  Option (b),
+   however, requires utilizing authentication mechanisms available
+   with current routing protocols (e.g., MD5 with RIPng [RIPMD5]).
+
+   In option (d), only Neighbor Discovery messages need to be
+   secured.  However, authenticating Neighbor Discovery messages
+   is needed regardless of the option chosen, even if only to
+
+
+
+
+
+Expires January 2002                                      [Page 7]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   secure discovery by devices on the same link.
+
+
+Time to Deploy
+   Anycast discovery can be deployed as soon as clients are
+   available, using any of the immediate-term options listed
+   above, alone or in any combination, at the choice of each site
+   administrator, without any need to coordinate with others.
+
+   For immediate option (a), one must update one or more routers
+   to run a server, if none already do.
+
+   For immediate option (b), one must update one or more DNS
+   servers to run an IPv6 routing protocol which can talk to its
+   local router(s).
+
+   For immediate option (c), one must ensure that multiple servers
+   are deployed on the same link(s).  One then configures its
+   local routers with a static host route for the anycast address.
+
+   To deploy option (d), routers on servers' links need to be able
+   to inject routes based on responses received from ND
+   solicitations.  This would require SW upgrades for those
+   existing routers.
+
+   In all four options, one must finally configure the servers
+   with the well-known anycast address.  No configuration is
+   needed on other routers or devices, so configuration is
+   confined to a small number of devices.  It is expected that at
+   least one of the above options will be acceptable to IPv6 site
+   administrators for the immediate future.
+
+
+Business Motivation
+   The primary business motivation is that it can be deployed
+   immediately with a minimum of effort and cost, compared to
+   other options.  As time progresses, the incentive to upgrade to
+   either option (d) or a dynamic joining protocol is that the
+   site would not be limited to the three basic options.
+
+
+Standardization
+   For immediate deployment, including option (d), nothing new is
+   required.  For a longer-term optimal solution, an anycast-
+   joining protocol is required.  It is expected that this would
+
+
+
+
+
+Expires January 2002                                      [Page 8]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   be done within the IPv6 Working Group as an extension to MLD.
+
+
+Fate Sharing
+   This mechanism exhibits good fate sharing properties.  No
+   additional dependencies on any other devices, protocols, or
+   processes exist, beyond those that are already required for
+   performing actual name resolution using DNS (i.e., unicast
+   reachability).
+
+
+Convergence Time
+   When a router or link fails, the convergence time is the
+   convergence time of the unicast routing protocol in the site,
+   if the server is off-link, or the convergence time of Neighbor
+   Discovery if the server is on-link.  When a server fails, this
+   is also the convergence time of DNS server discovery, but not
+   for name resolution.  Since unicast is used for actual name
+   resolution, a host with a list of DNS servers may converge
+   faster to another DNS server it previously discovered, when a
+   DNS server fails.
+
+
+Scenarios
+   This mechanism should work in all scenarios discussed.
+   Specifically, it will work in the absence of routers and in the
+   absence of multicast-capable media and routing protocols.
+
+
+5.2.  Anycast for name resolution
+
+Assign a well-known site-scoped anycast address to DNS servers.
+Use anycast destination address on DNS queries.  Anycast packet
+will eventually reach the topologically a closest DNS server.  DNS
+server will send a reply.
+
+While the other mechanisms evaluated try to obtain unicast IPv6
+addresses of DNS servers, this approach uses anycast as the actual
+name resolution transport.
+
+Acquiring the domain name and search path must still be done as in
+section 5.1 above, however.
+
+
+
+
+
+
+
+
+Expires January 2002                                      [Page 9]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+5.2.1.  Configuration
+
+Define a well-known site-scoped anycast address, and write it down
+on a document.  Let us assume that it is fec0::9999 for now.
+
+Configure clients to send DNS queries to the address.  The
+configuration does not need to be modified even if the machine
+moves from a site to another, as the anycast address is well-
+known.
+
+Configure DNS servers (server-1, server-2 to server-N) with the
+anycast address, and make them reply the query to fec0::9999.
+Make sure that packets with the anycast destination address get
+routed to DNS servers.  (see a section below on this topic)
+
+5.2.2.  Actual use
+
+(1)  When a DNS name resolution is necessary for a client, the
+     client would transmit a DNS query (usually UDP) toward
+     fec0::9999.
+
+     client -> fec0::9999    DNS query
+
+(2)  The DNS query will reach one of the DNS servers (suppose it
+     was "server-X").  The server will resolve the name by making
+     a recursive query.  The server will send a reply to the
+     client.  If we follow the RFC 2373 restriction that an
+     anycast address cannot be used as a source address, we need
+     to use server-X's unicast address as the source.  In this
+     case, DNS clients should not check the source address of DNS
+     replies.  Some existing implementations do this to check if
+     the packet was really from the server queried.  The check is
+     rather weak, however, as it is easy to spoof the source
+     address.  Instead, DNSSEC should be used here.
+
+     server-X -> client  DNS reply
+
+5.2.3.  Evaluation
+
+Note that there are multiple ways to handle anycast routing in a
+site.  Some of them require us to inject a /128 route into the
+routing system, some of them does not.
+
+Scalability
+   The scalability of the proposal is exactly the same as the
+
+
+
+
+
+Expires January 2002                                     [Page 10]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   scalability implication in anycast routing.  Note that, as the
+   proposal uses a site-scoped anycast address, we need to scale
+   up to a single site - we do not need to scale up to the whole
+   Internet.
+
+   Regarding to the site network size, the approach should have no
+   problem, except the possible delay imposed by extra hops
+   between DNS clients and servers.
+
+   Regarding to the impact from the number of possible DNS servers
+   to the site routing system, there should be no problem.  Even
+   if we are to inject a /128 route to the site routing system, we
+   will have a single extra routing entry on site routers.  As we
+   share a single site-scoped anycast address among the DNS
+   servers, we just need to carry a single /128 route in the site
+   routing system.
+
+   Regarding to the load balancing among DNS servers, it depends
+   on (1) the network topology in the site, (2) where the DNS
+   servers are located, (3) where the DNS clients are located, and
+   (4) the anycast routing mechanism we use.  If we need to
+   implement a perfect load balancing among DNS servers (equal
+   load onto each DNS servers), we should just put DNS servers
+   onto a single IPv6 subnet.  Neighbor discovery for anycast
+   address should take care of it.  Refer to [ND], section 7.2.7.
+
+   There is no impact against the worldwide routing system.
+
+
+Security
+   The security issues with this mechanism are the same as those
+   discussed in section 5.1.
+
+Time to Deploy
+   The proposal is based on standardized mechanisms, including
+   anycast, routing protocols (like RIPng) and DNS lookup over
+   IPv6.  This is just a matter of configuration to deploy this
+   proposal.
+
+   There are widely-deployed implementations that support anycast
+   address assignment.  There are many IPv6 routing protocol
+   implementations.
+
+   As for DNS lookup over IPv6, there are servers (including ISC
+   BIND9) and clients (including BIND9, NetBSD, OpenBSD, FreeBSD,
+
+
+
+
+
+Expires January 2002                                     [Page 11]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   and Linux) that support it.
+
+   The use of TCP with anycast needs more study (spec-wise), so
+   DNS query/reply over IPv6 TCP may need some time to deploy.
+
+   Regarding to the sanity checks made by DNS client
+   implementation, BIND-based implementation has a configurable
+   option to turn off the source address validation on the DNS
+   reply packet.
+
+   To deploy this proposal, there is no requirement to run
+   additional servers.
+
+Business Motivation
+   If there are operating system implementations without anycast
+   support, we apparently cannot use the operating system
+   implementation as a DNS server.  If there are commercial
+   operating systems that do not support anycast, they now have a
+   good motivation to support it.
+
+Standardization
+   As the proposal uses DNS as the content format, it is safe to
+   say that the content is standardized well.
+
+   We already have couple of standardized IPv6 routing protocols.
+   So even if we are to use routing protocol to inject a /128
+   route for the DNS server anycast address, there should be no
+   problem.
+
+   For full discussions on anycast routing, refer to [ADDRARCH]
+   and [ITOJUN-ANYCAST].
+
+Fate Sharing
+   As DNS queries use site-scoped anycast address as the
+   destination, DNS query/reply relies upon anycast routing
+   mechanism.  There is no circular dependency between anycast
+   routing and DNS lookups.
+
+Convergence Time
+   There are couple of possible configurations for anycast packet
+   delivery.
+
+   If we run anycast DNS servers on routers, the convergence time
+   will be the same as the router failure recovery time.  When a
+   router with DNS server dies, we need to wait until another
+
+
+
+
+
+Expires January 2002                                     [Page 12]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   router to take it over.
+
+   If we inject /128 routes onto the site routing system for
+   anycast packet delivery, the convergence time will depend on
+   the routing information propagation time of the site routing
+   system.
+
+   As to partial failure (like DNS server daemon died but the
+   operating system is alive), there are many failure modes to
+   mention and there are many implementation dependencies.
+   Implementers may need to diagnose partial failure modes in
+   detail.
+
+Scenarios
+   This mechanism should work in all scenarios discussed.
+
+
+5.3.  Link-scoped multicast with router-only responses
+
+This transport approach is modeled after IPv6 Neighbor Discovery
+[ND] transport mechanisms.  It could be part of [ND] or another
+protocol using a similar transport mechanism.
+
+This approach has two modes.  The first is routers periodically
+advertise DNS information (e.g., DNS server addresses, default
+domain, and search path) to all nodes on a link by sending an
+advertisement to the all nodes link-scope multicast address (i.e.,
+FF02::1 ).
+
+The second mode is that nodes needing DNS information can send a
+solicitation to the all routers link-scope multicast address
+(e.g., FF02::2) requesting DNS information.  Routers with the DNS
+information will respond with an advertisement with the requested
+DNS information.  This advertisement will be sent to the unicast
+address of the node sending the solicitation.
+
+
+5.3.1.  Evaluation
+
+Scalability
+   This transport approach has excellent scalability.  It scales
+   as well as ND and DNS does currently.  All of the multicast
+   traffic is local to the link. The periodic advertisement rates
+   can be tuned to environment including turn it off completely
+   and relying on the solicitation/advertisement mode.
+
+
+
+
+
+Expires January 2002                                     [Page 13]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   ND transport mechanisms work on a variety of link (e.g.,
+   multicast capable, point-to-point, shared media, etc.).  It
+   will well suited for both wired and wireless links.
+
+
+Security
+   Mechanisms that are being developed to authenticate ND can be
+   applied to this approach as well.  The only preconfiguration is
+   done in routers where the DNS information is held.
+
+   No new security issues are raised.  All of the traffic is link-
+   scoped.  Any attacks require link access and if successful only
+   affect nodes on the individual link.
+
+
+Time to Deploy
+   This approach requires implementation in nodes wishing to learn
+   DNS information and in routers to provide the information.  The
+   router will need to be configured with the DNS information
+   needed in the advertisements.
+
+   If done as an extension to ND, it will be a small amount of
+   work to extend the ND implementation to add the additional
+   functionality.  If done in a new protocol it would be more
+   difficult to create the new protocol.
+
+   It should be possible to deploy it quickly once the details are
+   scoped out and the implementations are developed.  There is no
+   new network wide services such as multicast or anycast that
+   need to be deployed.  There are no dependencies with other
+   protocols.
+
+
+Business Motivation
+   This approach is a simple extension to existing protocols in
+   existing products and there should be ample motivation to add
+   it to existing products.  No complex dependencies are created.
+   No new network transport mechanisms (e.g., anycast) are
+   required.  No network operators have to deploy any new
+   transport mechanisms (e.g., multicast and/or anycast).
+
+
+Standardization
+   A single document would have to be written to describe an
+   extension to ND or a new protocol.  This would have to become
+
+
+
+
+
+Expires January 2002                                     [Page 14]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   an IETF standard.  This is within the scope of the IPng working
+   group.  No other IETF working groups would need to be involved.
+
+
+Fate Sharing
+   The only fate sharing issue raised is that it ties the
+   discovery of DNS information with the operation of routers on a
+   link.  This is very similar to the common practice with IPv4 of
+   using Bootp relays in routers to communicate with DHCP servers,
+   so in practical terms the issue is very small.
+
+   No changes are made to DNS servers or way nodes communicate
+   with DNS servers.
+
+
+Convergence Time
+   Convergence time is similar to current IPv4 DNS operation using
+   DHCP for DNS discovery. No new convergence issues are created.
+   If one of a set of DNS servers is unavailable (e.g., down,
+   isolated, etc.), then normal DNS recover mechanisms will select
+   an alternative DNS servers.
+
+   If one of a set of routers is unavailable, other routers on the
+   link will continue providing the DNS information.
+
+   If the last DNS server is unavailable, then it is down.  If the
+   last router is unavailable, then new nodes will not be able to
+   learn DNS information or reach any DNS server through the
+   router.
+
+
+Scenarios
+   This mechanism works over a broad range of scenarios.  It
+   should work as well on links that are high performance (e.g.,
+   LANs) and low performance (e.g., wireless).
+
+   However, this mechanism relies on routers and does not support
+   DNS servers on isolated links.  Other local DNS server
+   discovery mechanisms (e.g., multicast DNS) would be needed.
+   This approach is believed to be compatible with multicast DNS
+   approach being developed in the IETF.
+
+   It can be used in either a periodic multicast advertisement, or
+   a solicitation/advertisement mode.
+
+
+
+
+
+
+Expires January 2002                                     [Page 15]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+5.4.  Link-scoped multicast (with router assist)
+
+In this approach, devices send a request to a (new) well-known
+link-scoped multicast address.  DNS servers and routers both
+listen to this multicast address.  If any DNS servers exist on the
+list, they can respond directly to the host.
+
+In addition, routers are responsible for using some other
+mechanism to obtain the DNS server list (e.g., one of the other
+mechanisms evaluated in this document).  Routers with the DNS
+information will respond with an advertisement with the requested
+DNS information.
+
+
+5.4.1.  Evaluation
+
+Scalability
+   This mechanism scales fine on each individual link.  The
+   scalability across the site depends on the scalability of the
+   inter-router mechanism used.
+
+
+Security
+   The use of multicast is vulnerable to the same attacks as
+   unicast.  This mechanism can best be authenticated by having
+   the content signed via a content-specific mechanism.
+
+   It may be possible to use IPsec to authenticate the discovery
+   messages, but IKE cannot be used for multicast transmission.
+   As a result, barring future research and development of other
+   key distribution protocols, using IPsec instead of a content-
+   specific mechanism would require manual keying.
+
+   In contrast to the anycast approaches, it is not strictly
+   necessary to secure the mechanism used to communicate multicast
+   joins from DNS servers to routers, since a rogue server cannot
+   redirect traffic to itself that would otherwise reach a valid
+   server.
+
+
+Time to Deploy
+   This approach can be deployed by devices immediately, as link-
+   scoped multicast is already ubiquitous.  However, the time to
+   deploy router assist to discover off-link servers depends on
+   the inter-router mechanism chosen.
+
+
+
+
+
+Expires January 2002                                     [Page 16]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+Business Motivation
+   No strong business case for choosing this mechanism over the
+   others evaluated is known.
+
+
+Standardization
+   Nothing new is required, beyond whatever is required for the
+   content mechanism and the inter-router mechanism.
+
+
+Fate Sharing
+   Good fate sharing is preserved in this partial mechanism, as no
+   additional dependencies on other devices or protocols is
+   introduced, beyond whatever is required for the inter-router
+   mechanism.
+
+
+Convergence Time
+   The convergence time depends on the convergence time of the
+   inter-router mechanism used.
+
+
+Scenarios
+   This mechanism works on an isolated link, and can work in the
+   absence of multicast routing (provided a non-multicast inter-
+   router mechanism is used).
+
+   However, it does not support the NBMA link scenario.
+
+
+5.5.  Site-scoped multicast
+
+Site-scoped multicast could be used to discover all DNS servers
+within a site.  This would be analogous to the way multicast is
+currently used by IPv6 hosts to discover their neighboring
+routers, but over the span of a site rather than just a single
+link.
+
+There are several possible ways for site-scoped multicast to be
+used for DNS (or any other) server discovery.  The clients could
+send multicast query packets to a well-known, site-local, "all-
+site-DNS-servers" multicast address, to which all DNS servers
+would listen and respond.  Alternatively, the servers themselves
+could send periodic multicast advertisement packets to a well-
+known, site-local, "all-site-DNS-clients" multicast address, to
+
+
+
+
+
+Expires January 2002                                     [Page 17]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+which all clients would listen in order to discover the presence
+and address(es) of all of the site's DNS servers.  Probably the
+best approach, from the point of view of responsiveness, scaling,
+and traffic volume is to use both of those techniques in
+combination, exactly as they are used for router discovery, as
+follows:
+
+
+o  Two well-known, site-local scoped, multicast addresses are
+   assigned by IANA, one for all-site-DNS-routers and one for all-
+   site-DNS-clients.
+
+
+o  When a DNS server starts up, it multicasts a small number (say,
+   3) of advertisement messages to the all-site-DNS-clients
+   address at short (sub-second) intervals, and then continues to
+   retransmit the advertisement messages but at much larger
+   intervals (30 seconds or more).  It also sends a unicast
+   response to any (unicast or multicast) DNS discovery query
+   message it receives.
+
+
+o  When a client starts up (or when the first attempt to perform a
+   DNS look-up occurs), if the client has not yet heard any
+   advertisements from DNS servers, it multicast up to a small
+   number (say, 3) of query messages to the all-site-DNS-servers
+   address at short (sub-second) intervals, stopping as soon as it
+   receives a response from a DNS server or it reaches the small
+   retransmission limit.  From that point on, the client does not
+   send any multicast queries, but rather relies on passively
+   discovering additional DNS servers (and DNS servers that fail
+   and subsequently recover) by listening on the the all-site-DNS-
+   clients address for advertisements.
+
+The response and advertisement messages would ideally contain only
+the address of the sending DNS (rather than a list of multiple DNS
+servers, which which would impose an undesirable requirement for
+configuration of, or a coordinating protocol among, the servers).
+That one address could be found either in the Source Address field
+of the IPv6 header or in the content of the message.  Clients
+would build their lists of candidate DNS servers by taking the
+union of the responses/advertisements received.
+
+To avoid the need for additional packet exchanges, the response
+and advertisement messages should also carry the other information
+
+
+
+
+
+Expires January 2002                                     [Page 18]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+required by the client, i.e., the domain name and default domain
+search list to be used by clients within the site.  [Open issue:
+what ought a client to when not all DNS serves are advertising the
+same information?]
+
+
+5.5.1.  Evaluation
+
+Scalability
+   The recommended technique, above, imposes a steady-state
+   traffic load on a site of one multicast packet per DNS server,
+   every (30 second or greater) advertisement transmission
+   interval.   Because almost all nodes would be expected to
+   listen to those multicasts, they would effectively be site-wide
+   broadcast messages.  However, note that the retransmission
+   interval can safely be made quite large to minimize the
+   overhead of those message, since the technique does not rely on
+   a small interval for its responsiveness; rather, the periodic
+   multicast advertisements serve the role of ensuring long-term
+   consistency and recovering from rare failures (e.g., loss of
+   three packets in a row, or site partitioning).
+
+   In addition to the overhead of the periodic advertisements,
+   there is also the small (maximum 3 packet) burst load of
+   queries/ responses/advertisements that occur whenever a client
+   or DNS server starts up.  Note that these costs are comparable
+   to those incurred by the anycast techniques described in other
+   sections.  They can also be further reduced by a more
+   sophisticated design, in which queries and/or responses are
+   delayed for small, randomized time intervals in order to do
+   "suppression" of identical queries or responses that occur very
+   close together, e.g., when a site comes up after a site-wide
+   power-failure.
+
+   Using this technique requires that all, or almost all, nodes
+   within a site send multicast packets at some point or another.
+   A multicast routing implementation that instantiated state for
+   every active multicast source node would have a state cost on
+   the order of the number of nodes in the site.  It may be
+   preferable to use a multicast routing protocol that
+   instantiates state only for each active multicast source
+   *subnet* (which is sufficient to support shortest-path
+   multicast delivery), or for each multicast destination address
+   (so-called "shared-tree" multicast, which does not try to
+   achieve shortest-path delivery, which is not important for this
+
+
+
+
+
+Expires January 2002                                     [Page 19]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   particular application).
+
+
+Security
+   The security evaluation for all types of multicast is discussed
+   in section 5.4.1.
+
+
+Time to Deploy
+   It is expected that most sites will not have site-wide
+   multicast deployed in the near-term future.  As a result, it
+   may be some time before a site-scoped multicast solution could
+   be deployed.
+
+
+Business Motivation
+   Given the perceived extra cost of managing a multicast-enabled
+   infrastructure, when other solutions relying only on unicast
+   routing exist, it is expected that no strong business case for
+   choosing site-scoped multicast exists.
+
+
+Standardization
+   Protocols needed for multicast connectivity are already on the
+   standards track, or in progress.
+
+
+Fate Sharing
+   This mechanism places an extra dependency on the correct
+   functioning of the multicast routing system.  There are no
+   dependencies on any extra devices, however, beyond those that
+   are already required for name resolution.
+
+
+Convergence Time
+   When a router or link fails, the convergence time is the
+   convergence time of the multicast routing protocol in the site.
+   When a server fails, this is also the convergence time of DNS
+   server discovery, but not for name resolution.  Since unicast
+   is used for actual name resolution, a host with a list of DNS
+   servers may converge faster to another DNS server it previously
+   discovered, when a DNS server fails.
+
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 20]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+Scenarios
+   This mechanism works on an isolated link with a DNS server but
+   no routers.
+
+   However, it does not work in a site with no multicast routing
+   enabled, or among hosts connected over an NBMA link.
+
+
+5.6.  Hybrid
+
+It is possible to combine the above approaches in some situations.
+For example, the option for link-scoped multicast with router
+assist requires one of the other options to form a complete
+solution.
+
+It is also possible for one of the above mechanisms to be the
+default, but allow use of one of the other mechanisms based on
+local manual configuration, or on configuration obtained
+information obtained from say Router Advertisements.  Of course,
+if routers can distribute the address to use for discovery, then a
+router which does not have multicast routing enabled must not
+distribute a site-scoped multicast address.
+
+The disadvantage with router overrides is that devices must be
+prepared to handle multiple mechanisms, increasing the complexity
+of the implementations.
+
+
+6.  Message Content Mechanisms
+
+6.1.  DHCP
+
+In this mechanism, the messages sent to DNS servers are DHCP-
+format messages, and the DNS servers send DHCP messages in
+response.
+
+The domain name can be obtained by having the DNS server include a
+Domain Name option in the response.  A DHCP option to obtain a
+domain search path [DOMSEARCH] is currently being discussed in the
+DHC WG.  Without this option, the search path behavior would be no
+different from the behavior today, where the search path is simply
+computed based on the domain name obtained.  A list of DNS servers
+would also require a new DHCP option, which is already required if
+DHCP for IPv6 is to be implemented.
+
+
+
+
+
+
+Expires January 2002                                     [Page 21]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+6.1.1.  Evaluation
+
+Scalability
+   Only one round trip of messages is required, and there is no
+   need to run any additional servers.  In other respects, this
+   mechanism has the same scalability properties as the underlying
+   transport mechanism chosen.
+
+
+Security
+   A means of securing DHCP content that does not rely on IPsec
+   has been proposed in the DHC Working Group [DHCPAUTH].
+
+
+Time to Deploy
+   This would require time to implement a DHCP parser in DNS
+   servers.  In addition, DHCP for IPv6 is still being defined by
+   the DHC Working Group.
+
+
+Business Motivation
+   Devices wanting to resolve names probably already have to
+   implement a DHCP parser and be able to obtain DNS-related
+   configuration information using DHCP messages.  As a result, it
+   is expected that little extra work would be required by stack
+   implementers beyond implementing DHCPv6.
+
+
+Standardization
+   The DHCP for IPv6 content format is still being defined by the
+   DHC Working Group.
+
+
+Fate Sharing
+   Good fate sharing would require that DNS servers also implement
+   a DHCP parser.  Otherwise, it is necessary to run a DHCP
+   service on the DNS servers which simply responds to requests
+   for DNS information.  In such a configuration, an additional
+   dependency on the DHCP service would be introduced by this
+   mechanism.
+
+
+Convergence Time
+   This mechanism has the same convergence time as the underlying
+   transport mechanism chosen.
+
+
+
+
+
+Expires January 2002                                     [Page 22]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+Scenarios
+   This mechanism works in the same scenarios as the underlying
+   transport mechanism chosen.
+
+
+6.2.  DNS
+
+DNS itself can be used, as long as the transport mechanism ensures
+that discovery messages reach DNS servers, to obtain the DNS
+server list, default domain name, and domain search path.
+
+DNS has many record types that could be used.  For example, SOA
+and NS records contain relevant information.  However, the name
+resolution configuration information which an administrator
+desires that a host should use may not match the usual
+configuration of the DNS server (e.g., might use a different
+domain name).  Hence, using information encoded in separate
+records is more flexible.  It is also desirable that an
+administrator can give different configuration information to
+hosts in different subnets, since this capability exists when a
+DHCP server is present.
+
+There are many ways to accomplish the above.  On the query side,
+the subnet prefix can be encoded in the hostname part of the
+query.  On the response side, the server list, domain name, and
+search path can be encoded in the response, potentially using SRV
+records [SRV] with a special encoding, or using TXT records [TXT],
+or even defining a new record type.
+
+
+
+6.2.1.  Evaluation
+
+Scalability
+   The mechanism has one round trip to the DNS server and the
+   security overhead.  Using Secret Keys, if possible, will
+   produce no more packets, but some processing on the DNS server
+   to match the clients secret key using [TSIG].  Using Diffie-
+   Hellman with [DNSSEC], if many clients attempt this at the same
+   time will put extreme processing demands on the DNS server.
+   But it is doubtful that one or a few DNS Servers will handle
+   1000's of clients.  See Security Evaluation below.
+
+Security
+   If the client can preconfigure a well known private or public
+
+
+
+
+
+Expires January 2002                                     [Page 23]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   key then TSIG or DNSSEC can be used with the same packets
+   presented for the query.  If this is not the case, then either
+   TSIG keys will have to be negotiated using [TKEY] or a Diffie-
+   Hellman Key [DIFFSEC] exchange will have to take place using
+   DNSSEC.  After the client has the proper key then the query can
+   be performed.
+
+Time to Deploy
+   This mechanism can be deployed now.  If the address provided to
+   the Client is an Anycast address then resolver implementations
+   would have to not use the present mechanisms to verify the
+   source address of a QUERY response is equivalent to the
+   destination address of the QUERY to the DNS Server.  Likewise
+   for Multicast DNS.
+
+Business Motivation
+   All DNS suppliers are now implementing TSIG and DNSSEC.  The
+   biggest business motivation for this mechanism is that it
+   requires the least new code of any of the mechanisms evaluated,
+   and provides the greatest robustness since there are no
+   dependencies on other protocols or services.
+
+Standardization
+   If SRV or TXT records are used, there is no standardization
+   required other than the specific mechanism document in the IPv6
+   Working Group.  If a new record type is required, the DNSEXT
+   Working Group would be involved.
+
+Fate Sharing
+   There are no dependencies on other than the normal DNS
+   processes implemented today, nor are there any new dependencies
+   created from these content messages.
+
+Convergence Time
+   There is no degradation in convergence time with this content
+   set of messages, other than awaiting for a failed network to
+   respond again or a DNS Server(s) to come back up after reboot.
+   Once the resolver has done the DNS queries the knowledge from
+   the server on most implementations becomes stateful and stored
+   to non-volatile storage.  In the case of embedded systems with
+   no non-volatile storage the DNS Server address would have to be
+   relearned.
+
+Scenarios
+   This mechanism should work in all scenarios discussed.
+
+
+
+
+
+Expires January 2002                                     [Page 24]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+6.3.  Node Information Query
+
+ICMPv6 node information query [NODEINFO] provides a way to query
+IPv6 addresses assigned to a machine.  This could be used to query
+IPv6 unicast address for a DNS server, from a DNS server IPv6
+anycast/multicast address.
+
+To get a local domain name and search path, new query types
+(QTypes) would need to be defined for these information types.
+
+6.3.1.  Evaluation
+
+Scalability
+   As ICMPv6 node information query will be handled by the DNS
+   server node itself, there is no need for running an additional
+   server.  This mechanism has the same scalability properties as
+   the underlying transport mechanism chosen.
+
+
+Security
+   IPsec is the only way to prevent malicious packets.  It depends
+   on the actual transport protocol used with ICMPv6 node
+   information query, if IPsec is usable or not.  For example, it
+   is rather hard to use IPsec with anycast/multicast, so IPsec
+   may not work well if we use anycast/multicast.
+
+
+Time to Deploy
+   While there exist some implementations of node information
+   queries, implementation is not ubiquitous.
+
+
+Business Motivation
+   There does not seem to be any strong business motivation for
+   implementing a node information query parser, in preference to
+   other options.
+
+
+Standardization
+   The ICMPv6 node information query has not made it to RFC status
+   yet, but is owned by the IPv6 Working Group.
+
+
+Fate Sharing
+   Depends on how we combine this with other mechanisms, and
+
+
+
+
+
+Expires January 2002                                     [Page 25]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   transport protocols.
+
+
+Convergence Time
+   Depends on how we combine this with other mechanisms, and
+   transport protocols.
+
+
+Scenarios
+   This mechanism should work in all scenarios in which the
+   transport mechanism works.
+
+
+6.4.  RA Extensions
+
+The basic approach is to define a new ND option that would contain
+the DNS information.  Existing ND transport mechanisms (i.e.,
+advertisements and solicitations) mechanisms would be used.  This
+would work in the same way that nodes learn about routers and
+prefixes, etc.
+
+A ND new option would be defined that routers could send in router
+advertisements.
+
+
+This approach has two modes of operation.  The first is routers
+periodically send the DNS Configuration Option in their periodic
+router advertisements.
+
+The second mode is that nodes needing DNS information can send a
+solicitation to the routers on the link requesting the DNS
+Configuration options.
+
+This approach has an issue that the DNS information needs to be
+configured in the routers doing the advertisements.  There are
+several approaches to this:
+
+
+a) Many routers may already have most of this information
+   configured.  Routers also function as hosts and may have DNS
+   server addresses, default domain, and list of domains to search
+   in their configuration file.  For example, Cisco IOS [IOS] has
+   the following commands:
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 26]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   ip domain-name name
+      Define a default domain name that the Cisco IOS software
+      will use to complete unqualified host names.
+
+
+   ip domain-list name
+      Define a list of default domain names to complete
+      unqualified host names.
+
+
+   ip name-server server-addr1 [server-addr2...server-addr6]
+      Specify one or more hosts that supply name information.
+
+   At least in the case of Cisco routers, and probably most
+   others, no additional work is needed to add the DNS information
+   to the routers.
+
+
+b) The next approach, that is consistent with current router
+   management practice, is to configure the router manually with
+   the DNS information that they would advertise w/ IPv6 ND.  This
+   could be done by CLI commands as shown above and/or by other
+   mechanisms normally used to configure routers (e.g., web
+   interfaces, proprietary tools, etc.)
+
+   The work to implement this is minor and part of implementation
+   the feature in the router.  No new management/distribution
+   protocols.
+
+
+c) The next approach, also consistent with current router
+   management practice, is that the router configuration files are
+   created centrally and remotely installed on the router.  This
+   is done today with a mix to special tools, text editors, pearl
+   scripts, vendor management systems, etc.  It is very common
+   practice to create files of CLI commands and push them to the
+   routers.  No new management and/or distribution protocols are
+   required.
+
+
+d) Create or extend an SNMP MIB (do we have an ND MIB?) that
+   contains this information and use existing management tools to
+   set the information in the router.  Also common practice and no
+   new management/distribution protocols.  A MIB is required and
+   extensions to management tools to support the new variables.
+
+
+
+
+
+Expires January 2002                                     [Page 27]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+e) Extend Router Renumbering (RR) to contain this information and
+   use it to advertise it to the routers.  This is mostly
+   consistent with what RR does and allows control reasonable fine
+   grained control of to allow different information per router or
+   even per interface.
+
+Without changing the intended usage of Router Advertisements, the
+natural transport mechanism used would be Link-scoped multicast
+with router-only response.
+
+
+6.4.1.  Evaluation
+
+Scalability
+   This mechanism has excellent scalability properties.  It scales
+   as well as ND and DNS does currently.  All of the multicast
+   traffic is local to the link. The periodic advertisement rates
+   can be tuned to environment including turn it off completely
+   and relying on the solicitation/advertisement mode.
+
+
+Security
+   ND does not currently have authentication mechanisms built in,
+   but there is ongoing work to investigate using AH with ND.
+   This approach would use what ever solution is selected for ND
+   authentication.
+
+
+Time to Deploy
+   This approach requires implementation in nodes wishing to learn
+   DNS information and in routers to provide the information.  The
+   router will need to be configured with the DNS information
+   needed in the advertisements.
+
+   It is a relatively minor amount of work to add a new option to
+   an existing router and/or node implementations of ND.  It
+   should be possible to deploy it quickly once the details are
+   scoped out and the implementations are developed.  There is no
+   new network wide services such as multicast or anycast that
+   need to be deployed.  There are no dependencies with other
+   protocols.
+
+
+Business Motivation
+   The business motivation is very good.  The implementation,
+
+
+
+
+
+Expires January 2002                                     [Page 28]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   documentation, and support cost are minor and very much in line
+   with existing ND features.  There are no new protocols and/or
+   transports to deploy, document, and support.
+
+   Devices wanting to discover DNS servers already have to have an
+   RA parser in them.  It is expected that implementors would find
+   it easier to extend an existing parser than to add a new
+   parser.
+
+
+Standardization
+   This mechanism would require a new RA option format to be
+   standardized.  This would be done by the IPv6 Working Group.
+
+
+Fate Sharing
+   The only fate sharing issue raised is that it ties the
+   discovery of DNS information with the operation of routers on a
+   link.  This is very similar to the common practice with IPv4 of
+   using Bootp relays in routers to communicate with DHCP servers,
+   so in practical terms the issue is very small.
+
+   No changes are made to DNS servers or way nodes communicate
+   with DNS servers.
+
+
+Convergence Time
+   Convergence time is similar to current IPv4 DNS operation using
+   DHCP for DNS discovery. No new convergence issues are created.
+   If one of a set of DNS servers is unavailable (e.g., down,
+   isolated, etc.), then normal DNS recover mechanisms will select
+   an alternative DNS servers.
+
+   If one of a set of routers is unavailable, other routers on the
+   link will continue providing the DNS information.
+
+   If the last DNS server is unavailable, then it is down.  If the
+   last router is unavailable, then new nodes will not be able to
+   learn DNS information or reach any DNS server through the
+   router.
+
+
+Scenarios
+   This mechanism works over a broad range of scenarios.  It
+   should work as well on links that are high performance (e.g.,
+
+
+
+
+
+Expires January 2002                                     [Page 29]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   LANs) and low performance (e.g., wireless).
+
+   However, this mechanism relies on routers and does not support
+   DNS servers on isolated links.  Other local DNS server
+   discovery mechanisms (e.g., multicast DNS) would be needed.
+   This approach is believed to be compatible with multicast DNS
+   approach being developed in the IETF.
+
+   It can be used in either a periodic multicast advertisement, or
+   a solicitation/advertisement mode.
+
+
+6.5.  SLP
+
+The Service Location Protocol [RFC 2608] provides a general
+framework for service discovery.  Services are modeled on the
+basis of their type, location, and a set of attributes.
+
+Clients use SLP to request services on the basis of the attributes
+required and retrieve both the location and attributes of all
+services fulfilling the request.  In the case of DNS server
+discovery, a DNS client could discover the location, domain name
+and search path to use, all in one message round trip
+(SrvRqst/SrvRply) if the Attribute List Extension is used, or two
+round trips (SrvRqst/SrvRply, AttrRqst/AttrRply) if the Attribute
+List extension is not supported.
+
+Without changing the basic SLPv2 protocol, the natural transport
+mechanism used would be Site-scoped multicast.
+
+
+6.5.1.  Evaluation
+
+Scalability
+
+   This mechanism has the same scalability properties as the
+   underlying transport mechanism chosen.
+
+
+Security
+   SLPv2 provides its own security so that those who obtain
+   service location and attribute information can verify the
+   signature over it.  These digital signatures are calculated
+   using keys which are distributed by some external mechanism
+   (SLPv2 does not provide mechanisms for cryptographic key
+
+
+
+
+
+Expires January 2002                                     [Page 30]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   distribution).
+
+
+Time to Deploy
+   SLPv2 for IPv6 is not yet a proposed standard.  It will shortly
+   enter IETF last call.
+
+   There are no IPv6 SLPv2 implementations yet.  SLPv2 over IPv4
+   has been implemented by many vendors and is used for a variety
+   of purposes.
+
+
+Business Motivation
+   Rather than each protocol supplying its own service discovery
+   protocol, SLP can provide a general purpose mechanism which
+   will minimize the software required and allow for common
+   operational considerations and management.
+
+
+Standardization
+   SLPv2 is a Proposed Standard.  SLPv2 over IPv6 and the
+   Attribute List Extension are both about to enter IETF last call
+   before being advanced to Proposed Standard.
+
+
+Fate Sharing
+   SLP would require an additional protocol to be used to
+   configure DNS resolvers - namely, a SLP user agent library.
+   DNS servers would need to be advertised using a SLP service
+   agent - this functionality could be provided by a library
+   invoked by a DNS server, or by an additional service running on
+   the DNS server host (although this is more complicated and less
+   assured of not advertising the DNS server when it is in fact
+   not available).
+
+
+Convergence Time
+   If no directory agents are deployed, convergence time is on the
+   order of milliseconds:  the only way that a DNS resolver could
+   discover a DNS server which was not available would be if the
+   DNS server failed after answering that it was available.
+
+   If directory agents are available, convergence depends on the
+   soft state registration lifetime - which could be of any
+   granularity on the order of seconds - but typically is on the
+
+
+
+
+
+Expires January 2002                                     [Page 31]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   order of minutes.  During this interval it is possible for a
+   client to discover a service which has gone off line since the
+   service location has been cached by a directory agent
+   temporarily.
+
+
+Scenarios
+
+   o  Isolated link with a DNS server but no routers
+
+      SLP requests multicast on the link would enable DNS clients
+      to directly discover DNS servers, domain name and search
+      path.
+
+      The DNS clients and servers would have to make use of a SLP
+      library to accomplish this.  Another alternative is a
+      service advertising process co-resident on the DNS server
+      host which advertises the DNS server on its behalf.  In this
+      case, no modification of the DNS server would be necessary.
+
+
+   o  Site with routers, but no multicast routing enabled
+
+      Routers use SLP to discover DNS servers on attached links.
+      The routers can then use other mechanisms to distribute the
+      location of the DNS servers (add an anycast routing entry
+      for each DNS server, send extensions to routing
+      advertisements, etc.)
+
+      DNS clients could use link-scoped multicast SLP discovery,
+      and routers could answer these requests on behalf of DNS
+      servers.  The problem with this approach is that it does not
+      specify the way in which DNS server locations are propagated
+      between routers.
+
+      Thus, SLP can be used as a mechanism to provide dynamic and
+      decentralized service discovery for the system, but only
+      between the routers and the DNS servers.  The mechanism
+      between the routers to propagate DNS service locations would
+      have to be satisfied by some additional protocol (such as
+      OSPF extensions).
+
+      In summary, a link-scoped multicast with router-assist
+      transport mechanism would be needed in this scenario.
+
+
+
+
+
+
+Expires January 2002                                     [Page 32]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+   o  NBMA Link
+
+      This scenario could not be supported without changing the
+      SLP protocol to work with anycast addresses.  However, it is
+      not expected that this is a very important scenario.
+
+
+6.6.  Something New
+
+Any number of other mechanisms (e.g., HTTP, SNMP, etc.)  could
+also be extended, but it is expected that any other mechanism
+would take at least as long to deploy, and have no significant
+advantage over the other mechanisms evaluated above.
+
+
+7.  Recommendations
+
+Based on team discussion, and WG consensus at IETF 49, the
+recommendation for transport mechanism is to use site-scoped
+anycast.  That is, IANA should allocate a well-known site-local
+anycast address for DNS servers.
+
+No specific recommendation is made regarding using anycast for
+discovery-only or for actual name resolution.  However, we observe
+that choice can be made by individual sites as follows.  Nodes
+will use the anycast address to discover DNS-specific information
+such as the domain name, search path, and DNS server list.  If the
+DNS server list contains just the anycast address itself, the
+anycast address will also be used for name resolution.
+
+Based on subsequent team discussion, the recommendation to the WG
+regarding the content mechanism is to use DNS.  That is, the
+recommendation is that the WG should define the details of how the
+DNS server list, domain name, and search path, can be encoded in
+DNS records.  The team's initial recommendation is that the IPv6
+WG investigate whether SRV records are sufficient, and if not,
+then either TXT records or a new record type should be used.  It
+is believed that the information should and can be encoded in a
+single response message.
+
+Finally, it is recommended that the "Other stateful configuration"
+flag in the Router Advertisement be used to control whether to use
+DHCP or this mechanism.  That is, the analysis and recommendations
+in this document apply only to links where the "Other stateful
+configuration" flag is zero.
+
+
+
+
+
+Expires January 2002                                     [Page 33]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+8.  Appendix A: Summary Grid
+
+Figure 1 summarizes information on transport mechanisms:
+
+                 |Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM
+-----------------+---------+--------+---------+---------+---------
+SW upgrades      |-/S/SR   |-/S/SR  |R        |R        |UR
+-----------------+---------+--------+---------+---------+---------
+Reconfig changes |S        |-       |R        |S        |-
+-----------------+---------+--------+---------+---------+---------
+New dependencies |-        |-       |router,  |linkmcast|multicast
+                 |         |        |linkmcast|         |routing,
+                 |         |        |         |         |linkmcast
+-----------------+---------+--------+---------+---------+---------
+Convergence time |fast     |per-rtg |fast     |fast     |fast
+-----------------+---------+--------+---------+---------+---------
+Can use IKE      |no       |no      |no       |no       |no
+-----------------+---------+--------+---------+---------+---------
+Standards work   |-/ipngwg |-/ipngwg|ipngwg   |ipngwg   |-
+-----------------+---------+--------+---------+---------+---------
+Deployable "now" |yes      |yes     |no       |no       |no
+-----------------+---------+--------+---------+---------+---------
+
+              Figure 1: Transport Mechanism Summary
+
+Key:
+ / separates multiple deployment options
+ - = No devices
+ S = All DNS servers
+SR = All routers with directly-connected DNS servers
+UR = All routers which don't have multicast routing implemented
+ R = All routers
+
+SW upgrades = what boxes, other than devices wanting to discover
+DNS servers, require software upgrades?
+
+Reconfig changes = what boxes need to be reconfigured when the set
+of DNS servers changes?
+
+New dependencies = what new dependencies are added?
+
+Convergence Time = how long does it take to contact a new DNS
+server when a server/link/router fails?  "Fast" = a device can
+immediately use an alternate server if reachable.  "Per-rtg" =
+Device must wait until routing converges for the unreachable
+
+
+
+
+
+Expires January 2002                                     [Page 34]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+address.
+
+Can use IKE = can IKE be used for key negotiation?
+
+Standards work = what WGs would be required to standardize new
+items?
+
+Deployable "now" = could a new client using this mechanism be
+deployed immediately, without requiring implementation of new code
+for routers or servers?
+
+Figure 2 summarizes information on content mechanisms:
+
+                  |DHCP      |DNS      |NIQ      |RA       |SLP
+------------------+----------+---------+---------+---------+---------
+Round trips used  |1         |1        |1        |1        |1
+------------------+----------+---------+---------+---------+---------
+Has own signatures|yes       |yes      |-        |no       |yes
+------------------+----------+---------+---------+---------+---------
+Has own key dist  |-         |yes      |-        |-        |-
+------------------+----------+---------+---------+---------+---------
+Standards work    |dhc       |dnsext?  |ipngwg   |ipngwg   |svrloc
+------------------+----------+---------+---------+---------+---------
+Need addl parser  |in servers|-        |yes      |-        |yes
+------------------+----------+---------+---------+---------+---------
+Generalizable     |yes       |yes      |yes      |-        |yes
+------------------+----------+---------+---------+---------+---------
+Deployable "now"  |no        |yes      |no       |no       |no
+------------------+----------+---------+---------+---------+---------
+
+               Figure 2: Content Mechanism Summary
+
+Round trips used = How many round trips are required?
+
+Has own signatures? = Does the content have its own signature
+facility?  (a "no" means it relies on IPsec)
+
+Standards work = what WGs would be required to standardize new
+items?
+
+Need addl parser = besides any parsers that a device must already
+implement to perform basic name resolution, does the mechanism
+introduce a requirement for another parser?
+
+Generalizable = can the mechanism be generalized to allow
+
+
+
+
+
+Expires January 2002                                     [Page 35]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+discovery of other types of information or services?
+
+Deployable "now" = could a new client using this mechanism be
+deployed immediately, without requiring implementation of new code
+for routers or servers?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 36]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+9.  Authors' Addresses
+
+     Bernard Aboba
+     Microsoft
+     One Microsoft Way
+     Redmond, WA 98052, USA
+     Email: aboba@internaut.com
+
+     Jim Bound
+     Compaq Computer Corporation
+     110 Spitbrook Road ZK3-3/U14
+     Nashua, NH 03062-2698
+     Email: bound@zk3.dec.com
+
+     Steve Deering
+     Cisco Systems, Inc.
+     170 West Tasman Drive
+     San Jose, CA 95134-1706, USA
+     Email: deering@cisco.com
+
+     Erik Guttman
+     Sun Microsystems
+     Bahnstr. 2
+     74915 Waibstadt, Germany
+     Email: erik.guttman@sun.com
+
+     Jun-ichiro itojun HAGINO
+     Research Laboratory, Internet Initiative Japan Inc.
+     Takebashi Yasuda Bldg.,
+     3-13 Kanda Nishiki-cho,
+     Chiyoda-ku, Tokyo 101-0054, JAPAN
+     Email: itojun@iijlab.net
+
+     Robert M. Hinden
+     Nokia
+     313 Fairchild Drive
+     Mountain View, CA 94043, USA
+     Email: hinden@iprg.nokia.com
+
+     Tatuya JINMEI
+     Research and Development Center, Toshiba Corporation
+     1 Komukai Toshiba-cho, Kawasaki-chi
+     Kanagawa 212-8582
+     Japan
+     Email: jinmei@isl.rdc.toshiba.co.jp
+
+
+
+
+
+Expires January 2002                                     [Page 37]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+     Atsushi Onoe
+     Internet Systems Laboratory, IN Laboratories, Sony Corporation
+     6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001
+     Japan
+     Email: onoe@sm.sony.co.jp
+
+     Hesham Soliman
+     Ericsson Australia
+     61 Rigall St., Broadmeadows
+     Melbourne, Victoria 3047
+     Australia
+     Email: Hesham.Soliman@ericsson.com.au
+
+     David Thaler
+     Microsoft
+     One Microsoft Way
+     Redmond, WA 98052, USA
+     Email: dthaler@microsoft.com
+
+
+10.  References
+
+[ANYCAST]
+     Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+     Service", RFC 1546, November 1993.
+
+[ADDRARCH]
+     Hinden, R., and S. Deering, "IP Version 6 Addressing
+     Architecture", RFC 2373, July 1998.
+
+[DHCPAUTH]
+     Droms, R., and W. Arbaugh, "Authentication for DHCP
+     Messages", draft-ietf-dhc-authentication-16.txt, January
+     2001.
+
+[DIFFSEC]
+     D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
+     Name System (DNS)", RFC 2539, March 1999.
+
+[DNSSEC]
+     D. Eastlake, "Domain Name System Security Extensions", RFC
+     2535, March 1999.
+
+[DOMSEARCH]
+     B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc-
+
+
+
+
+
+Expires January 2002                                     [Page 38]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+     domsearch-01.txt, December 2000.
+
+[HOST-ANYCAST]
+     Haberman, B., and D. Thaler, "Host-based Anycast using MLD",
+     draft-haberman-ipngwg-host-anycast-00.txt, February 2001.
+
+[IOS]
+     Cisco IOS Release 12.0 Configuration Guides,
+     http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/cbkixol.htm
+
+[ITOJUN-ANYCAST]
+     Jun-ichiro Hagino and K. Ettikan, "An analysis of IPv6
+     anycast", draft-itojun-ipv6-anycast-analysis-02.txt, February
+     2001.
+
+[MDNS]
+     Esibov, L., Aboba, B., and D. Thaler, "Multicast DNS", draft-
+     ietf-dnsext-mdns-00.txt, November 2000.
+
+[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+     for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+[NODEINFO]
+     Matt Crawford, "IPv6 Node Information Queries", draft-ietf-
+     ipngwg-icmp-name-lookups-07.txt, August 2000.
+
+[RFC1034]
+     P. Mockapetris, "Domain Names - Concepts and Facilities", STD
+     13, RFC 1034, November 1987.
+
+[RFC1035]
+     P. Mockapetris, "Domain Names - Implementation and
+     Specifications", STD 13, RFC 1035, November 1987.
+
+[RIPMD5]
+     Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC
+     2082, January 1997.
+
+[RIPNG]
+     Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
+     January 1997.
+
+[SLPv2]
+     Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
+     Location Protocol, Version 2", RFC 2608, June 1999.
+
+
+
+
+
+Expires January 2002                                     [Page 39]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+[SRV]
+     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+     specifying the location of services (DNS SRV)", RFC 2782,
+     February 2000.
+
+[TSIG]
+     Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+     "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+     2845, May 2000.
+
+[TKEY]
+     D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC
+     2930, September 2000
+
+[TXT]
+     R. Rosenbaum, "Using the Domain Name System To Store
+     Arbitrary String Attributes", RFC 1464, May 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 40]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+11.  Full Copyright Statement
+
+Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished
+to others, and derivative works that comment on or otherwise
+explain it or assist in its implementation may be prepared,
+copied, published and distributed, in whole or in part, without
+restriction of any kind, provided that the above copyright notice
+and this paragraph are included on all such copies and derivative
+works.  However, this document itself may not be modified in any
+way, such as by removing the copyright notice or references to the
+Internet Society or other Internet organizations, except as needed
+for the purpose of developing Internet standards in which case the
+procedures for copyrights defined in the Internet Standards
+process must be followed, or as required to translate it into
+languages other than English.
+
+The limited permissions granted above are perpetual and will not
+be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on
+an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 41]
+
+
+
+
+
+Draft                       DDDT Report               January 2002
+
+
+
+Table of Contents
+
+
+1 Introduction ..............................................    2
+2 Requirements ..............................................    2
+3 Criteria for Evaluation ...................................    3
+4 Taxonomy ..................................................    4
+5 Transport Mechanisms ......................................    4
+5.1 Anycast for DNS server discovery only ...................    4
+5.1.1 Evaluation ............................................    7
+5.2 Anycast for name resolution .............................    9
+5.2.1 Configuration .........................................   10
+5.2.2 Actual use ............................................   10
+5.2.3 Evaluation ............................................   10
+5.3 Link-scoped multicast with router-only responses ........   13
+5.3.1 Evaluation ............................................   13
+5.4 Link-scoped multicast (with router assist) ..............   16
+5.4.1 Evaluation ............................................   16
+5.5 Site-scoped multicast ...................................   17
+5.5.1 Evaluation ............................................   19
+5.6 Hybrid ..................................................   21
+6 Message Content Mechanisms ................................   21
+6.1 DHCP ....................................................   21
+6.1.1 Evaluation ............................................   22
+6.2 DNS .....................................................   23
+6.2.1 Evaluation ............................................   23
+6.3 Node Information Query ..................................   25
+6.3.1 Evaluation ............................................   25
+6.4 RA Extensions ...........................................   26
+6.4.1 Evaluation ............................................   28
+6.5 SLP .....................................................   30
+6.5.1 Evaluation ............................................   30
+6.6 Something New ...........................................   33
+7 Recommendations ...........................................   33
+8 Appendix A: Summary Grid ..................................   34
+9 Authors' Addresses ........................................   37
+10 References ...............................................   38
+11 Full Copyright Statement .................................   41
+
+
+
+
+
+
+
+
+
+
+
+Expires January 2002                                     [Page 42]
+
diff --git a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-00.txt b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-00.txt
new file mode 100644
index 00000000..a5e21f9e
--- /dev/null
+++ b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-00.txt
@@ -0,0 +1,291 @@
+INTERNET-DRAFT									3rd October 2000    
+      									   Expires: 3rd April 2001
+
+   Mail transfer reliability in Simple Mail Tranfer Protocol(SMTP)
+          draft-khanna-smtp-mail-transfer-reliability-00.txt
+                       Kumar Gaurav Khanna
+
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups. Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and maybe updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
+
+
+Abstract
+
+This draft discusses the issue which makes the data tranfer in SMTP 
+protocol highly vulnerable to a "resend" in case of a network 
+disruption. We then discuss a means by which such a "resend" can be 
+avoided, by tranferring mail data only from the point of disruption.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires: 3rd April, 2001									[Page 1]
+
+
+INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
+
+1. Introduction
+
+So tell me, how many times has it happened that when you were sending a 
+lengthy mail, then due to network disruption (either due to the dialup 
+connection breaking up, or the network timing out, or for some reason 
+which I forgot to mention here!), your mail transfer was forced to come 
+to an abrupt halt ??? You, then, had to send it all over again, and 
+transfer would be successful only if the lady luck be with you. Else, 
+the irony repeats itself.
+
+The problem, that incase of a failed mail tranfer you have to send the 
+mail all over again, resending what you had sent earlier, is due to the 
+nature of the SMTP protocol. This draft is aimed at discussing why and 
+how this problem occurs, and also suggests a solution which can help 
+solve it effectively.
+
+2. The Problem
+
+To understand why we have to resend a mail entirely incase of 
+disruption while sending it previously, lets look at a simple SMTP
+conversation between a SMTP client (C) and a SMTP server (S):
+
+<Server waits for an incoming connection...>
+<Client connects to the SMTP server...>
+
+S: 220 SMTP service ready
+C: Helo mydomain.com
+S: 250 Pleased to meet you
+C: MAIL FROM: <gauravkhanna@mailandnews.com>
+S: 250 sender okay
+C: RCPT TO: <prabhakhanna@yahoo.com>
+S: 250 Recipient okay
+C: Data
+S: 354 send data with <CRLF>.<CRLF> to end
+
+<Client sends the mail here. The mail is comprised of all the standard 
+SMTP headers, including the X- headers, and any attachments. Finally, 
+the termination period is sent.>
+
+S: 250 message accepted for delivery
+C: QUIT
+S: 221 Transmission channel closed
+
+That's how the most basic of SMTP conversations are held. Note that 
+after the DATA command, when the client is sending the mail, the entire 
+mail is sent as one big chunk!! Now suppose, that while sending that  
+chunk, the connection breaks up for some reason. Bingo! The SMTP 
+server closes the transmission channel (it gets to know that connection 
+has broken up, so it cleans up its resource usage), and the SMTP client 
+is left with no option but to resend the entire mail. Infact, this 
+entire conversation has to occur again!! Consider the amount of 
+bandwidth going waste, let alone time.
+
+Expires: 3rd April, 2001									[Page 2]
+
+INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
+
+3. The Solution
+
+This draft suggests a mechanism by introducing few additional commands
+in the SMTP protocol, which can help overcome this problem. So, lets
+look at it...
+
+The philosophy behind the solution to the above problem is to divide
+the chunk to be sent by the SMTP client, after the DATA command, be
+divided in blocks of size, say N. 
+
+Next, during the course of a SMTP conversation, instead of sending a
+DATA command, the SMTP client sends the (new) DB command. The syntax
+of the command is:
+
+DB <N>
+
+Its purpose is to tell the SMTP server that the mail shall now be
+delivered in small(er) blocks of size N. This block size is decided
+by the client. If the server doesn't accept the command, it returns
+421 error code. However, if the server accepts this command, it saves
+the block size and returns...
+
+250 <mesg ID>
+
+where <mesg ID> is a unique number produced by the SMTP server to 
+uniquely identify this mail transaction. This ID is saved both by the
+SMTP server and the SMTP client.
+
+After the acceptence of the DB command by the SMTP server, the SMTP
+client sends the first block of the mail to the server, which 
+maintains an internal count (CNT) of the number of mail blocks 
+successfully transferred from the client to the server. After 
+receiving each block successfully, the server increments CNT and 
+sends a 250 success code. The client continues to send the blocks
+of mail in this manner to server. The server should make sure that the 
+block sent by the client is not more than N bytes, as decided. It can, 
+however, be less than N. 
+
+The termination of the blocks is indicated by the SMTP client by sending 
+the <CRLF>.<CRLF>, as done conventionally. The server responds with a 
+successful 250 code, after which the client can issue the QUIT command 
+and proceed normally. After a successful QUIT, both the server and
+client discard the block size N and the <mesg ID>. The server, in
+addition, discards the CNT. Here's a sample conversation illustrating 
+this concept between the SMTP client (C) and the SMTP Server (S)...
+
+<Server waits for an incoming connection>
+<Client connects to the SMTP server>
+
+S: 220 SMTP Server Ready
+C: Helo mydomain.com
+S: 250 Pleased to meet you
+C: MAIL FROM: <gauravkhanna@mailandnews.com>
+
+Expires: 3rd April, 2001									[Page 3]
+
+INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt Oct,2K
+
+S: 250 Sender okay
+C: RCPT TO: <prabhakhanna@yahoo.com>
+S: 250 Recipient okay
+C: DB 100
+S: 250 20001003152543
+
+<Assume that the mail is 450 bytes in length>
+
+C: <send the 1st block of 100 bytes>
+S: 250 block 1 accepted
+C: <send the 2nd block of 100 bytes>
+S: 250 block 2 accepted
+C: <send the 3rd block of 100 bytes>
+S: 250 block 3 accepted
+C: <send the 4th block of 100 bytes>
+S: 250 block 4 accepted
+C: <send the 5th block of 50 bytes>
+S: 250 block 5 accepted
+C: <CRLF>.<CRLF>
+S: 250 message accepted for delivery
+C: QUIT
+S: 221 Transmission channel closed
+
+As evident from above, the server maintains an internal count of the 
+number of blocks transmitted. after a successful QUIT, the server
+can work upon the mail as it does normally, either by queueing it, or
+asking a Message Transfer Agent (MTA) to work on it.
+
+Now, for example, while the 4th block was being transmitted, the network 
+got disrupted and the connection broke up. In such a case, the server 
+shall save the partial mail sent to it by the client, for some defined 
+period of time (after which it may discard it), indentifying it with its 
+<mesg ID>. The client shall re-establish a connection with the SMTP 
+server and, instead of HELO, shall give the RESEND command whose syntax 
+is:
+
+RESEND <mesg ID>
+
+where <mesg ID> is the unique identifier which the server returned to
+the client, in reply to the DB command. If there is partial mail saved 
+by the server, whose <mesg ID> matches the one sent by the SMTP client
+in the RESEND command, then the server shall read the partial mail in
+the memory and proceed ahead to complete the interrupted transmission
+by sending the block size (N) and the number of blocks already sent by
+the SMTP client as part of 250 response code. Else, it shall send a 421
+error code.
+
+In the conversation above, if the connection broke up during the sending 
+of the 4th block, the SMTP server saves the <mesg ID>, the block size N 
+and the number of blocks which have already been sent by the SMTP 
+client. The SMTP client also, upon connection breakup, saves the 
+<mesg ID>. It then proceeds to resend the mail as follows (C=> SMTP
+Client, S=> SMTP Server) :
+
+Expires: 3rd April, 2001									[Page 4]
+
+INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
+
+<Server waits for an incoming connection>
+<Client connects to the server>
+S: 220 SMTP service ready
+C: RESEND 20001003152543
+S: 250 100 3
+
+<This reply tells the SMTP client that block size is 100 bytes, and
+3 blocks have already been sent.>
+
+C: <sends the 4th block of 100 bytes again>
+S: 250 block 4 accepted
+C: <sends the 5th block of 50 bytes>
+S: 250 block 5 accepted
+C: <CRLF>.<CRLF>
+S: 250 message accepted for delivery
+C: QUIT
+S: 221 Transmission channel closed
+
+As can be seen above, during the "recovery" by the RESEND command, the
+SMTP client doesn't sends the MAIL FROM and RCPT TO commands again as
+they have already been stored by the SMTP server in the partial mail
+that it saves. Also, the SMTP server tells the client the block size
+that was decided, and how many blocks have been sent. This helps the
+SMTP client to send blocks of mail of size N and resume the broken
+transmission from the block where it had got disrupted, thereby saving
+the time and bandwidth involved in resending what had already been sent
+to the SMTP server.
+
+Thus, as we can see, if modified in the manner suggested by this draft,
+the SMTP protocol can inherit good amount of reliability in the 
+transfer of mails, which can help save time and network bandwidth.
+
+5. Author's Address
+
+Kumar Gaurav Khanna,
+#23, TTTI Campus,
+Sector 26,
+Chandigarh - 160 019
+India
+Phone: 91-172-773454
+WWW: http://www.wintools.f2s.com/
+Email: gauravkhanna@mailandnews.com
+       gaurav@wintools.f2s.com
+
+
+
+
+
+
+
+
+
+
+
+Expires: 3rd April, 2001									[Page 5]