RE: "Deprecate"

["C. M. Heard" <[e-mail]>]

Thanks for adding transport mode ... it's essential for addressing 
the issues under discussion on this thread.

//cmh

On Fri, 2 Aug 2013, Templin, Fred L wrote:
> Hi,
> 
> Up to now, the SEAL spec has focused on "tunnel mode", and had the
> singular statement:
> 
>   "(A transport-mode of operation is also possible, but out of scope
>    for this document.)"
> 
> in the introduction. (Indeed, the first edition of SEAL (RFC5320)
> did specify a transport mode of operation, but that document will
> be obsolete by the second edition.) So, in light of these discussions
> I decided that now might be a good time to bring transport mode back
> into scope and as such have added the following new section to the
> document. Please send comments and suggestions. I will post a new
> draft version by the end of the day that will include both tunnel
> and transport modes.
> 
> Thanks - Fred
> [e-mail]
> 
> 6.  SEAL Transport Mode Specification
> 
>    SEAL is also used for transport-mode operation.  Transport mode
>    refers to a SEAL encapsulation in which a layer-4 header appears
>    immediately following the SEAL header.  The type of layer-4 header is
>    indicated in the "NEXTHDR" field the same as for tunnel mode.  The
>    SEAL header is identical to the version used for tunnel mode, except
>    that the "LINK_ID" and "LEVEL" fields are omitted, and the transport
>    layer port numbers are included in each non-initial segment (see:
>    Figure 6).
> 
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    NEXTHDR    |VER|C|P|I|V|R|M|     Offset    |    Reserved   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Source Port (when Offset!=0)  |   Dest Port (when Offset!=0)  |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                      Identification (optional)                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                  Integrity Check Vector (optional)            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ...
> 
>                        Figure 6: SEAL Header Format
> 
>    The "Source Port" and "Dest Port" are taken from the corresponding
>    fields in the transport layer next header that appears immediately
>    following the SEAL header in the initial segment.  For example, for
>    UDP [RFC0768] the transport layer source/dest ports are 16 bits in
>    length and are copied from the transport layer header.  All
>    segmentation is exactly as specified in SEAL tunnel mode, and the
>    SEAL Control Message Protocol (SCMP) operates the same as for tunnel
>    mode.  For example, the source node can probe the path MTU to the
>    destination by setting the P bit in a probe packet and waiting for an
>    acknowledgement from the destination.
> 
>    SEAL transport mode is useful for transport layer protocols that have
>    no way to segment the large packets they send.  It is a universal
>    format that can be applied to any such transport.
>