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.temp...@boeing.com > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@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.temp...@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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------