TSVDIR review, draft-ietf-v6ops-6to4-advisory

"Dan Wing" <dwing@cisco.com> Tue, 21 June 2011 23:16 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AFF22800D; Tue, 21 Jun 2011 16:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.339
X-Spam-Level:
X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x68+x1BVodv; Tue, 21 Jun 2011 16:16:55 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id F2996228006; Tue, 21 Jun 2011 16:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1767; q=dns/txt; s=iport; t=1308698214; x=1309907814; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=X746jxNlGlBvAXkMOb/itYXb1zr/mSBT8VchHM/fKs0=; b=HEN3+V+D/nvxN6vpDHWthcOoXa7UQIP3+5NGqTVab6xa4mT/gKLL3D/i adbzMKDGG5sIl9L3drTucOHuWWPILnc1YPzb3fQaQNXe+VWxiL3tS4nbv WqSzItSJN/GPfEmv1FBg/myYG/U1v2Q9S/YxrW2ssLehNjtRw7jcfJ9S0 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAMolAU6rRDoJ/2dsb2JhbABUmViNLneqO54ghioEhyKaag
X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="382680619"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 23:16:54 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNGshD008712; Tue, 21 Jun 2011 23:16:54 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Transport Directorate' <tsv-dir@ietf.org>, tsv-area@ietf.org
Subject: TSVDIR review, draft-ietf-v6ops-6to4-advisory
Date: Tue, 21 Jun 2011 16:16:54 -0700
Message-ID: <062b01cc3069$4f3144b0$ed93ce10$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwwaU7jlTWCqbL7RwmnF47+Qbjwnw==
Content-Language: en-us
Cc: 'David B Harrington' <dbharrington@comcast.net>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2011 23:16:55 -0000

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. The authors should consider this review together with any other
last-call comments they receive. Please always CC  tsv-dir@ietf.org if you
reply to or forward this review.

This document is ready to be published.  I have one small suggestion.  In
Section 3, it reads:

   5.  PMTUD Failure: A common link MTU size observed on the Internet
       today is 1500 bytes.  However, when using 6to4 the path MTU is
       less than this due to the encapsulation header.  Thus a 6to4
       client will normally see a link MTU that is less than 1500, but a
       native IPv6 server will see 1500.  It has been observed that Path
       MTU Discovery does not always work, and this can lead to
       connectivity failures.  Even if a TCP SYN/ACK exchange works, TCP
       packets with full size payloads may simply be lost.  This problem
       is apparently exacerbated in some cases by failure of the TCP MSS
       negotiation mechanism.  These failures are disconcerting even to
       an informed user, since a standard 'ping' from the client to the
       server will succeed, because it generates small packets, and the
       successful SYN/ACK exchange can be traced.  Also, the failure may
       occur on some paths but not others, so a user may be able to
       fetch web pages from one site, but only ping another.

this would benefit by adding an informational reference to RFC2923, "TCP
Problems with Path MTU Discovery"

-d