At 06:30 p.m. 21/08/2008, Black_David(_at_)emc(_dot_)com wrote:
(1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead.
Relevant portions of that draft should be reproduced or otherwise
explained in Section 3.2.
The reference to this I-D has been updated to the corresponding RFC.
As part of doing this, please state
whether trying v6 and v4 connections in parallel is a good idea or
not and why.
The document does not discuss alternative approaches, at it just
documents this alternative reaction to soft errors, as implemented in
a number of stacks.
(FYI, the draft originally aimed at Std. Track, and discussed other
alternative approaches for dealing with the problem of long delays
between conenction establishment attempts. Then we changed the draft
category to "Informational", to simply document this behavior. At
that point, the discussion of parallel connections and other
approaches was dropped).
(2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a
modified SYN when an RST is received in response to an ECN-setup SYN,
and suggests that this mechanism is applicable to ICMP errors received
in response to an ECN-setup SYN. This mechanism was specified in
RFC 3168 because there were known deployed middleboxes with this
problem-causing RST behavior, and the mechanism was necessary to deal
with them. Are there any known middleboxes that send an ICMP error
in response to a SYN that signals ECN capability?
- If yes, state the specific ICMP error(s) that is(are) used and limit
the recommendation to the actual error(s).
- If no, remove this entire RFC 3168 discussion as speculative, or
describe it as a possible response should this problem scenario
ever arise in practice.
I am particularly referring to firewalls, that can be configured to
reject incoming connections with either RST segment, ICMP error
messages, or silently.
Would your comment be addressed if I incorporate a small paragraph to
clarify this? The resulting text would read:
--- cut here ----
[RFC3168] states that a host that receives a RST in response to the
transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and
ECE cleared. This is meant to deal with faulty middle-boxes that
reject connections when a SYN segment has the ECE and CWR bits set.
Given that this section describes a modification that processes ICMP
error messages as hard errors when they are received for a connection
in any of the non-synchronized states, systems implementing this
behavior could resend the SYN segment with the ECE and CWR bits
cleared when an ICMP error message is received in response to a SYN
segment that had these bits set.
This would address those scenarios in which a middle-box such as a
firewall rejects incoming connection requests with an ICMP soft error
simply because the ECE and CWR bits were set in the incoming SYN segment.
---- cut here ----
(Only the last paragraph was added).
(3) Section 5.3 describes a NAT behavior that causes a host TCP problem
and then suggests changing the NAT to fix it. While that's a good idea
in an ideal world (and needs to be stated in the draft), in practice,
deployed NATs have to be dealt with as-is. In addition to recommending
fixing the NAT, please discuss what could be done when the NAT cannot
be fixed.
There's not much that could be done. However, this would just break
TCP simultaneous opens, that are unlikely. (As a matter of fact,
there are even end-system implementations of TCP that do not support
simultaneous opens)
Nits:
Section 1 - reduce generality of this text.
OLD:
This document analyzes the fault recovery strategy of TCP [RFC0793],
and the problems that may arise due to TCP's reaction to ICMP soft
errors.
NEW:
This document analyzes problems that may arise due to TCP [RFC0793]
fault recovery reactions to ICMP soft errors.
I have not incorporated this change. But please let me know if you
feel strongly about it.
It would be good to provide the text expansion of the codes in
Figure 1, as was done in the text before the figure.
I guess this would mess up the table, which is suppose to provide a
quick reference for extrapolating the ICMPv4 soft errors to their
ICMPv6 counter-parts. Therefore I have not incorporated this
suggested change. However, please let me know if you feel strongly about it.
In section 4, please provide the expansion of TCPM WG (TCP Maintenance
Working Group).
Fixed!
Please let me know if the above address your comments....
Thanks so much!
Kind regards,
--
Fernando Gont
e-mail: fernando(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf