On 08 Feb 2013, at 09:36 , Brian E Carpenter wrote: > Me too. TCP is also an encapsulating header; its contents > just don't happen to be encrypted. The draft's definition > of "Entire IPv6 header chain" uses TCP as an example: > > Note: If there is an upper layer header, only the header (and > not its payload) are considered part of the "entire IPv6 header > chain". For example, if the upper layer protocol is TCP, only > the TCP header (and not its possible data bytes) should be > considered part of the "entire IPv6 header chain". > > but I don't think it would be any different for ESP. > > However, I do see one point that is under-defined right now: > > **How many bytes of the transport header+payload are included in this > definition?** > > For ESP, is it 8 bytes (SPI + Sequence Number)?
I think that would be OK. Certainly it MUST NOT be more than those 8 bytes, because beyond there lies encrypted bits (in the general case). I actually believe that the SPI alone would suffice for ESP. > For TCP, is it 8 bytes (ports + Sequence Number)? My own sense is that Source Port and Destination Port, so 32 bits, actually would suffice, but I'll at least note one possible counter-argument: A firewall implementation might want to look at the TCP flags to check for invalid flag combinations. For UDP, my own sense is that the first 32 bits would suffice, although I don't see any harm in including the first 64 bits. I would have no objection to Fernando adding more detail for the obvious terminating payloads (e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft. Adding more clarity about this to the I-D could not hurt, and might help some implementers. Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------