Hi Fred, I think my SEAL summary V2 (msg05982) with your comments below is OK for now.
- Robin >> Adapting to changed PMTUs >> ------------------------- >> >> I am not sure if or where it is specified, but I understand that SEAL >> will allow exploration of increased PMTUs. According to RFC 1191 and >> therefore RFC 1981, the SH can try sending a longer packet than it >> has been told to send by a previous PTB, after 10 minutes has elapsed. > > This is discussed in SEAL, Section 4.3.5. >> Jumboframes >> ----------- >> >> "Jumbograms" refer to IPv6 packets with special formats so they can >> be longer than 2^16 bytes, and can be as long as 4 gigabytes. >> Neither SEAL, Ivip's IPTM, nor any CES proposal attempts to deal with >> these. >> >> See discussion in msg05979 and msg05981 - Fred writes that SEAL can >> accommodate jumbograms - but I can't see how. > > The draft talks about jumbograms and cites RFC2675. But, > it could probably benefit from a sentence or two telling > how the Jumbo Payload Option is processed. >> As far as I understand how SEAL would work, SEAL will be able to >> smoothly adapt to the appearance of jumboframe ~9k byte paths between >> ITEs and ETEs. > > Yes. >> For both IPv4 and IPv6, if the SH ignores PTBs, or if there is some >> filtering between the ITE and the SH which drops PTBs, then there's >> no way the SH is going to adapt its packets to the lengths required >> by SEAL to send them without fragmentation, segmentation or whatever. >> >> No CES architecture tries to cope with these problems - they must be >> fixed directly. >> >> As far as I know, SEAL does have "segmentation" capabilities - but >> these are not intended to be used within the IRON CES architecture. >> So SEAL's segmentation is no solution to this kind of failure of >> PMTUD. There's nothing to be done about this - the fault is in the >> SH and/or the filtering, so these need to be fixed. > > This discussion is not specific to SEAL nor even to > tunneling in general. If the SH is not accepting PTBs > from the gateway that connects the source's site to > the Internet, then there is a problem regardless of > the way in which the gateway connects. > > Thanks - Fred > [email protected] _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
