Hi Ron, Glad to hear you have had a look at SEAL, and see below for a few follow-up comments:
> -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Friday, August 09, 2013 4:32 AM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Fred, > > Quite to the contrary, I have spent a good deal of time reviewing the > SEAL draft. (Although I am now one version behind. The document is now > in version 61.) > > SEAL attempts to solve many problems. These include: > > - source address authentication I suppose it could be considered source address authentication in transport mode, but in tunnel mode it is about data origin authentication. When data origin authentication is enabled, the tunnel egress has a way of knowing when the tunnel ingress is authorized to tunnel a packet with source address S. But, the egress has no way of reaching back to the original source to know if it is authorized to source a packet with source address S. > - detection of packet duplication and reordering Yes, SEAL provides a well-behaved 32-bit packet sequence number which can be used by the tunnel far end to keep track of any duplicate or re-ordered packets. > - fragmentation at a layer above IP It is fragmentation at a layer above the outer IP protocol and below the inner IP protocol. However, cases in which both outer IP fragmentation and SEAL-layer fragmentation will be applied are exceedingly rare and will be tuned out as soon as they are detected. SEAL fragmentation uses the same header footprint as for IPv6 fragmentation, but the idea is that it would be used as a short-term facility to make sure the IPv6 minMTU is honored while arrangements are made to begin sending unfragmented packets. > - MTU discovery More like "MTU assistance". SEAL tries to do as little as possible to make sure that no path MTU black holes are exposed by virtue of tunneling while the original hosts still need to do PMTUD and/or PLPMTUD. SEAL "takes care of the smalls, and lets the bigs take care of themselves"; the original hosts will take care of those. > In order to solve all of these problems, SEAL invents good bit of > protocol machinery. Much of this machinery a) already exists at another > layer I'm not sure I get that. SEAL fragmentation would be used instead of IPv6 fragmentation to make sure that packets no larger than the minMTU make it through to the tunnel far end. SEAL fragmentation is in many ways a simplified version of IPv6 fragmentation and reuses most of the same code while avoiding the tiny fragment, overlapping fragment, etc. issues. > and b) is not required to solve the problem at hand. Wait, which problem are we talking about - transport mode or tunnel mode? I am no longer considering the transport mode case and have returned my focus to tunnel mode. Are you talking about transport mode or tunnel mode? > This makes > SEAL a much more heavyweight than the simple point solution that we > seek. It is no different than GRE plus fragmentation used sparingly and only as necessary. Thanks - Fred [email protected] > Ron > > > > > > SEAL solves the problem too. Transport-mode SEAL took me 15 minutes > to > > write, and is really just a couple of paragraphs. In addition to > > providing a universal sublayer that can handle any transport protocol > > 'X', SEAL also provides an RFC4821 path MTU probing facility. And, if > > ingress filtering is thought to be a problem, it also provides a data > > origin authentication facility. > > > > It seems Ron that you are trying to avoid a closer examination of > SEAL. > > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
