Skip to main content

Note on protocol synch sequences
RFC 529

Document Type RFC - Unknown (June 1973)
Authors
Last updated 2013-03-02
RFC stream Legacy stream
Formats
IESG Responsible AD (None)
Send notices to (None)
RFC 529
Global Routing Operations                                       J. Mauch
Internet-Draft                                               J. Snijders
Intended status: Standards Track                                     NTT
Expires: May 4, 2017                                          G. Hankins
                                                                   Nokia
                                                        October 31, 2016

 Default IPv4 and IPv6 Unicast EBGP Route Propagation Behavior Without
                                Policies
                     draft-ietf-grow-bgp-reject-02

Abstract

   This document defines the default behavior of a BGP speaker when
   there is no import or export policy associated with a BGP session for
   the IPv4 or IPv6 Unicast Address Family.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Mauch, et al.              Expires May 4, 2017                  [Page 1]
Internet-Draft             BGP Default Reject               October 2016

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents" signal.

   For the TELNET protocol the "out of band" signal is the INS of Host-
   Host Protocol and the "in band" marker is the TELNET Data Mark
   character (DM).  Ignoring for the moment the use of TELNET as a basis
   for higher level protocols (such as FTP), the class of characters
   "interesting" to a TELNET interpreter is the set of TELNET commands
   (including the commands for option negotiation and sub-negotiation
   [2]).

   One might reasonably argue that this class could be enlarged by a
   server Host to include the set of signals of interest to the terminal
   support software of that particular Host.  For example, in case of
   TENEX such a set would include the "terminal interrupt" characters
   enabled by the process reading from the TELNET connection (e.g., ^C,
   ^T, etc.).  Other hosts, such as Multics, might look only for the
   TELNET commands, such as Interrupt Process (IP), Abort Output (AO),
   etc.  Whether or not one chooses to consider additional signals as
   interesting during the processing of a TELNET SYNCH sequence should
   cause the implementer no problem:

      He must treat all TELNET commands as interesting by interpreting
      them.  He may choose either to ignore such additional signals or
      to pass them on to the process; in either case there is no
      vagueness since the implementer knows which characters his
      terminal support software considers interesting.

   The difficulty noted in RFC 513 concerning the vagueness of
   "interesting things" occurs when a higher level protocol makes use of
   the TELNET SYNCH sequence to force commands of interest to it through
   to its interpreter.  A higher level protocol designed in such a way
   represents a violation of the protocol layering discipline:

      The TELNET SYNCH mechanism is being misused by attempting to give
      it meaning at two different levels of protocol.

   The problem stems from the fact that, in general, a (increasing)
   number of different higher level protocols can be designed with
   TELNET as a base.  A TELNET interpreter has no way of knowing the
   higher level protocol interpreter (if any) to which it is passing
   characters, and therefore, can not tell which things are
   "interesting" to the higher level protocol interpreter.  That is,
   just as an NCP should not have to know whether the data it handles is

McKenzie, et. al.                                               [Page 2]
RFC 529            A Note on Protocol Synch Sequences       29 June 1973

   for a TELNET connection, an FTP data connection, etc., a TELNET
   interpreter should not be required to know the kind of process for
   which it is handling characters.  This should, in fact, result in a
   simplification of the design and implementation of TELNET protocol
   interpreters.

   This difficulty can be resolved by proper design of protocols that
   make use of TELNET as a base.  In particular, if in such a higher
   level protocol it is important to be able to force commands through
   to the protocol interpreter, the higher level protocol should include
   its own synch sequence:  i.e., an "out of band" signal used with an
   "in band" data mark.  The TELNET protocol provides the Interrupt
   Process character (IP) for use as an "out of band" signal.  A synch
   sequence for a protocol built upon TELNET would be:

      1. Insert the TELNET IP control character into the data stream;

      2. Insert the higher level protocol data mark character (HDM) into
         the data stream following whatever higher level protocol
         commands are important at the time.

   Receipt of the IP TELNET command causes the higher level protocol
   interpreter to be interrupted, enabling it to scan the data stream
   (up to and including the HDM) for commands it considers important.

   As an example, consider the case of the File Transfer Protocol (RFC
   454) and the problem of aborting a file transfer in progress.  To
   accomplish such an abort the FTP user (process) should:

      1. Send the TELNET IP character;

      2. Send the TELNET SYNC sequence, that is:

         a. Send the TELNET Data Mark (DM);

         b. Send the Host-Host Protocol INS;

      3. Send the FTP ABOR command; and

      4. Send the FTP data mark character [3].

   The user (or process acting on his behalf) must transmit the TELNET
   SYNCH sequence of step 2 above to ensure that the TELNET IP gets
   through to the server's TELNET interpreter.

McKenzie, et. al.                                               [Page 3]
RFC 529            A Note on Protocol Synch Sequences       29 June 1973

Endnotes

   [1] I.e., any TELNET commands appearing before the Data Mark are to
   be interpreted; the Data Mark is to be used to terminate the scan
   initiated by the INS; characters that are not TELNET commands may be
   discarded or passed to the user process as the implementer sees fit.

   [2] We support Hathaway's proposal to fully parenthesize sub-
   negotiations.  Further, we believe that the "closing parenthesis"
   should be a new command rather than a second SB command; this will
   aid the receiver in recovering from errors, either in parsing at the
   receiver or in generation at the transmitter.  We disagree with his
   proposal that sub-negotiations be discarded when encountered during
   processing of a TELNET SYNCH.

   [3] For FTP such a data mark character has not yet been defined and,
   in fact, may not be necessary under the constraint that the FTP
   command interpreter should look for exactly one command after being
   interrupted; this is consistent with the general command-reply
   orientation of FTP.

          [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Helene Morin, Via Genie 12/1999]

McKenzie, et. al.                                               [Page 4]