Technical Summary:
SEAL is a tunnel mechanism that includes ingress encapsulation,
egress decapsulation, and signalling between the ingress and
egress. It overcomes the limitations of implementing tunnels using
IP headers alone by introducing an adaptation layer with features
to address fragmentation/reassembly, source address spoofing, and
path MTU issues.
Working Group Summary:
Was the document considered in any WG, and if so, why was it not
adopted as a work item there?
The original SEAL RFC 5320 came out in Feb 2010.
This update is AD Sponsored, but was not the product of a WG.
SEAL has been taken to the INTAREA WG for consideration multiple
times, including its previous experimental version, but there has
been insufficient interest to accept this as a WG item.
I have been tracking this work since its beginnings, and consider
it to be a complete and thorough example of a correct way to do
tunneling. It addresses many of the weaknesses of existing tunnel
mechanisms, while focusing solely on only the features needed to
support tunneling.
Was there controversy about particular points that caused the WG to
not adopt the document?
There seems to be general appreciation for the work, but a
hesitation to either adopt or recognize it as a preferred
solution. I believe this is due to a lack of appreciation for the
significance of its contribution.
At various stages - both in the past version and this update - the
WG interacted and provided constructive feedback and suggestions
for improvement. To my knowledge, all such suggestions are included
and/or addressed sufficiently.
Document Quality:
Are there existing implementations of the protocol?
A pre-RFC5320 implementation is available here:
http://isatap.com/seal
There is no implementation of the currently proposed version that
this document describes.
Have a significant number of vendors indicated their plan to implement the specification?
There is no current implementation, and no plans for vendor
implementations has been presented or discussed.
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?
I have provided substantial feedback on this document, notably on
the relationship of SEAL reassembly IDs and IPv4 and IPv6 IDs,
which have been addressed. This includes a very thorough review
completed Oct. 1, 2012 of -49 updated with a "differences from
experimental SEAL" discussion. I provided extensive feedback which
was addressed in -50.
Substantial input has been provided by others also listed in the
Acknowledgements section, including Joel Halpern and Brian
Carpenter.
The differences between this version and the previous Experimental
version of RFC 5320 are noted in detail in Section 1.3.
If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)?
Not applicable.
In the case of a Media Type review, on what date was the request
posted?
Not applicable.
Personnel:
Who is the Document Shepherd?
Joe Touch
Who is the Responsible Area Director?
Ralph Droms
RFC Editor Note
(Insert RFC Editor Note here or remove section)
IRTF Note
(Insert IRTF Note here or remove section)
IESG Note
IANA Note
(Insert IANA Note here or remove section)