doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc5320.txt b/doc/rfc/rfc5320.txt
new file mode 100644
index 0000000..81e5028
--- /dev/null
+++ b/doc/rfc/rfc5320.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Independent Submission                                   F. Templin, Ed.
+Request for Comments: 5320                  Boeing Research & Technology
+Category: Experimental                                     February 2010
+ISSN: 2070-1721
+
+
+        The Subnetwork Encapsulation and Adaptation Layer (SEAL)
+
+Abstract
+
+   For the purpose of this document, subnetworks are defined as virtual
+   topologies that span connected network regions bounded by
+   encapsulating border nodes.  These virtual topologies may span
+   multiple IP and/or sub-IP layer forwarding hops, and can introduce
+   failure modes due to packet duplication and/or links with diverse
+   Maximum Transmission Units (MTUs).  This document specifies a
+   Subnetwork Encapsulation and Adaptation Layer (SEAL) that
+   accommodates such virtual topologies over diverse underlying link
+   technologies.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5320.
+
+IESG Note
+
+   This RFC is not a candidate for any level of Internet Standard.  The
+   IETF disclaims any knowledge of the fitness of this RFC for any
+   purpose and in particular notes that the decision to publish is not
+   based on IETF review for such things as security, congestion control,
+   or inappropriate interaction with deployed protocols.  The RFC Editor
+   has chosen to publish this document at its discretion.  Readers of
+   this document should exercise caution in evaluating its value for
+   implementation and deployment.  See RFC 3932 for more information.
+
+
+
+Templin                       Experimental                      [Page 1]
+
+RFC 5320                          SEAL                     February 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                      [Page 2]
+
+RFC 5320                          SEAL                     February 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Motivation .................................................4
+      1.2. Approach ...................................................6
+   2. Terminology and Requirements ....................................6
+   3. Applicability Statement .........................................7
+   4. SEAL Protocol Specification - Tunnel Mode .......................8
+      4.1. Model of Operation .........................................8
+      4.2. ITE Specification .........................................10
+           4.2.1. Tunnel Interface MTU ...............................10
+           4.2.2. Accounting for Headers .............................11
+           4.2.3. Segmentation and Encapsulation .....................12
+           4.2.4. Sending Probes .....................................14
+           4.2.5. Packet Identification ..............................15
+           4.2.6. Sending SEAL Protocol Packets ......................15
+           4.2.7. Processing Raw ICMPv4 Messages .....................15
+           4.2.8. Processing SEAL-Encapsulated ICMPv4 Messages .......16
+      4.3. ETE Specification .........................................17
+           4.3.1. Reassembly Buffer Requirements .....................17
+           4.3.2. IPv4-Layer Reassembly ..............................17
+           4.3.3. Generating SEAL-Encapsulated ICMPv4
+                  Fragmentation Needed Messages ......................18
+           4.3.4. SEAL-Layer Reassembly ..............................19
+           4.3.5. Delivering Packets to Upper Layers .................20
+   5. SEAL Protocol Specification - Transport Mode ...................20
+   6. Link Requirements ..............................................21
+   7. End System Requirements ........................................21
+   8. Router Requirements ............................................21
+   9. IANA Considerations ............................................21
+   10. Security Considerations .......................................21
+   11. Related Work ..................................................22
+   12. SEAL Advantages over Classical Methods ........................22
+   13. Acknowledgments ...............................................24
+   14. References ....................................................24
+      14.1. Normative References .....................................24
+      14.2. Informative References ...................................24
+   Appendix A. Historic Evolution of PMTUD ...........................27
+   Appendix B. Reliability Extensions ................................29
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                      [Page 3]
+
+RFC 5320                          SEAL                     February 2010
+
+
+1.  Introduction
+
+   As Internet technology and communication has grown and matured, many
+   techniques have developed that use virtual topologies (including
+   tunnels of one form or another) over an actual network that supports
+   the Internet Protocol (IP) [RFC0791][RFC2460].  Those virtual
+   topologies have elements that appear as one hop in the virtual
+   topology, but are actually multiple IP or sub-IP layer hops.  These
+   multiple hops often have quite diverse properties that are often not
+   even visible to the endpoints of the virtual hop.  This introduces
+   failure modes that are not dealt with well in current approaches.
+
+   The use of IP encapsulation has long been considered as the means for
+   creating such virtual topologies.  However, the insertion of an outer
+   IP header reduces the effective path MTU as-seen by the IP layer.
+   When IPv4 is used, this reduced MTU can be accommodated through the
+   use of IPv4 fragmentation, but unmitigated in-the-network
+   fragmentation has been found to be harmful through operational
+   experience and studies conducted over the course of many years
+   [FRAG][FOLK][RFC4963].  Additionally, classical path MTU discovery
+   [RFC1191] has known operational issues that are exacerbated by in-
+   the-network tunnels [RFC2923][RFC4459].  In the following
+   subsections, we present further details on the motivation and
+   approach for addressing these issues.
+
+1.1.  Motivation
+
+   Before discussing the approach, it is necessary to first understand
+   the problems.  In both the Internet and private-use networks today,
+   IPv4 is ubiquitously deployed as the Layer 3 protocol.  The two
+   primary functions of IPv4 are to provide for 1) addressing, and 2) a
+   fragmentation and reassembly capability used to accommodate links
+   with diverse MTUs.  While it is well known that the addressing
+   properties of IPv4 are limited (hence, the larger address space
+   provided by IPv6), there is a lesser-known but growing consensus that
+   other limitations may be unable to sustain continued growth.
+
+   First, the IPv4 header Identification field is only 16 bits in
+   length, meaning that at most 2^16 packets pertaining to the same
+   (source, destination, protocol, Identification)-tuple may be active
+   in the Internet at a given time.  Due to the escalating deployment of
+   high-speed links (e.g., 1Gbps Ethernet), however, this number may
+   soon become too small by several orders of magnitude.  Furthermore,
+   there are many well-known limitations pertaining to IPv4
+   fragmentation and reassembly -- even to the point that it has been
+   deemed "harmful" in both classic and modern-day studies (cited
+   above).  In particular, IPv4 fragmentation raises issues ranging from
+
+
+
+
+Templin                       Experimental                      [Page 4]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   minor annoyances (e.g., slow-path processing in routers) to the
+   potential for major integrity issues (e.g., mis-association of the
+   fragments of multiple IP packets during reassembly).
+
+   As a result of these perceived limitations, a fragmentation-avoiding
+   technique for discovering the MTU of the forward path from a source
+   to a destination node was devised through the deliberations of the
+   Path MTU Discovery Working Group (PMTUDWG) during the late 1980's
+   through early 1990's (see Appendix A).  In this method, the source
+   node provides explicit instructions to routers in the path to discard
+   the packet and return an ICMP error message if an MTU restriction is
+   encountered.  However, this approach has several serious shortcomings
+   that lead to an overall "brittleness".
+
+   In particular, site border routers in the Internet are being
+   configured more and more to discard ICMP error messages coming from
+   the outside world.  This is due in large part to the fact that
+   malicious spoofing of error messages in the Internet is made simple
+   since there is no way to authenticate the source of the messages.
+   Furthermore, when a source node that requires ICMP error message
+   feedback when a packet is dropped due to an MTU restriction does not
+   receive the messages, a path MTU-related black hole occurs.  This
+   means that the source will continue to send packets that are too
+   large and never receive an indication from the network that they are
+   being discarded.
+
+   The issues with both IPv4 fragmentation and this "classical" method
+   of path MTU discovery are exacerbated further when IP-in-IP tunneling
+   is used.  For example, site border routers that are configured as
+   ingress tunnel endpoints may be required to forward packets into the
+   subnetwork on behalf of hundreds, thousands, or even more original
+   sources located within the site.  If IPv4 fragmentation were used,
+   this would quickly wrap the 16-bit Identification field and could
+   lead to undetected data corruption.  If classical IPv4 path MTU
+   discovery were used instead, the site border router may be bombarded
+   by ICMP error messages coming from the subnetwork that may be either
+   untrustworthy or insufficiently provisioned to allow translation into
+   error message to be returned to the original sources.
+
+   The situation is exacerbated further still by IPsec tunnels, since
+   only the first IPv4 fragment of a fragmented packet contains the
+   transport protocol selectors (e.g., the source and destination ports)
+   required for identifying the correct security association rendering
+   fragmentation useless under certain circumstances.  Even worse, there
+   may be no way for a site border router that configures an IPsec
+   tunnel to transcribe the encrypted packet fragment contained in an
+
+
+
+
+
+Templin                       Experimental                      [Page 5]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   ICMP error message into a suitable ICMP error message to return to
+   the original source.  Due to these many limitations, a new approach
+   to accommodate links with diverse MTUs is necessary.
+
+1.2.  Approach
+
+   For the purpose of this document, subnetworks are defined as virtual
+   topologies that span connected network regions bounded by
+   encapsulating border nodes.  Examples include the global Internet
+   interdomain routing core, Mobile Ad hoc Networks (MANETs) and
+   enterprise networks.  Subnetwork border nodes forward unicast and
+   multicast IP packets over the virtual topology across multiple IP
+   and/or sub-IP layer forwarding hops that may introduce packet
+   duplication and/or traverse links with diverse Maximum Transmission
+   Units (MTUs).
+
+   This document introduces a Subnetwork Encapsulation and Adaptation
+   Layer (SEAL) for tunnel-mode operation of IP over subnetworks that
+   connect Ingress and Egress Tunnel Endpoints (ITEs/ETEs) of border
+   nodes.  Operation in transport mode is also supported when subnetwork
+   border node upper-layer protocols negotiate the use of SEAL during
+   connection establishment.  SEAL accommodates links with diverse MTUs
+   and supports efficient duplicate packet detection by introducing a
+   minimal mid-layer encapsulation.
+
+   The SEAL encapsulation introduces an extended Identification field
+   for packet identification and a mid-layer segmentation and reassembly
+   capability that allows simplified cutting and pasting of packets.
+   Moreover, SEAL senses in-the-network IPv4 fragmentation as a "noise"
+   indication that packet sizing parameters are "out of tune" with
+   respect to the network path.  As a result, SEAL can naturally tune
+   its packet sizing parameters to eliminate the in-the-network
+   fragmentation.
+
+   The SEAL encapsulation layer and protocol are specified in the
+   following sections.
+
+2.  Terminology and Requirements
+
+   The terms "inner", "mid-layer", and "outer", respectively, refer to
+   the innermost IP (layer, protocol, header, packet, etc.) before any
+   encapsulation, the mid-layer IP (protocol, header, packet, etc.)
+   after any mid-layer '*' encapsulation, and the outermost IP (layer,
+   protocol, header, packet etc.) after SEAL/*/IPv4 encapsulation.
+
+   The term "IP" used throughout the document refers to either Internet
+   Protocol version (IPv4 or IPv6).  Additionally, the notation
+   IPvX/*/SEAL/*/IPvY refers to an inner IPvX packet encapsulated in any
+
+
+
+Templin                       Experimental                      [Page 6]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   mid-layer '*' encapsulations, followed by the SEAL header, followed
+   by any outer '*' encapsulations, followed by an outer IPvY header,
+   where the notation "IPvX" means either IP protocol version (IPv4 or
+   IPv6).
+
+   The following abbreviations correspond to terms used within this
+   document and elsewhere in common Internetworking nomenclature:
+
+      ITE - Ingress Tunnel Endpoint
+
+      ETE - Egress Tunnel Endpoint
+
+      PTB - an ICMPv6 "Packet Too Big" or an ICMPv4 "Fragmentation
+            Needed" message
+
+      DF - the IPv4 header "Don't Fragment" flag
+
+      MHLEN - the length of any mid-layer '*' headers and trailers
+
+      OHLEN - the length of the outer encapsulating SEAL/*/IPv4 headers
+
+      HLEN - the sum of MHLEN and OHLEN
+
+      S_MRU - the per-ETE SEAL Maximum Reassembly Unit
+
+      S_MSS - the SEAL Maximum Segment Size
+
+      SEAL_ID - a 32-bit Identification value, randomly initialized and
+                monotonically incremented for each SEAL protocol packet
+
+      SEAL_PROTO - an IPv4 protocol number used for SEAL
+
+      SEAL_PORT - a TCP/UDP service port number used for SEAL
+
+      SEAL_OPTION - a TCP option number used for (transport-mode) SEAL
+
+   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [RFC2119].
+
+3.  Applicability Statement
+
+   SEAL was motivated by the specific case of subnetwork abstraction for
+   Mobile Ad hoc Networks (MANETs); however, the domain of applicability
+   also extends to subnetwork abstractions of enterprise networks, the
+   interdomain routing core, etc.  The domain of application therefore
+
+
+
+
+
+Templin                       Experimental                      [Page 7]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   also includes the map-and-encaps architecture proposals in the IRTF
+   Routing Research Group (RRG) (see http://www3.tools.ietf.org/group/
+   irtf/trac/wiki/RoutingResearchGroup).
+
+   SEAL introduces a minimal new sublayer for IPvX in IPvY encapsulation
+   (e.g., as IPv6/SEAL/IPv4), and appears as a subnetwork encapsulation
+   as seen by the inner IP layer.  SEAL can also be used as a sublayer
+   for encapsulating inner IP packets within outer UDP/IPv4 headers
+   (e.g., as IPv6/SEAL/UDP/IPv4) such as for the Teredo domain of
+   applicability [RFC4380].  When it appears immediately after the outer
+   IPv4 header, the SEAL header is processed exactly as for IPv6
+   extension headers.
+
+   SEAL can also be used in "transport-mode", e.g., when the inner layer
+   includes upper-layer protocol data rather than an encapsulated IP
+   packet.  For instance, TCP peers can negotiate the use of SEAL for
+   the carriage of protocol data encapsulated as TCP/SEAL/IPv4.  In this
+   sense, the "subnetwork" becomes the entire end-to-end path between
+   the TCP peers and may potentially span the entire Internet.
+
+   The current document version is specific to the use of IPv4 as the
+   outer encapsulation layer; however, the same principles apply when
+   IPv6 is used as the outer layer.
+
+4.  SEAL Protocol Specification - Tunnel Mode
+
+4.1.  Model of Operation
+
+   SEAL supports the encapsulation of inner IP packets in mid-layer and
+   outer encapsulating headers/trailers.  For example, an inner IPv6
+   packet would appear as IPv6/*/SEAL/*/IPv4 after mid-layer and outer
+   encapsulations, where '*' denotes zero or more additional
+   encapsulation sublayers.  Ingres Tunnel Endpoints (ITEs) add mid-
+   layer inject into a subnetwork, where the outermost IPv4 header
+   contains the source and destination addresses of the subnetwork
+   entry/exit points (i.e., the ITE/ETE), respectively.  SEAL uses a new
+   Internet Protocol type and a new encapsulation sublayer for both
+   unicast and multicast.  The ITE encapsulates an inner IP packet in
+   mid-layer and outer encapsulations as shown in Figure 1:
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                      [Page 8]
+
+RFC 5320                          SEAL                     February 2010
+
+
+                                            +-------------------------+
+                                            |                         |
+                                            ~   Outer */IPv4 headers  ~
+                                            |                         |
+   I                                        +-------------------------+
+   n                                        |       SEAL Header       |
+   n      +-------------------------+       +-------------------------+
+   e      ~ Any mid-layer * headers ~       ~ Any mid-layer * headers ~
+   r      +-------------------------+       +-------------------------+
+          |                         |       |                         |
+   I -->  ~         Inner IP        ~  -->  ~         Inner IP        ~
+   P -->  ~         Packet          ~  -->  ~         Packet          ~
+          |                         |       |                         |
+   P      +-------------------------+       +-------------------------+
+   a      ~  Any mid-layer trailers ~       ~  Any mid-layer trailers ~
+   c      +-------------------------+       +-------------------------+
+   k                                        ~    Any outer trailers   ~
+   e                                        +-------------------------+
+   t
+           (After mid-layer encaps.)        (After SEAL/*/IPv4 encaps.)
+
+                       Figure 1: SEAL Encapsulation
+
+   where the SEAL header is inserted as follows:
+
+   o  For simple IPvX/IPv4 encapsulations (e.g.,
+      [RFC2003][RFC2004][RFC4213]), the SEAL header is inserted between
+      the inner IP and outer IPv4 headers as: IPvX/SEAL/IPv4.
+
+   o  For tunnel-mode IPsec encapsulations over IPv4, [RFC4301], the
+      SEAL header is inserted between the {AH,ESP} header and outer IPv4
+      headers as: IPvX/*/{AH,ESP}/SEAL/IPv4.
+
+   o  For IP encapsulations over transports such as UDP, the SEAL header
+      is inserted immediately after the outer transport layer header,
+      e.g., as IPvX/*/SEAL/UDP/IPv4.
+
+   SEAL-encapsulated packets include a 32-bit SEAL_ID formed from the
+   concatenation of the 16-bit ID Extension field in the SEAL header as
+   the most-significant bits, and with the 16-bit Identification value
+   in the outer IPv4 header as the least-significant bits.  (For tunnels
+   that traverse IPv4 Network Address Translators, the SEAL_ID is
+   instead maintained only within the 16-bit ID Extension field in the
+   SEAL header.)  Routers within the subnetwork use the SEAL_ID for
+   duplicate packet detection, and ITEs/ETEs use the SEAL_ID for SEAL
+   segmentation and reassembly.
+
+   SEAL enables a multi-level segmentation and reassembly capability.
+
+
+
+Templin                       Experimental                      [Page 9]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   First, the ITE can use IPv4 fragmentation to fragment inner IPv4
+   packets with DF=0 before SEAL encapsulation to avoid lower-layer
+   segmentation and reassembly.  Secondly, the SEAL layer itself
+   provides a simple cutting-and-pasting capability for mid-layer
+   packets to avoid IPv4 fragmentation on the outer packet.  Finally,
+   ordinary IPv4 fragmentation is permitted on the outer packet after
+   SEAL encapsulation and used to detect and dampen any in-the-network
+   fragmentation as quickly as possible.
+
+   The following sections specify the SEAL-related operations of the ITE
+   and ETE, respectively:
+
+4.2.  ITE Specification
+
+4.2.1.  Tunnel Interface MTU
+
+   The ITE configures a tunnel virtual interface over one or more
+   underlying links that connect the border node to the subnetwork.  The
+   tunnel interface must present a fixed MTU to the inner IP layer
+   (i.e., Layer 3) as the size for admission of inner IP packets into
+   the tunnel.  Since the tunnel interface may support a potentially
+   large set of ETEs, however, care must be taken in setting a greatest-
+   common-denominator MTU for all ETEs while still upholding end system
+   expectations.
+
+   Due to the ubiquitous deployment of standard Ethernet and similar
+   networking gear, the nominal Internet cell size has become 1500
+   bytes; this is the de facto size that end systems have come to expect
+   will either be delivered by the network without loss due to an MTU
+   restriction on the path or a suitable PTB message returned.  However,
+   the network may not always deliver the necessary PTBs, leading to
+   MTU-related black holes [RFC2923].  The ITE therefore requires a
+   means for conveying 1500 byte (or smaller) packets to the ETE without
+   loss due to MTU restrictions and without dependence on PTB messages
+   from within the subnetwork.
+
+   In common deployments, there may be many forwarding hops between the
+   original source and the ITE.  Within those hops, there may be
+   additional encapsulations (IPSec, L2TP, etc.) such that a 1500 byte
+   packet sent by the original source might grow to a larger size by the
+   time it reaches the ITE for encapsulation as an inner IP packet.
+   Similarly, additional encapsulations on the path from the ITE to the
+   ETE could cause the encapsulated packet to become larger still and
+   trigger in-the-network fragmentation.  In order to preserve the end
+   system expectations, the ITE therefore requires a means for conveying
+   these larger packets to the ETE even though there may be links within
+   the subnetwork that configure a smaller MTU.
+
+
+
+
+Templin                       Experimental                     [Page 10]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   The ITE should therefore set a tunnel virtual interface MTU of 1500
+   bytes plus extra room to accommodate any additional encapsulations
+   that may occur on the path from the original source (i.e., even if
+   the path to the ETE does not support an MTU of this size).  The ITE
+   can set larger MTU values still, but should select a value that is
+   not so large as to cause excessive PTBs coming from within the tunnel
+   interface (see Sections 4.2.2 and 4.2.6).  The ITE can also set
+   smaller MTU values; however, care must be taken not to set so small a
+   value that original sources would experience an MTU underflow.  In
+   particular, IPv6 sources must see a minimum path MTU of 1280 bytes,
+   and IPv4 sources should see a minimum path MTU of 576 bytes.
+
+   The inner IP layer consults the tunnel interface MTU when admitting a
+   packet into the interface.  For inner IPv4 packets larger than the
+   tunnel interface MTU and with the IPv4 Don't Fragment (DF) bit set to
+   0, the inner IPv4 layer uses IPv4 fragmentation to break the packet
+   into fragments no larger than the tunnel interface MTU (but, see also
+   Section 4.2.3), then admits each fragment into the tunnel as an
+   independent packet.  For all other inner packets (IPv4 or IPv6), the
+   ITE admits the packet if it is no larger than the tunnel interface
+   MTU; otherwise, it drops the packet and sends an ICMP PTB message
+   with an MTU value of the tunnel interface MTU to the source.
+
+4.2.2.  Accounting for Headers
+
+   As for any transport layer protocol, ITEs use the MTU of the
+   underlying IPv4 interface, the length of any mid-layer '*' headers
+   and trailers, and the length of the outer SEAL/*/IPv4 headers to
+   determine the maximum size for a SEAL segment (see Section 4.2.3).
+   For example, when the underlying IPv4 interface advertises an MTU of
+   1500 bytes and the ITE inserts a minimum-length (i.e., 20-byte) IPv4
+   header, the ITE sees a maximum segment size of 1480 bytes.  When the
+   ITE inserts IPv4 header options, the size is further reduced by as
+   many as 40 additional bytes (the maximum length for IPv4 options)
+   such that as few as 1440 bytes may be available for the upper-layer
+   payload.  When the ITE inserts additional '*' encapsulations, the
+   maximum segment size is reduced further still.
+
+   The ITE must additionally account for the length of the SEAL header
+   itself as an extra encapsulation that further reduces the maximum
+   segment size.  The length of the SEAL header is not incorporated in
+   the IPv4 header length; therefore, the network does not observe the
+   SEAL header as an IPv4 option.  In this way, the SEAL header is
+   inserted after the IPv4 options but before the upper-layer payload in
+   exactly the same manner as for IPv6 extension headers.
+
+
+
+
+
+
+Templin                       Experimental                     [Page 11]
+
+RFC 5320                          SEAL                     February 2010
+
+
+4.2.3.  Segmentation and Encapsulation
+
+   For each ETE, the ITE maintains the length of any mid-layer '*'
+   encapsulation headers and trailers (e.g., for '*' = AH, ESP, NULL,
+   etc.) in a variable 'MHLEN' and maintains the length of the outer
+   SEAL/*/IPv4 encapsulation headers in a variable 'OHLEN'.  The ITE
+   further maintains a variable 'HLEN' set to MHLEN plus OHLEN.  The ITE
+   maintains a SEAL Maximum Reassembly Unit (S_MRU) value for each ETE
+   as soft state within the tunnel interface (e.g., in the IPv4
+   destination cache).  The ITE initializes S_MRU to a value no larger
+   than 2KB and uses this value to determine the maximum-sized packet it
+   will require the ETE to reassemble.  The ITE additionally maintains a
+   SEAL Maximum Segment Size (S_MSS) value for each ETE.  The ITE
+   initializes S_MSS to the maximum of (the underlying IPv4 interface
+   MTU minus OHLEN) and S_MRU/8 bytes, and decreases or increases S_MSS
+   based on any ICMPv4 Fragmentation Needed messages received (see
+   Section 4.2.6).
+
+   The ITE performs segmentation and encapsulation on inner packets that
+   have been admitted into the tunnel interface.  For inner IPv4 packets
+   with the DF bit set to 0, if the length of the inner packet is larger
+   than (S_MRU - HLEN), the ITE uses IPv4 fragmentation to break the
+   packet into IPv4 fragments no larger than (S_MRU - HLEN).  For
+   unfragmentable inner packets (e.g., IPv6 packets, IPv4 packets with
+   DF=1, etc.), if the length of the inner packet is larger than
+   (MAX(S_MRU, S_MSS) - HLEN), the ITE drops the packet and sends an
+   ICMP PTB message with an MTU value of (MAX(S_MRU, S_MSS) - HLEN) back
+   to the original source.
+
+   The ITE then encapsulates each inner packet/fragment in the MHLEN
+   bytes of mid-layer '*' headers and trailers.  For each such resulting
+   mid-layer packet of length 'M', if (S_MRU >= (M + OHLEN) > S_MSS),
+   the ITE must perform SEAL segmentation.  To do so, it breaks the mid-
+   layer packet into N segments (N <= 8) that are no larger than
+   (MIN(1KB, S_MSS) - OHLEN) bytes each.  Each segment, except the final
+   one, MUST be of equal length, while the final segment MUST be no
+   larger than the initial segment.  The first byte of each segment MUST
+   begin immediately after the final byte of the previous segment, i.e.,
+   the segments MUST NOT overlap.  The ITE should generate the smallest
+   number of segments possible, e.g., it should not generate 6 smaller
+   segments when the packet could be accommodated with 4 larger
+   segments.
+
+   Note that this SEAL segmentation ignores the fact that the mid-layer
+   packet may be unfragmentable.  This segmentation process is a mid-
+   layer (not an IP layer) operation employed by the ITE to adapt the
+   mid-layer packet to the subnetwork path characteristics, and the ETE
+   will restore the packet to its original form during reassembly.
+
+
+
+Templin                       Experimental                     [Page 12]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   Therefore, the fact that the packet may have been segmented within
+   the subnetwork is not observable outside of the subnetwork.
+
+   The ITE next encapsulates each segment in a SEAL header formatted as
+   follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          ID Extension         |A|R|M|RSV| SEG |  Next Header  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 2: SEAL Header Format
+
+   where the header fields are defined as follows:
+
+   ID Extension (16)
+      a 16-bit extension of the Identification field in the outer IPv4
+      header; encodes the most-significant 16 bits of a 32 bit SEAL_ID
+      value.
+
+   A (1)
+      the "Acknowledgement Requested" bit.  Set to 1 if the ITE wishes
+      to receive an explicit acknowledgement from the ETE.
+
+   R (1)
+      the "Report Fragmentation" bit.  Set to 1 if the ITE wishes to
+      receive a report from the ETE if any IPv4 fragmentation occurs.
+
+   M (1)
+      the "More Segments" bit.  Set to 1 if this SEAL protocol packet
+      contains a non-final segment of a multi-segment mid-layer packet.
+
+   RSV (2)
+      a 2-bit field reserved for future use.  Must be set to 0 for the
+      purpose of this specification.
+
+   SEG (3)
+      a 3-bit segment number.  Encodes a segment number between 0 - 7.
+
+   Next Header (8)
+      an 8-bit field that encodes an Internet Protocol number the same
+      as for the IPv4 protocol and IPv6 next header fields.
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 13]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   For single-segment mid-layer packets, the ITE encapsulates the
+   segment in a SEAL header with (M=0; SEG=0).  For N-segment mid-layer
+   packets (N <= 8), the ITE encapsulates each segment in a SEAL header
+   with (M=1; SEG=0) for the first segment, (M=1; SEG=1) for the second
+   segment, etc., with the final segment setting (M=0; SEG=N-1).
+
+   The ITE next sets RSV='00' and sets the A and R bits in the SEAL
+   header of the first segment according to whether the packet is to be
+   used as an explicit/implicit probe as specified in Section 4.2.4.
+   The ITE then writes the Internet Protocol number corresponding to the
+   mid-layer packet in the SEAL 'Next Header' field and encapsulates
+   each segment in the requisite */IPv4 outer headers according to the
+   specific encapsulation format (e.g., [RFC2003], [RFC4213], [RFC4380],
+   etc.), except that it writes 'SEAL_PROTO' in the protocol field of
+   the outer IPv4 header (when simple IPv4 encapsulation is used) or
+   writes 'SEAL_PORT' in the outer destination service port field (e.g.,
+   when UDP/IPv4 encapsulation is used).  The ITE finally sets packet
+   identification values as specified in Section 4.2.5 and sends the
+   packets as specified in Section 4.2.6.
+
+4.2.4.  Sending Probes
+
+   When S_MSS is larger than S_MRU/8 bytes, the ITE sends ordinary
+   encapsulated data packets as implicit probes to detect in-the-network
+   IPv4 fragmentation and to determine new values for S_MSS.  The ITE
+   sets R=1 in the SEAL header of a packet with SEG=0 to be used as an
+   implicit probe, and will receive ICMPv4 Fragmentation Needed messages
+   from the ETE if any IPv4 fragmentation occurs.  When the ITE has
+   already reduced S_MSS to the minimum value, it instead sets R=0 in
+   the SEAL header to avoid generating fragmentation reports for
+   unavoidable in-the-network fragmentation.
+
+   The ITE should send explicit probes periodically to manage a window
+   of SEAL_IDs of outstanding probes as a means to validate any ICMPv4
+   messages it receives.  The ITE sets A=1 in the SEAL header of a
+   packet with SEG=0 to be used as an explicit probe, where the probe
+   can be either an ordinary data packet or a NULL packet created by
+   setting the 'Next Header' field in the SEAL header to a value of "No
+   Next Header" (see Section 4.7 of [RFC2460]).
+
+   The ITE should further send explicit probes, periodically, to detect
+   increases in S_MSS by resetting S_MSS to the maximum of (the
+   underlying IPv4 interface MTU minus OHLEN) and S_MRU/8 bytes, and/or
+   by sending explicit probes that are larger than the current S_MSS.
+
+   Finally, the ITE MAY send "expendable" probe packets with DF=1 (see
+   Section 4.2.6) in order to generate ICMPv4 Fragmentation Needed
+   messages from routers on the path to the ETE.
+
+
+
+Templin                       Experimental                     [Page 14]
+
+RFC 5320                          SEAL                     February 2010
+
+
+4.2.5.  Packet Identification
+
+   For the purpose of packet identification, the ITE maintains a 32-bit
+   SEAL_ID value as per-ETE soft state, e.g., in the IPv4 destination
+   cache.  The ITE randomly initializes SEAL_ID when the soft state is
+   created and monotonically increments it (modulo 2^32) for each
+   successive SEAL protocol packet it sends to the ETE.  For each
+   packet, the ITE writes the least-significant 16 bits of the SEAL_ID
+   value in the Identification field in the outer IPv4 header, and
+   writes the most-significant 16 bits in the ID Extension field in the
+   SEAL header.
+
+   For SEAL encapsulations specifically designed for the traversal of
+   IPv4 Network Address Translators (NATs), e.g., for encapsulations
+   that insert a UDP header between the SEAL header and outer IPv4
+   header such as IPv6/SEAL/UDP/IPv4, the ITE instead maintains SEAL_ID
+   as a 16-bit value that it randomly initializes when the soft state is
+   created and monotonically increments (modulo 2^16) for each
+   successive packet.  For each packet, the ITE writes SEAL_ID in the ID
+   extension field of the SEAL header and writes a random 16-bit value
+   in the Identification field in the outer IPv4 header.  This is due to
+   the fact that the ITE has no way to control IPv4 NATs in the path
+   that could rewrite the Identification value in the outer IPv4 header.
+
+4.2.6.  Sending SEAL Protocol Packets
+
+   Following SEAL segmentation and encapsulation, the ITE sets DF=0 in
+   the outer IPv4 header of every outer packet it sends.  For
+   "expendable" packets (e.g., for NULL packets used as probes -- see
+   Section 4.2.4), the ITE may instead set DF=1.
+
+   The ITE then sends each outer packet that encapsulates a segment of
+   the same mid-layer packet into the tunnel in canonical order, i.e.,
+   segment 0 first, followed by segment 1, etc. and finally segment N-1.
+
+4.2.7.  Processing Raw ICMPv4 Messages
+
+   The ITE may receive "raw" ICMPv4 error messages from either the ETE
+   or routers within the subnetwork that comprise an outer IPv4 header,
+   followed by an ICMPv4 header, followed by a portion of the SEAL
+   packet that generated the error (also known as the "packet-in-
+   error").  For such messages, the ITE can use the 32-bit SEAL ID
+   encoded in the packet-in-error as a nonce to confirm that the ICMP
+   message came from either the ETE or an on-path router.  The ITE MAY
+   process raw ICMPv4 messages as soft errors indicating that the path
+   to the ETE may be failing.
+
+
+
+
+
+Templin                       Experimental                     [Page 15]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   The ITE should specifically process raw ICMPv4 Protocol Unreachable
+   messages as a hint that the ETE does not implement the SEAL protocol.
+
+4.2.8.  Processing SEAL-Encapsulated ICMPv4 Messages
+
+   In addition to any raw ICMPv4 messages, the ITE may receive SEAL-
+   encapsulated ICMPv4 messages from the ETE that comprise outer ICMPv4/
+   */SEAL/*/IPv4 headers followed by a portion of the SEAL-encapsulated
+   packet-in-error.  The ITE can use the 32-bit SEAL ID encoded in the
+   packet-in-error as well as information in the outer IPv4 and SEAL
+   headers as nonces to confirm that the ICMP message came from a
+   legitimate ETE.  The ITE then verifies that the SEAL_ID encoded in
+   the packet-in-error is within the current window of transmitted
+   SEAL_IDs for this ETE.  If the SEAL_ID is outside of the window, the
+   ITE discards the message; otherwise, it advances the window and
+   processes the message.
+
+   The ITE processes SEAL-encapsulated ICMPv4 messages other than ICMPv4
+   Fragmentation Needed exactly as specified in [RFC0792].
+
+   For SEAL-encapsulated ICMPv4 Fragmentation Needed messages, the ITE
+   sets a variable 'L' to the IPv4 length of the packet-in-error minus
+   OHLEN.  If (L > S_MSS), or if the packet-in-error is an IPv4 first
+   fragment (i.e., with MF=1; Offset=0) and (L >= (576 - OHLEN)), the
+   ITE sets (S_MSS = L).
+
+   Note that 576 in the above corresponds to the nominal minimum MTU for
+   IPv4 links.  When an ITE instead receives an IPv4 first fragment
+   packet-in-error with (L < (576 - OHLEN)), it discovers that IPv4
+   fragmentation is occurring in the network but it cannot determine the
+   true MTU of the restricting link due to a router on the path
+   generating runt first fragments.  The ITE should therefore search for
+   a reduced S_MSS value (to a minimum of S_MRU/8) through an iterative
+   searching strategy that parallels (Section 5 of [RFC1191]).
+
+   This searching strategy may require multiple iterations of sending
+   SEAL packets with DF=0 using a reduced S_MSS and receiving additional
+   Fragmentation Needed messages, but it will soon converge to a stable
+   value.  During this process, it is essential that the ITE reduce
+   S_MSS based on the first Fragmentation Needed message received, and
+   refrain from further reducing S_MSS until ICMPv4 Fragmentation Needed
+   messages pertaining to packets sent under the new S_MSS are received.
+
+   As an optimization only, the ITE MAY transcribe SEAL-encapsulated
+   Fragmentation Needed messages that contain sufficient information
+   into corresponding PTB messages to return to the original source.
+
+
+
+
+
+Templin                       Experimental                     [Page 16]
+
+RFC 5320                          SEAL                     February 2010
+
+
+4.3.  ETE Specification
+
+4.3.1.  Reassembly Buffer Requirements
+
+   ETEs MUST be capable of using IPv4-layer reassembly to reassemble
+   SEAL protocol outer IPv4 packets up to 2KB in length, and MUST also
+   be capable of using SEAL-layer reassembly to reassemble mid-layer
+   packets up to (2KB - OHLEN).  Note that the ITE must retain the
+   SEAL/*/IPv4 header during both IPv4-layer and SEAL-layer reassembly
+   for the purpose of associating the fragments/segments of the same
+   packet.
+
+4.3.2.  IPv4-Layer Reassembly
+
+   The ETE performs IPv4 reassembly as normal, and should maintain a
+   conservative high- and low-water mark for the number of outstanding
+   reassemblies pending for each ITE.  When the size of the reassembly
+   buffer exceeds this high-water mark, the ETE actively discards
+   incomplete reassemblies (e.g., using an Active Queue Management (AQM)
+   strategy) until the size falls below the low-water mark.  The ETE
+   should also use a reduced IPv4 maximum segment lifetime value (e.g.,
+   15 seconds), i.e., the time after which it will discard an incomplete
+   IPv4 reassembly for a SEAL protocol packet.  Finally, the ETE should
+   also actively discard any pending reassemblies that clearly have no
+   opportunity for completion, e.g., when a considerable number of new
+   IPv4 fragments have been received before a fragment that completes a
+   pending reassembly has arrived.
+
+   After reassembly, the ETE either accepts or discards the reassembled
+   packet based on the current status of the IPv4 reassembly cache
+   (congested versus uncongested).  The SEAL_ID included in the IPv4
+   first fragment provides an additional level of reassembly assurance,
+   since it can record a distinct arrival timestamp useful for
+   associating the first fragment with its corresponding non-initial
+   fragments.  The choice of accepting/discarding a reassembly may also
+   depend on the strength of the upper-layer integrity check if known
+   (e.g., IPSec/ESP provides a strong upper-layer integrity check)
+   and/or the corruption tolerance of the data (e.g., multicast
+   streaming audio/video may be more corruption-tolerant than file
+   transfer, etc.).  In the limiting case, the ETE may choose to discard
+   all IPv4 reassemblies and process only the IPv4 first fragment for
+   SEAL-encapsulated error generation purposes (see the following
+   sections).
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 17]
+
+RFC 5320                          SEAL                     February 2010
+
+
+4.3.3.  Generating SEAL-Encapsulated ICMPv4 Fragmentation Needed
+        Messages
+
+   During IPv4-layer reassembly, the ETE determines whether the packet
+   belongs to the SEAL protocol by checking for SEAL_PROTO in the outer
+   IPv4 header (i.e., for simple IPv4 encapsulation) or for SEAL_PORT in
+   the outer */IPv4 header (e.g., for '*'=UDP).  When the ETE processes
+   the IPv4 first fragment (i.e, one with DF=1 and Offset=0 in the IPv4
+   header) of a SEAL protocol IPv4 packet with (R=1; SEG=0) in the SEAL
+   header, it sends a SEAL-encapsulated ICMPv4 Fragmentation Needed
+   message back to the ITE with the MTU field set to 0.  (Note that
+   setting a non-zero value in the MTU field of the ICMPv4 Fragmentation
+   Needed message would be redundant with the length value in the IPv4
+   header of the first fragment, since this value is set to the correct
+   path MTU through in-the-network fragmentation.  Setting the MTU field
+   to 0 therefore avoids the ambiguous case in which the MTU field and
+   the IPv4 length field of the first fragment would record different
+   non-zero values.)
+
+   When the ETE processes a SEAL protocol IPv4 packet with (A=1; SEG=0)
+   for which no IPv4 reassembly was required, or for which IPv4
+   reassembly was successful and the R bit was not set, it sends a SEAL-
+   encapsulated ICMPv4 Fragmentation Needed message back to the ITE with
+   the MTU value set to 0.  Note therefore that when both the A and R
+   bits are set and fragmentation occurs, the ETE only sends a single
+   ICMPv4 Fragmentation Needed message, i.e., it does not send two
+   separate messages (one for the first fragment and a second for the
+   reassembled whole SEAL packet).
+
+   The ETE prepares the ICMPv4 Fragmentation Needed message by
+   encapsulating as much of the first fragment (or the non-fragmented
+   packet) as possible in outer */SEAL/*/IPv4 headers without the length
+   of the message exceeding 576 bytes, as shown in Figure 3:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 18]
+
+RFC 5320                          SEAL                     February 2010
+
+
+      +-------------------------+ -
+      |                         |   ~ Outer */SEAL/*/IPv4 hdrs~   |
+      |                         |   |
+      +-------------------------+   |
+      |      ICMPv4 Header      |   |
+      |(Dest Unreach; Frag Need)|   |
+      +-------------------------+   |
+      |                         |    > Up to 576 bytes
+      ~    IP/*/SEAL/*/IPv4     ~   |
+      ~ hdrs of packet/fragment ~   |
+      |                         |   |
+      +-------------------------+   |
+      |                         |   |
+      ~ Data of packet/fragment ~   |
+      |                         |   /
+      +-------------------------+ -
+
+       Figure 3: SEAL-Encapsulated ICMPv4 Fragmentation Needed Message
+
+   The ETE next sets A=0, R=0, and SEG=0 in the outer SEAL header, sets
+   the SEAL_ID the same as for any SEAL packet, then sets the SEAL Next
+   Header field and the fields of the outer */IPv4 headers the same as
+   for ordinary SEAL encapsulation.  The ETE then sets the outer IPv4
+   destination and source addresses to the source and destination
+   addresses (respectively) of the packet/fragment.  If the destination
+   address in the packet/fragment was multicast, the ETE instead sets
+   the outer IPv4 source address to an address assigned to the
+   underlying IPv4 interface.  The ETE finally sends the SEAL-
+   encapsulated ICMPv4 message to the ITE the same as specified in
+   Section 4.2.5, except that when the A bit in the packet/fragment is
+   not set, the ETE sends the messages subject to rate limiting since it
+   is not entirely critical that all fragmentation be reported to the
+   ITE.
+
+4.3.4.  SEAL-Layer Reassembly
+
+   Following IPv4 reassembly of a SEAL packet with (RSV!=0; SEG=0), if
+   the packet is not a SEAL-encapsulated ICMPv4 message, the ETE
+   generates a SEAL-encapsulated ICMPv4 Parameter Problem message with
+   pointer set to the flags field in the SEAL header, sends the message
+   back to the ITE in the same manner specified in Section 4.3.3, then
+   drops the packet.  For all other SEAL packets, the ETE adds the
+   packet to a SEAL-Layer pending-reassembly queue if either the M bit
+   or the SEG field in the SEAL header is non-zero.
+
+   The ETE performs SEAL-layer reassembly through simple in-order
+   concatenation of the encapsulated segments from N consecutive SEAL
+   protocol packets from the same mid-layer packet.  SEAL-layer
+
+
+
+Templin                       Experimental                     [Page 19]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   reassembly requires the ETE to maintain a cache of recently received
+   segments for a hold time that would allow for reasonable inter-
+   segment delays.  The ETE uses a SEAL maximum segment lifetime of 15
+   seconds for this purpose, i.e., the time after which it will discard
+   an incomplete reassembly.  However, the ETE should also actively
+   discard any pending reassemblies that clearly have no opportunity for
+   completion, e.g., when a considerable number of new SEAL packets have
+   been received before a packet that completes a pending reassembly has
+   arrived.
+
+   The ETE reassembles the mid-layer packet segments in SEAL protocol
+   packets that contain segment numbers 0 through N-1, with M=1/0 in
+   non-final/final segments, respectively, and with consecutive SEAL_ID
+   values.  That is, for an N-segment mid-layer packet, reassembly
+   entails the concatenation of the SEAL-encapsulated segments with
+   (segment 0, SEAL_ID i), followed by (segment 1, SEAL_ID ((i + 1) mod
+   2^32)), etc. up to (segment N-1, SEAL_ID ((i + N-1) mod 2^32)).  (For
+   SEAL encapsulations specifically designed for traversal of IPv4 NATs,
+   the ETE instead uses only a 16-bit SEAL_ID value, and uses mod 2^16
+   arithmetic to associate the segments of the same packet.)
+
+4.3.5.  Delivering Packets to Upper Layers
+
+   Following SEAL-layer reassembly, the ETE silently discards the
+   reassembled packet if it was a NULL packet (see Section 4.2.4).  In
+   the same manner, the ETE silently discards any reassembled mid-layer
+   packet larger than (2KB - OHLEN) that either experienced IPv4
+   fragmentation or did not arrive as a single SEAL segment.
+
+   Next, if the ETE determines that the inner packet would cause an
+   ICMPv4 error message to be generated, it generates a SEAL-
+   encapsulated ICMPv4 error message, sends the message back to the ITE
+   in the same manner specified in Section 4.3.3, then either accepts or
+   drops the packet according to the type of error.  Otherwise, the ETE
+   delivers the inner packet to the upper-layer protocol indicated in
+   the Next Header field.
+
+5.  SEAL Protocol Specification - Transport Mode
+
+   Section 4 specifies the operation of SEAL in "tunnel mode", i.e.,
+   when there are both an inner and outer IP layer with a SEAL
+   encapsulation layer between.  However, the SEAL protocol can also be
+   used in a "transport mode" of operation within a subnetwork region in
+   which the inner-layer corresponds to a transport layer protocol
+   (e.g., UDP, TCP, etc.) instead of an inner IP layer.
+
+
+
+
+
+
+Templin                       Experimental                     [Page 20]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   For example, two TCP endpoints connected to the same subnetwork
+   region can negotiate the use of transport-mode SEAL for a connection
+   by inserting a 'SEAL_OPTION' TCP option during the connection
+   establishment phase.  If both TCPs agree on the use of SEAL, their
+   protocol messages will be carried as TCP/SEAL/IPv4 and the connection
+   will be serviced by the SEAL protocol using TCP (instead of an
+   encapsulating tunnel endpoint) as the transport layer protocol.  The
+   SEAL protocol for transport mode otherwise observes the same
+   specifications as for Section 4.
+
+6.  Link Requirements
+
+   Subnetwork designers are expected to follow the recommendations in
+   Section 2 of [RFC3819] when configuring link MTUs.
+
+7.  End System Requirements
+
+   SEAL provides robust mechanisms for returning PTB messages; however,
+   end systems that send unfragmentable IP packets larger than 1500
+   bytes are strongly encouraged to use Packetization Layer Path MTU
+   Discovery per [RFC4821].
+
+8.  Router Requirements
+
+   IPv4 routers within the subnetwork are strongly encouraged to
+   implement IPv4 fragmentation such that the first fragment is the
+   largest and approximately the size of the underlying link MTU, i.e.,
+   they should avoid generating runt first fragments.
+
+9.  IANA Considerations
+
+   SEAL_PROTO, SEAL_PORT, and SEAL_OPTION are taken from their
+   respective range of experimental values documented in [RFC3692] and
+   [RFC4727].  These values are for experimentation purposes only, and
+   not to be used for any kind of deployments (i.e., they are not to be
+   shipped in any products).
+
+10.  Security Considerations
+
+   Unlike IPv4 fragmentation, overlapping fragment attacks are not
+   possible due to the requirement that SEAL segments be non-
+   overlapping.
+
+   An amplification/reflection attack is possible when an attacker sends
+   IPv4 first fragments with spoofed source addresses to an ETE,
+   resulting in a stream of ICMPv4 Fragmentation Needed messages
+
+
+
+
+
+Templin                       Experimental                     [Page 21]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   returned to a victim ITE.  The encapsulated segment of the spoofed
+   IPv4 first fragment provides mitigation for the ITE to detect and
+   discard spurious ICMPv4 Fragmentation Needed messages.
+
+   The SEAL header is sent in-the-clear (outside of any IPsec/ESP
+   encapsulations) the same as for the outer */IPv4 headers.  As for
+   IPv6 extension headers, the SEAL header is protected only by L2
+   integrity checks and is not covered under any L3 integrity checks.
+
+11.  Related Work
+
+   Section 3.1.7 of [RFC2764] provides a high-level sketch for
+   supporting large tunnel MTUs via a tunnel-level segmentation and
+   reassembly capability to avoid IP level fragmentation, which is in
+   part the same approach used by tunnel-mode SEAL.  SEAL could
+   therefore be considered as a fully functioned manifestation of the
+   method postulated by that informational reference; however, SEAL also
+   supports other modes of operation including transport-mode and
+   duplicate packet detection.
+
+   Section 3 of [RFC4459] describes inner and outer fragmentation at the
+   tunnel endpoints as alternatives for accommodating the tunnel MTU;
+   however, the SEAL protocol specifies a mid-layer segmentation and
+   reassembly capability that is distinct from both inner and outer
+   fragmentation.
+
+   Section 4 of [RFC2460] specifies a method for inserting and
+   processing extension headers between the base IPv6 header and
+   transport layer protocol data.  The SEAL header is inserted and
+   processed in exactly the same manner.
+
+   The concepts of path MTU determination through the report of
+   fragmentation and extending the IP Identification field were first
+   proposed in deliberations of the TCP-IP mailing list and the Path MTU
+   Discovery Working Group (MTUDWG) during the late 1980's and early
+   1990's.  SEAL supports a report fragmentation capability using bits
+   in an extension header (the original proposal used a spare bit in the
+   IP header) and supports ID extension through a 16-bit field in an
+   extension header (the original proposal used a new IP option).  A
+   historical analysis of the evolution of these concepts, as well as
+   the development of the eventual path MTU discovery mechanism for IP,
+   appears in Appendix A of this document.
+
+12.  SEAL Advantages over Classical Methods
+
+   The SEAL approach offers a number of distinct advantages over the
+   classical path MTU discovery methods [RFC1191] [RFC1981]:
+
+
+
+
+Templin                       Experimental                     [Page 22]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   1.  Classical path MTU discovery *always* results in packet loss when
+       an MTU restriction is encountered.  Using SEAL, IPv4
+       fragmentation provides a short-term interim mechanism for
+       ensuring that packets are delivered while SEAL adjusts its packet
+       sizing parameters.
+
+   2.  Classical path MTU discovery requires that routers generate an
+       ICMP PTB message for *all* packets lost due to an MTU
+       restriction; this situation is exacerbated at high data rates and
+       becomes severe for in-the-network tunnels that service many
+       communicating end systems.  Since SEAL ensures that packets no
+       larger than S_MRU are delivered, however, it is sufficient for
+       the ETE to return ICMPv4 Fragmentation Needed messages subject to
+       rate limiting and not for every packet-in-error.
+
+   3.  Classical path MTU may require several iterations of dropping
+       packets and returning ICMP PTB messages until an acceptable path
+       MTU value is determined.  Under normal circumstances, SEAL
+       determines the correct packet sizing parameters in a single
+       iteration.
+
+   4.  Using SEAL, ordinary packets serve as implicit probes without
+       exposing data to unnecessary loss.  SEAL also provides an
+       explicit probing mode not available in the classic methods.
+
+   5.  Using SEAL, ETEs encapsulate ICMP error messages in an outer SEAL
+       header such that packet-filtering network middleboxes can
+       distinguish them from "raw" ICMP messages that may be generated
+       by an attacker.
+
+   6.  Most importantly, all SEAL packets have a 32-bit Identification
+       value that can be used for duplicate packet detection purposes
+       and to match ICMP error messages with actual packets sent without
+       requiring per-packet state.  Moreover, the SEAL ITE can be
+       configured to accept ICMP feedback only from the legitimate ETE;
+       hence, the packet spoofing-related denial-of-service attack
+       vectors open to the classical methods are eliminated.
+
+   In summary, the SEAL approach represents an architecturally superior
+   method for ensuring that packets of various sizes are either
+   delivered or deterministically dropped.  When end systems use their
+   own end-to-end MTU determination mechanisms [RFC4821], the SEAL
+   advantages are further enhanced.
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 23]
+
+RFC 5320                          SEAL                     February 2010
+
+
+13.  Acknowledgments
+
+   The following individuals are acknowledged for helpful comments and
+   suggestions: Jari Arkko, Fred Baker, Iljitsch van Beijnum, Teco Boot,
+   Bob Braden, Brian Carpenter, Steve Casner, Ian Chakeres, Remi Denis-
+   Courmont, Aurnaud Ebalard, Gorry Fairhurst, Joel Halpern, John
+   Heffner, Thomas Henderson, Bob Hinden, Christian Huitema, Joe Macker,
+   Matt Mathis, Erik Nordmark, Dan Romascanu, Dave Thaler, Joe Touch,
+   Magnus Westerlund, Robin Whittle, James Woodyatt, and members of the
+   Boeing PhantomWorks DC&NT group.
+
+   Path MTU determination through the report of fragmentation was first
+   proposed by Charles Lynn on the TCP-IP mailing list in 1987.
+   Extending the IP identification field was first proposed by Steve
+   Deering on the MTUDWG mailing list in 1989.
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, September 1981.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+14.2.  Informative References
+
+   [FOLK]     C, C., D, D., and k. k, "Beyond Folklore: Observations on
+              Fragmented Traffic", December 2002.
+
+   [FRAG]     Kent, C. and J. Mogul, "Fragmentation Considered Harmful",
+              October 1987.
+
+   [MTUDWG]   "IETF MTU Discovery Working Group mailing list,
+               gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log,
+              November 1989 - February 1995.".
+
+   [RFC1063]  Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
+              MTU discovery options", RFC 1063, July 1988.
+
+
+
+
+
+Templin                       Experimental                     [Page 24]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+              November 1990.
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, August 1996.
+
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              October 1996.
+
+   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+              October 1996.
+
+   [RFC2764]  Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+              Malis, "A Framework for IP Based Virtual Private
+              Networks", RFC 2764, February 2000.
+
+   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC
+              2923, September 2000.
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
+              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
+              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
+              RFC 3819, July 2004.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380, February
+              2006.
+
+   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
+              Network Tunneling", RFC 4459, April 2006.
+
+   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
+              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, March 2007.
+
+   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
+              Errors at High Data Rates", RFC 4963, July 2007.
+
+
+
+Templin                       Experimental                     [Page 25]
+
+RFC 5320                          SEAL                     February 2010
+
+
+   [TCP-IP]   "Archive/Hypermail of Early TCp-IP Mail List",
+              http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/,
+              May 1987 - May 1990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 26]
+
+RFC 5320                          SEAL                     February 2010
+
+
+Appendix A.  Historic Evolution of PMTUD
+
+   (Taken from "Neighbor Affiliation Protocol for IPv6-over-(foo)-over-
+   IPv4"; written 10/30/2002):
+
+   The topic of Path MTU discovery (PMTUD) saw a flurry of discussion
+   and numerous proposals in the late 1980's through early 1990.  The
+   initial problem was posed by Art Berggreen on May 22, 1987 in a
+   message to the TCP-IP discussion group [TCP-IP].  The discussion that
+   followed provided significant reference material for [FRAG].  An IETF
+   Path MTU Discovery Working Group [MTUDWG] was formed in late 1989
+   with charter to produce an RFC.  Several variations on a very few
+   basic proposals were entertained, including:
+
+   1.  Routers record the PMTUD estimate in ICMP-like path probe
+       messages (proposed in [FRAG] and later [RFC1063])
+
+   2.  The destination reports any fragmentation that occurs for packets
+       received with the "RF" (Report Fragmentation) bit set (Steve
+       Deering's 1989 adaptation of Charles Lynn's Nov. 1987 proposal)
+
+   3.  A hybrid combination of 1) and Charles Lynn's Nov. 1987 (straw
+       RFC draft by McCloughrie, Fox and Mogul on Jan 12, 1990)
+
+   4.  Combination of the Lynn proposal with TCP (Fred Bohle, Jan 30,
+       1990)
+
+   5.  Fragmentation avoidance by setting "IP_DF" flag on all packets
+       and retransmitting if ICMPv4 "fragmentation needed" messages
+       occur (Geof Cooper's 1987 proposal; later adapted into [RFC1191]
+       by Mogul and Deering).
+
+   Option 1) seemed attractive to the group at the time, since it was
+   believed that routers would migrate more quickly than hosts.  Option
+   2) was a strong contender, but repeated attempts to secure an "RF"
+   bit in the IPv4 header from the IESG failed and the proponents became
+   discouraged. 3) was abandoned because it was perceived as too
+   complicated, and 4) never received any apparent serious
+   consideration.  Proposal 5) was a late entry into the discussion from
+   Steve Deering on Feb. 24th, 1990.  The discussion group soon
+   thereafter seemingly lost track of all other proposals and adopted
+   5), which eventually evolved into [RFC1191] and later [RFC1981].
+
+   In retrospect, the "RF" bit postulated in 2) is not needed if a
+   "contract" is first established between the peers, as in proposal 4)
+   and a message to the MTUDWG mailing list from jrd@PTT.LCS.MIT.EDU on
+   Feb 19. 1990.  These proposals saw little discussion or rebuttal, and
+   were dismissed based on the following the assertions:
+
+
+
+Templin                       Experimental                     [Page 27]
+
+RFC 5320                          SEAL                     February 2010
+
+
+      o  routers upgrade their software faster than hosts
+
+      o  PCs could not reassemble fragmented packets
+
+      o  Proteon and Wellfleet routers did not reproduce the "RF" bit
+         properly in fragmented packets
+
+      o  Ethernet-FDDI bridges would need to perform fragmentation
+         (i.e., "translucent" not "transparent" bridging)
+
+      o  the 16-bit IP_ID field could wrap around and disrupt reassembly
+         at high packet arrival rates
+
+   The first four assertions, although perhaps valid at the time, have
+   been overcome by historical events leaving only the final to
+   consider.  But, [FOLK] has shown that IP_ID wraparound simply does
+   not occur within several orders of magnitude the reassembly timeout
+   window on high-bandwidth networks.
+
+   (Author's 2/11/08 note: this final point was based on a loose
+   interpretation of [FOLK], and is more accurately addressed in
+   [RFC4963].)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 28]
+
+RFC 5320                          SEAL                     February 2010
+
+
+Appendix B.  Reliability Extensions
+
+   The SEAL header includes a Reserved (RSV) field that is set to zero
+   for the purpose of this specification.  This field may be used by
+   future updates to this specification for the purpose of improved
+   reliability in the face of loss due to congestion, signal
+   intermittence, etc.  Automatic Repeat-ReQuest (ARQ) mechanisms are
+   used to ensure reliable delivery between the endpoints of physical
+   links (e.g., on-link neighbors in an IEEE 802.11 network) as well as
+   between the endpoints of an end-to-end transport (e.g., the endpoints
+   of a TCP connection).  However, ARQ mechanisms may be poorly suited
+   to in-the-network elements such as the SEAL ITE and ETE, since
+   retransmission of lost segments would require unacceptable state
+   maintenance at the ITE and would result in packet reordering within
+   the subnetwork.
+
+   Instead, alternate reliability mechanisms such as Forward Error
+   Correction (FEC) may be specified in future updates to this
+   specification for the purpose of improved reliability.  Such
+   mechanisms may entail the ITE performing proactive transmissions of
+   redundant data, e.g., by sending multiple copies of the same data.
+   Signaling from the ETE (e.g., by sending SEAL-encapsulated ICMPv4
+   Source Quench messages) may be specified in a future document as a
+   means for the ETE to dynamically inform the ITE of changing FEC
+   conditions.
+
+Author's Address
+
+   Fred L. Templin, Editor
+   Boeing Research & Technology
+   P.O. Box 3707
+   Seattle, WA  98124
+   USA
+
+   EMail: fltemplin@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Experimental                     [Page 29]
+