Christian Hopps writes: > > Earlier there was also another encapsuluation mode called a Bound > > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and > > in that case it would have been impossible to detect the mode from the > > incoming packet, as lots of the information needed to reconstruct the > > end to end IP header is stored in the SA. > > > > Anyways we do store things in the IPsec SA when we create them, we do > > have negotiation mechanism to agree on those parameters and we can use > > them, we do not need to process things per packet basis. > > Are you saying that the next-header field is useless then?
Nope. It is needed for transport mode, and also for tunnel mode, where there are few possible values for it (4, 41, 59). > I mean the code I've worked on parses the next header field on a per > packet basis to handle the inner packet payload. In tunnel mode they most likely drop everything else than IP in IP, right? Or do they really start processing TCP packets inside tunnel mode SA? > I'm not interested in trying to redesign ESP with IPTFS, just use it > as provided. So if you want to define new version of ip in ip that allows encapsulating multiple ip packets inside one packet, then that should not be done in the IPsecME WG. IPv4 tunneling (protocol 4) was there long before IPsec, the IPv6 tunneling (protocol 41) was done by ipng wg etc. Neither one of those are done in the IPsec WG, but ESP are using them as they are useful things to do. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
