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
[email protected]
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Templin, Fred L
> Sent: Friday, August 02, 2013 8:41 AM
> To: [email protected]
> 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
> [email protected]
>
> 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
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
