Hi Ron, On 10/2/13 12:23 PM, Ronald Bonica wrote: > Hi Brian, > > So, merging in you last set of comments, the next draft version will include > the changes listed below. Please tell me if these work for you. > > Ron > > OLD> > For example, assume that a stateless firewall discards all traffic > received from an interface unless it destined for a particular TCP > port on a particular IPv6 address. When this firewall is presented > with a fragmented packet, and the entire header chain is contained > within the first fragment, the firewall discards the first fragment > and allows subsequent fragments to pass. Because the first fragment > was discarded, the packet cannot be reassembled at the destination. > Insomuch as the packet cannot be reassembled, the forwarding policy > is enforced. > <OLD > > NEW> > For example, assume that a stateless firewall discards all traffic > received from an interface unless it destined for a particular TCP > port on a particular IPv6 address. When this firewall is presented > with a fragmented packet that is destined for a different TCP port, > and the entire header chain is contained within the first fragment, > the firewall discards the first fragment and allows subsequent > fragments to pass. Because the first fragment was discarded, > the packet cannot be reassembled at the destination. Insomuch as > the packet cannot be reassembled, the forwarding policy is enforced. > <NEW >
Agreed.
> OLD>
> A host that receives a first-fragment that does not satisfy the
> above-stated requirement SHOULD discard that packet, and also MAY
> send an ICMPv6 error message to the source address of the offending
> packet (subject to the rules for ICMPv6 errors specified in
> [RFC4443]).
> <OLD
>
> NEW>
> By default, a host that receives a first-fragment that does not satisfy the
> above-stated requirement MUST discard that packet. However, host
> implementations
> may include a configuration option that allows them to accept such
> fragments.
>
> Furthermore, a host that receives a first-fragment that does not satisfy
> the
> above-stated requirement SHOULD send an ICMPv6 error message to the source
> address of the offending packet (subject to the rules for ICMPv6 errors
> specified in
> [RFC4443]).
> <NEW
>
The MUST+however confuses me. To me, that just reduces to a SHOULD.
How about:
A host that receives a first-fragment that does not satisfy the
above-stated requirement SHOULD discard the packet (e.g., including a
configuration option that allows such fragments to be accepted for
backwards compatibility) and SHOULD send an ICMPv6 error message to the
source address of the offending packet (subject to the rules for ICMPv6
errors specified in [RFC4443]).
?
> OLD>
> If a host or intermediate system discards a first-fragment because it
> does not satisfy the above-stated requirements, and sends an ICMPv6
> error message due to the discard, then the ICMPv6 error message MUST
> be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
> fragment has incomplete IPv6 Header Chain"). The Pointer field
> contained by the ICMPv6 Parameter Problem message MUST be set to
> zero.
> <OLD
>
> NEW>
> If a host or intermediate system discards a first-fragment because it
> does not satisfy the above-stated requirements, and sends an ICMPv6
> error message due to the discard, then the ICMPv6 error message MUST
> be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
> fragment has incomplete IPv6 Header Chain"). The Pointer field
> contained by the ICMPv6 Parameter Problem message MUST be set to
> zero. Whether a host or intermediate system originates this ICMP message,
> its format is identical.
> <NEW
>
Agreed.
> OLD>
> As a result of the above mentioned requirements, a packet's header
> chain length cannot exceed the Path MTU associated with its
> destination. Hosts MAY discover the Path MTU, using procedures such
> as those defined in [RFC1981] and [RFC4821]. However, if a host does
> not discover the Path MTU, it MUST limit the header chain length to
> 1280 bytes. Limiting the header chain length to 1280 bytes ensures
> that the header chain length does not exceed the IPv6 minimum MTU.
> <OLD
>
> NEW>
> As a result of the above mentioned requirements, a packet's header
> chain length cannot exceed the Path MTU associated with its
> destination. Hosts MAY discover the Path MTU, using procedures such
> as those defined in [RFC1981] and [RFC4821]. However, if a host does
> not discover the Path MTU, it MUST limit the header chain length to
> 1280 bytes. Limiting the header chain length to 1280 bytes ensures
> that the header chain length does not exceed the IPv6 minimum MTU [RFC
> 2460].
> <NEW
>
Agreed.
Regards,
Brian
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
