Skip to main content

TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-01-20
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-01-20
09 (System) IANA Action state changed to No IC from In Progress
2009-01-20
09 (System) IANA Action state changed to In Progress
2009-01-20
09 Amy Vezza IESG state changed to Approved-announcement sent
2009-01-20
09 Amy Vezza IESG has approved the document
2009-01-20
09 Amy Vezza Closed "Approve" ballot
2009-01-19
09 Lars Eggert State Changes to Approved-announcement to be sent from Waiting for AD Go-Ahead::AD Followup by Lars Eggert
2009-01-19
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-11-30
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-11-30
09 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-09.txt
2008-11-24
09 Jari Arkko
[Ballot comment]
Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding …
[Ballot comment]
Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Update Aug 2008: the IETF specs are still saying this, even
if implementations are not. Suggesting that the authors consider
stating some of the actual reality as well.
2008-11-24
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-09-19
09 Lars Eggert State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lars Eggert
2008-09-18
09 Lars Eggert gen-art comments need to be discussed before this document can move before the IESG
2008-08-26
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-08-13
09 Jari Arkko
[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice …
[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice quite important --
this problem is perhaps more important than any other problem for IPv6
deployment -- and hence requires careful review.

I have a few issues with the document, however.

First, I was unable to find any evidence of review from the 6MAN or V6OPS
communities. No request for review has been posted to the lists, at least.
Has there been such review, and if not, can we ensure it happens now?
Normally, in general and in particularly for Informational documents IETF
Last Call suffices, but as I outlined above, this specification is
important enough to warrant that we get it right.

Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Update Aug 2008: the IETF specs are still saying this, even
if implementations are not. Suggesting that the authors consider
stating some of the actual reality as well.
2008-08-12
09 Amy Vezza Last call sent
2008-08-12
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-08-12
09 Lars Eggert Last Call was requested by Lars Eggert
2008-08-12
09 Lars Eggert State Changes to Last Call Requested from IESG Evaluation::AD Followup by Lars Eggert
2008-08-12
09 Lars Eggert INT AD has asked for a second last call so that v6ops/6man/etc. can review this document.
2008-08-12
09 Lars Eggert Last Call was requested by Lars Eggert
2008-07-18
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sandra Murphy.
2008-07-18
09 (System) Removed from agenda for telechat - 2008-07-17
2008-07-17
09 Cindy Morgan State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan
2008-07-17
09 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-07-17
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-07-17
09 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Yes by Mark Townsley
2008-07-17
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-07-17
09 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley
2008-07-17
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-07-17
09 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2008-07-17
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-07-17
09 Jari Arkko
[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice …
[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice quite important --
this problem is perhaps more important than any other problem for IPv6
deployment -- and hence requires careful review.

I have a few issues with the document, however.

First, I was unable to find any evidence of review from the 6MAN or V6OPS
communities. No request for review has been posted to the lists, at least.
Has there been such review, and if not, can we ensure it happens now?
Normally, in general and in particularly for Informational documents IETF
Last Call suffices, but as I outlined above, this specification is
important enough to warrant that we get it right.

Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Section 3.2 says:

  In scenarios where a node has no default routers and Neighbor
  Unreachability Detection (NUD) [RFC4861] fails for destinations
  assumed to be on-link, or where firewalls or other systems that
  enforce scope boundaries send ICMPv6 errors, the sending node will be
  signaled of the unreachability problem.  However, as discussed in
  Section 2.2, standard TCP implementations will not abort connections
  when receiving ICMP error messages that indicate soft errors.

Clarity. This is somewhat misleading. When the node has no default
routers it also has no prefixes, no global addresses and it will not
even try to use IPv6 towards other global addresses. That is not a soft
error situation as described by this document.
2008-07-17
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-07-16
09 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings
2008-07-16
09 Russ Housley
[Ballot discuss]
I have not seen a response to the comments in the SecDir Review
  by Sandy Murphy posted on 15-07-2007.  The comments deserve …
[Ballot discuss]
I have not seen a response to the comments in the SecDir Review
  by Sandy Murphy posted on 15-07-2007.  The comments deserve a
  response, even if the discussion does not result in any changes
  to the document.
2008-07-16
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-07-16
09 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza
2008-07-14
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-07-11
09 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-07-01
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2008-07-01
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2008-06-30
09 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-06-30
09 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2008-06-30
09 Lars Eggert Ballot has been issued by Lars Eggert
2008-06-30
09 Lars Eggert Created "Approve" ballot
2008-06-30
09 Lars Eggert Tentatively on the agenda for 2008-7-17.
2008-06-30
09 Lars Eggert Placed on agenda for telechat - 2008-07-17 by Lars Eggert
2008-06-30
09 Lars Eggert State Changes to Last Call Requested from AD Evaluation by Lars Eggert
2008-06-30
09 Lars Eggert Last Call was requested by Lars Eggert
2008-06-30
09 (System) Ballot writeup text was added
2008-06-30
09 (System) Last call text was added
2008-06-30
09 (System) Ballot approval text was added
2008-06-30
09 Lars Eggert State Change Notice email list have been change to weddy@grc.nasa.gov, david.borman@windriver.com, tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org from tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org
2008-06-30
09 Lars Eggert [Note]: 'Document Shepherd: Mark Allman (mallman@icir.org)' added by Lars Eggert
2008-06-30
09 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2008-06-30
09 Lars Eggert State Change Notice email list have been change to tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org from tcpm-chairs@tools.ietf.org
2008-06-30
09 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2008-06-30
09 Cindy Morgan
draft-ietf-tcpm-tcp-soft-errors-08.txt
>
>>  (1.a)  Who is the Document Shepherd for this document?  Has the
>>          Document Shepherd personally reviewed this version …
draft-ietf-tcpm-tcp-soft-errors-08.txt
>
>>  (1.a)  Who is the Document Shepherd for this document?  Has the
>>          Document Shepherd personally reviewed this version of
>>          the document and, in particular, does he or she believe
>>          this version is ready for forwarding to the IESG for
>>          publication?
>
> Mark Allman (mallman@icir.org) (TCPM co-chair)
>
> I have read the document and believe it is ready for publication.
>
>>  (1.b)  Has the document had adequate review both from key WG 
>> members
>>          and from key non-WG members?  Does the Document Shepherd 
>> have
>>          any concerns about the depth or breadth of the reviews that
>>          have been performed?
>
> The document has enjoyed much review from the TCPM WG.
>
>>  (1.c)  Does the Document Shepherd have concerns that the document
>>          needs more review from a particular or broader perspective,
>>          e.g., security, operational complexity, someone familiar 
>> with
>>          AAA, internationalization or XML?
>
> No concerns.
>
>>  (1.d)  Does the Document Shepherd have any specific concerns or
>>          issues with this document that the Responsible Area Director
>>          and/or the IESG should be aware of?  For example, perhaps he
>>          or she is uncomfortable with certain parts of the 
>> document, or
>>          has concerns whether there really is a need for it.  In any
>>          event, if the WG has discussed those issues and has 
>> indicated
>>          that it still wishes to advance the document, detail those
>>          concerns here.  Has an IPR disclosure related to this 
>> document
>>          been filed?  If so, please include a reference to the
>>          disclosure and summarize the WG discussion and conclusion on
>>          this issue.
>
> This document involves no IPR disclosure.
>
> The document shepherd has no specific concerns about the document.
>
>>  (1.e)  How solid is the WG consensus behind this document?  Does it
>>          represent the strong concurrence of a few individuals, with
>>          others being silent, or does the WG as a whole understand 
>> and
>>          agree with it?
>
> The WG consensus on this document is broad and solid.
>
>>  (1.f)  Has anyone threatened an appeal or otherwise indicated 
>> extreme
>>          discontent?  If so, please summarise the areas of conflict 
>> in
>>          separate email messages to the Responsible Area Director. 
>> (It
>>          should be in a separate email because this questionnaire is
>>          entered into the ID Tracker.)
>
> We are aware of no reasons this document would be appealed or anyone
> who is overly unhappy with it.
>
> The biggest bone of contention about this draft was that, while
> aiming for informational status, initially was quite prescriptive in
> its language.  The language now is not prescriptive, but rather
> simply documents the behavior of some popular TCP stacks.
>
>>  (1.g)  Has the Document Shepherd personally verified that the
>>          document satisfies all ID nits?  (See
>>          http://www.ietf.org/ID-Checklist.html and
>>          http://tools.ietf.org/tools/idnits/).  Boilerplate checks 
>> are
>>          not enough; this check needs to be thorough.  Has the 
>> document
>>          met all formal review criteria it needs to, such as the MIB
>>          Doctor, media type and URI type reviews?
>
> This document does not need MIB or URI reviews.
>
> The document passes 'idnits'.
>
>>  (1.h)  Has the document split its references into normative and
>>          informative?  Are there normative references to documents 
>> that
>>          are not ready for advancement or are otherwise in an unclear
>>          state?  If such normative references exist, what is the
>>          strategy for their completion?  Are there normative 
>> references
>>          that are downward references, as described in [RFC3967]?  If
>>          so, list these downward references to support the Area
>>          Director in the Last Call procedure for them [RFC3967].
>
> The references have been split into 'normative' and 'non-normative'.
>
> The normative references are all published RFCs.
>
>>  (1.i)  Has the Document Shepherd verified that the document IANA
>>          consideration section exists and is consistent with the body
>>          of the document?  If the document specifies protocol
>>          extensions, are reservations requested in appropriate IANA
>>          registries?  Are the IANA registries clearly identified?  If
>>          the document creates a new registry, does it define the
>>          proposed initial contents of the registry and an allocation
>>          procedure for future registrations?  Does it suggest a
>>          reasonable name for the new registry?  See [RFC2434].  If 
>> the
>>          document describes an Expert Review process has Shepherd
>>          conferred with the Responsible Area Director so that the 
>> IESG
>>          can appoint the needed Expert during the IESG Evaluation?
>
> The document has an IANA considerations section that correctly notes
> that no IANA work is needed.
>
>>  (1.j)  Has the Document Shepherd verified that sections of the
>>          document that are written in a formal language, such as XML
>>          code, BNF rules, MIB definitions, etc., validate correctly 
>> in
>>          an automated checker?
>
> N/A
>
>>  (1.k)  The IESG approval announcement includes a Document
>>          Announcement Write-Up.  Please provide such a Document
>>          Announcement Write-Up?  Recent examples can be found in the
>>          "Action" announcements for approved documents.  The approval
>>          announcement contains the following sections:
>>
>>          Technical Summary
>>            Relevant content can frequently be found in the abstract
>>            and/or introduction of the document.  If not, this may be
>>            an indication that there are deficiencies in the abstract
>>            or introduction.
>>
>>          Working Group Summary
>>            Was there anything in WG process that is worth noting? 
>> For
>>            example, was there controversy about particular points or
>>            were there decisions where the consensus was particularly
>>            rough?
>>
>>          Document Quality
>>            Are there existing implementations of the protocol? 
>> Have a
>>            significant number of vendors indicated their plan to
>>            implement the specification?  Are there any reviewers 
>> that
>>            merit special mention as having done a thorough review,
>>            e.g., one that resulted in important changes or a
>>            conclusion that the document had no substantive 
>> issues?  If
>>            there was a MIB Doctor, Media Type or other expert 
>> review,
>>            what was its course (briefly)?  In the case of a Media 
>> Type
>>            review, on what date was the request posted?
>
> Technical Summary:
>
>    The TCP specification calls for calls for ICMP soft errors to be
>    treated as transient and therefore TCP connections will not
>    abort in response to such messages.  A widely implemented
>    departure from the specification has TCP stacks treating such
>    soft errors as hard errors and aborting connections during
>    connection establishment.
>
> Working Group Summary
>
>    The WG could not arrive at consensus for changing the TCP
>    specification to allow ICMP soft errors to be treated as hard
>    errors during connection establishment.  However, this change is
>    widely implemented.  This document describes the change in an
>    informational way.
>
> Document Quality
>
>    The document was reviewed for quality by a large number of TCPM
>    WG members.
2008-04-23
08 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-08.txt
2007-12-26
07 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-07.txt
2007-06-25
06 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-06.txt
2007-04-04
05 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-05.txt
2007-03-22
04 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-04.txt
2007-01-25
03 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-03.txt
2006-10-09
02 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-02.txt
2006-08-08
01 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-01.txt
2006-03-20
09 Lars Eggert Shepherding AD has been changed to Lars Eggert from Allison Mankin
2006-03-19
09 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-02-24
00 (System) New version available: draft-ietf-tcpm-tcp-soft-errors-00.txt