Brian, Thanks for the review. Please see responses, inline.....
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Brian Haberman > Sent: Tuesday, October 01, 2013 3:16 PM > To: [email protected]; 6man WG > Subject: AD Evaluation: draft-ietf-6man-oversized-header-chain > > All, > I have completed my AD evaluation for draft-ietf-6man-oversized- > header-chain. I found the document to be concise and well-written. > Thank you. > > I only have a few things I would like to see addressed prior to > starting an IETF Last Call on this document. > > 1. The 2nd paragraph of Section 4 (Motivation) could be made more > clear. > For example, you could indicate if the example first fragment does or > does not match the stateless firewall rule. It is inferred that the > first fragment does not match the target TCP port since it was dropped, > but I like to err on the explicit side. Does the following edit address your concern? 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 > As an aside, wouldn't the > subsequent fragments be dropped as well or does the IP destination > match the forward rule? They won't be dropped by the firewall filter because the firewall filter has no way of knowing the TCP port to which they are directed. (Remember, we are talking about a stateless firewall.) However, they will be dropped by the destination IP stack because they cannot be reassembled. > > 2. I would like to get some clarification on the rule in section 5 that > says "A host that receives a first-fragment that does not satisfy the > above-stated requirement SHOULD discard that packet". Can you provide > some justification for the SHOULD when you made it a MUST for a sending > node to ensure the upper-layer header is in the first fragment? Are > you assuming some flexibility to support compatibility with older > stacks? > If so, it would be good to have some guidance on what those stack > vendors should do. I agree. This should be a MUST. > > 3. Why is sending an ICMP error message a MAY? On second thought, this should be a SHOULD. So, we have the following change, addressing your second and third points: 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 MUST discard that packet, and also 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 > > 4. It would be better to be explicit that a host sending an ICMP error > message is sending the same ICMP error specified for > routers/middleboxes. Does the following change address your comment: 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 > > 5. I would suggest adding a reference to 2460 for the 1280 minimum MTU > value. Does the following change address your comment: 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 > > Regards, > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
