[quagga-dev 11121] Re: [PATCH] ospf6d: account for IPv6 headers in MTU checks
John W. O'Brien
john at saltant.com
Mon Mar 24 23:34:07 GMT 2014
On 3/23/14 10:45 PM, David Lamparter wrote:
> On Sat, Nov 26, 2011 at 10:20:55AM -0500, John W. O'Brien wrote:
>> On 11/17/2011 01:05 PM, Dmitrij Tejblum wrote:
>>> John W. O'Brien wrote:
>>>> This patch accounts for the essential header only, and not for
>>>> permissible extra headers which can still induce fragmentation. A
>>>> complete resolution would require additional information from the
>>>> kernel which is not generally available.
>>> Yes, your fix looks correct. Actually, the very similar patch has been
>>> committed to the RE-testing-0.99 branch few months ago, but,
>>> unfortunately, it was not merged to master until now. I have just merged
>>> (The 'release engineering process' we follow is described at
>> Yes, I agree that the accepted patch  appears, upon inspection, to be
>> functionally identical to the patch I proposed, though I have not had
>> (and probably will not have for a while) a chance to test it. I also
>> appreciate that ospf6_packet_max() provides a desirable decoupling
>> point, for when Quagga learns how to discover the presence of extra headers.
> Aw, crap.
> Section A.1 of both RFCs 2740 and 5340 states:
> OSPF does not define a way to fragment its protocol packets, and
> depends on IPv6 fragmentation when transmitting packets larger than
> the link MTU. If necessary, the length of OSPF packets can be up to
> 65,535 bytes.
> Certainly we should try to keep packets below MTU where possible,
> however we can only do that if the particular case under consideration
> allows us some freedom in data scheduling, i.e. we can make a choice of
> what to include.
> This is not the case for Hello packets, and it is not the case for
> LSUpdates containing a single large LSA. I believe the correct
> behaviour would be:
> - ignore MTU for Hellos, send up to 65535 - 40(?) bytes.
> - in LSUpdates, ignore MTU check for the first LSA (i.e. always send at
> least one LSA, even if it goes beyond size and needs fragments)
> Can someone double-check and confirm above description? I may have
> overlooked something.
> Neither of the patches introduced this issue; I'm only replying to this
> here because I was going through patchwork #91 to mark it as Superseded.
Thank you for following up. I concur with your overall assessment.
For a Hello packet to grow that large would require a very large number
of neighbors indeed. In that event, and others like it, we would need to
prevent overflow of the packet length header field (are these checks
missing?). Furthermore, a maximally-sized OSPF packet would cause the
standard IPv6 length header to overflow, even without any extension
headers, and require the host to emit a Jumbogram.
In all cases where OSPF has some discretion about the number of
sub-packets to include, shall we interpret the RFC language---"IPv6
fragmentation should be avoided whenever possible"---to mean "if you
have a choice between inducing fragmentation or not inducing
fragmentation, do the latter, and if you have a choice between emitting
more fragments or emitting fewer fragments, also do the latter?" That
is, should a correct data scheduler check the MTU threshold for every
sub-packet, or only if fragmentation is not already assured?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 535 bytes
Desc: OpenPGP digital signature
More information about the Quagga-dev