RE: "Deprecate"

One other thing to add:

   "SEAL transport mode implementations SHOULD configure reassembly buffers
    that are large enough to accommodate a maximum-sized SEAL packet, i.e.,
    they SHOULD configure a 64KB reassembly buffer size."

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Templin, Fred L
> Sent: Friday, August 02, 2013 8:41 AM
> To: ipv6@ietf.org
> Subject: RE: "Deprecate"
> 
> 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
> fred.l.templin@boeing.com
> 
> 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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------