Brian,
This works for me. So, the complete list of changes follows. Do these work for
you?
Ron
CHANGES
=======
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
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>
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]).
<NEW
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
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
> -----Original Message-----
> From: Brian Haberman [mailto:br...@innovationslab.net]
> Sent: Wednesday, October 02, 2013 12:36 PM
> To: draft-ietf-6man-oversized-header-chain....@tools.ietf.org
> Cc: 6man WG
> Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain
>
> 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
> >
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
