Subject: RE: RFC4821 for tunnels using SEAL

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Oct 2013 21:30:30 +0000

Hi,

A new version of the SEAL code is available here:

http://linkupnetworks.com/seal/sealv2-0.1.tgz

This version picks up changes introduced by the recently
released -63 SEAL draft version:

http://www.ietf.org/id/draft-templin-intarea-seal-63.txt

It also adds support for IPv6-in-IPv4 tunnels, and ensures
that the first fragment of a fragmented tunneled packet will
include as close as possible to the IPv6 minMTU of 1280 bytes.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Templin, Fred L
> Sent: Tuesday, September 24, 2013 3:35 PM
> To: IPv6
> Subject: RFC4821 for tunnels using SEAL
> 
> Hi,
> 
> I have prepared an alpha implementation of SEAL that focuses
> on RFC4821 for tunnels:
> 
>     http://linkupnetworks.com/seal/sealv2-0.0.tgz
> 
> The code has been tested on Ubuntu 12.04 linux with the 3.10.12
> linux kernel. The release contains a README with instructions
> on how to reproduce the experiments.
> 
> The implementation has been tested with both IP/IPv6 and GRE/IPv6
> tunnels, and includes test scripts that can show the functionality
> using the Common Open Research Emulator (CORE):
> 
>     http://cs.itd.nrl.navy.mil/work/core/
> 
> The implementation inserts a SEAL shim header between the outer
> IPv6 header and the inner packet, and uses SEAL fragmentation
> and reassembly as follows:
> 
>   1) If the inner packet is no larger than 1280 bytes minus the
>      length of the encapsulation headers, encapsulate and send
>      without fragmentation.
> 
>   2) If the inner packet is larger than 1500 bytes but no larger
>      than the path MTU, encapsulate and send without fragmentation.
> 
>   3) For all other packets, encapsulate and use SEAL fragmentation
>      to break the packets into a size that should be small enough
>      to traverse the path without further fragmentation even if
>      there are other tunnels in the path. At the same time, probe
>      the path to see if packets of this size can be delivered without
>      fragmentation and, if so, discontinue the fragmentation process
>      and send future packets in this size range as whole packets.
> 
> The procedures are specified in 'draft-templin-intarea-seal', which
> can be found here:
> 
>     http://tools.ietf.org/html/draft-templin-intarea-seal
> 
> Any comments or observations would be welcome.
> 
> Thanks - Fred
> [email-masked]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Oct 2013 22:17:04 +0000

Hi, I had to make another change before putting this to rest. A new
version of the SEAL code is here:

http://linkupnetworks.com/seal/sealv2-0.2.tgz

and picks up the changes introduced in the -64 version of the spec:

http://www.ietf.org/id/draft-templin-intarea-seal-64.txt

The substantive change is that SEAL is now using the IP protocol
number for the IPv6 Fragment Header, and codes the Reserved field
of the Fragment Header to indicate that SEAL is being used. On
Wireshark, it looks just like an ordinary IPv6 Fragment Header,
but if you look closely the Reserved field has the value
"SEAL_VER1" encoded instead of set to 0.

Everything else works just as in the previous release. Only now,
there is no need for an experimental IP version number and no need
to bother IANA about assigning an official IP version number. This
is in fact simply a new version of the IPv6 fragment header. (That
it also gets used in IPv4 is somewhat interesting...)

Thanks - Fred

> Sent: Thursday, October 17, 2013 2:31 PM
> To: IPv6
> Subject: RE: RFC4821 for tunnels using SEAL
> 
> Hi,
>