Have you considered having an E2E fragmentation header as an option of DCCP? Then:- All datagrams would fit in one packet when the option is used (=> no tricky performance problem in filtering devices). - The fragmentation header would be simpler than in your initial proposal below (just Identification, Fragment Offset, M). - Means already available to detect by negociation whether concerned nodes, only two in this case, support the option (incremental deployment). - Applicability in IPv4 and IPv6 without any required modification in the IP layer.
DCCP seems to me the right direction for graceful transmission of datagrams that exceed path MTUs through filtering devices.
Regards. Rémi Després Chip Popoviciu (cpopovic) le (m/j/a) 8/19/08 6:32 PM:
But if the HbH is present, the packet will hit the slow path anyway so performance penalties are there. If the HbH is not present then the first header will be the fragmentation header. Chip -----Original Message-----From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Tuesday, August 19, 2008 12:21 PMTo: Chip Popoviciu (cpopovic) Cc: v6ops Operations Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs On 19 aug 2008, at 18:17, Chip Popoviciu (cpopovic) wrote:Then might as well, put a fragment header on all packets so that routers do not have to cross EH for upper layer info and also make things work with ESP as well.:-)Regarding the position of the header, are you saying this header will be ahead of HbH?Well, that's the only way to avoid the current situation where filtering devices have to hunt for the UDP or TCP header, which they either don't do or incurs performance penalties...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next header |res|type |S/F|T| fragment offset |res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | observed packet length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+