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