<dec f='src/src/sys/netinet6/ip6_var.h' l='370' type='int frag6_input(struct mbuf ** , int * , int )'/>
<def f='src/src/sys/netinet6/frag6.c' l='117' ll='484' type='int frag6_input(struct mbuf ** mp, int * offp, int proto)'/>
<use f='src/src/sys/netinet6/frag6.c' l='490' u='c' c='ip6_reass_packet'/>
<doc f='src/src/sys/netinet6/frag6.c' l='86'>/*
 * IPv6 fragment input.
 *
 * In RFC2460, fragment and reassembly rule do not agree with each other,
 * in terms of next header field handling in fragment header.
 * While the sender will use the same value for all of the fragmented packets,
 * receiver is suggested not to check the consistency.
 *
 * fragment rule (p20):
 *	(2) A Fragment header containing:
 *	The Next Header value that identifies the first header of
 *	the Fragmentable Part of the original packet.
 *		-&gt; next header field is same for all fragments
 *
 * reassembly rule (p21):
 *	The Next Header field of the last header of the Unfragmentable
 *	Part is obtained from the Next Header field of the first
 *	fragment&apos;s Fragment header.
 *		-&gt; should grab it from the first fragment only
 *
 * The following note also contradicts with fragment rule - noone is going to
 * send different fragment with different next header field.
 *
 * additional note (p22):
 *	The Next Header values in the Fragment headers of different
 *	fragments of the same original packet may differ.  Only the value
 *	from the Offset zero fragment packet is used for reassembly.
 *		-&gt; should grab it from the first fragment only
 *
 * There is no explicit reason given in the RFC.  Historical reason maybe?
 */</doc>
<use f='src/src/sys/netinet6/in6_proto.c' l='326'/>
<use f='src/src/sys/netinet6/in6_proto.c' l='326'/>
<use f='src/src/sys/netinet6/in6_proto.c' l='326'/>
<use f='src/src/sys/netinet6/in6_proto.c' l='326'/>
