draft-ietf-6man-udpchecksums-02.txt
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 13 March 2012 20:47 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB821F86D7 for <ipv6@ietfa.amsl.com>; Tue, 13 Mar 2012 13:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.245
X-Spam-Level:
X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlM2Z-Uvtiys for <ipv6@ietfa.amsl.com>; Tue, 13 Mar 2012 13:47:14 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id D46AD21F86D8 for <6man@ietf.org>; Tue, 13 Mar 2012 13:47:10 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2DKl1oX001998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2012 20:47:01 GMT
Message-ID: <4F5FB248.6030407@erg.abdn.ac.uk>
Date: Tue, 13 Mar 2012 20:47:04 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: 6man@ietf.org
Subject: draft-ietf-6man-udpchecksums-02.txt
References: <4F5F0B41.8070705@erg.abdn.ac.uk>
In-Reply-To: <4F5F0B41.8070705@erg.abdn.ac.uk>
X-Forwarded-Message-Id: <4F5F0B41.8070705@erg.abdn.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Mailman-Approved-At: Tue, 13 Mar 2012 13:48:00 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2012 20:47:15 -0000
Marshall & Philip, I've read the new draft, and have a few new comments. Hope these are helpful - happy to discuss if this seems useful. Best wishes, Gorry ---- BOILER PLATE: - Please an Updates line:goprry "Updates RFC2460 (if approved)" ---- Section 3: "there is no additional benefit and indeed some cost to nodes to both compute and check the UDP checksum of the outer (encapsulating) header." - I do not think this sentence is really true, and I think it's important that we do get this right. I suggest there ARE benefits in performing a UDP integrity check for IPv6, see Section 3 of I-D.ietf-6man-udpzero. However, I agree that omitting this check can reduce the forwarding cost for systems that perform the check in software. ---- Section 3: "to set the checksum field of the outer header only to 0 and skip both the sender and receiver computation." - Could we insert a "UDP transport" between "outer" and "header" above, so there can be no confusion with the network layer headers. ---- Section 4: "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine (9) constraints on the usage of a zero checksum for UDP over IPv6. We agree with the restrictions proposed, and in fact proposed some of those restrictions ourselves in the previous version of the current draft. These restrictions are incorporated into the proposed changes below." - This reads rather like a paper. ietf-6man-udpzero is also a working group document, and I would like to think we can find better language. I suggest something like: "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements that introduce constraints on the usage of a zero checksum for UDP over IPv6. This document is intended to satisfy these requirements." ---- Section 4: "inspection firewall devices or other middleboxes actually checking" - remove "actually"? ---- Section 4: "This is would be an issue also for legacy systems which have not implemented the change in the IPv6 specification. So in any case, there may be packet loss of lightweight tunneling packets because of mixed new-rule and old-rule nodes." - Seems like it could be improved. I suggest: "This would be an issue also for any legacy IPv6 system that has not implemented the change to the IPv6 specification. In this case, the system will discard the zero-checksum UDP packets, and should log this as an error." ---- Section 4: " As an example, we discuss how can errors be detected and " ^^^ - remove "can" ---- Section 4: "Note that other (non-tunneling) protocols may have different approaches." - suggest replace add: ", but these are not the topic of this update." ---- Section 4: "The control packets can also contain any negotiation that is necessary to set up the endpoint/adapters to accept UDP packets with a zero checksum." - this needs to be enabled for each flow, so please add: "The control packets may also carry any negotiation that is necessary to set up the endpoint/adapters to identify the set of ports that need to enable reception UDP datagrams with a zero checksum." ---- Section 4: "Only UDP packets containing tunneled packets should have a UDP checksum equal to zero." - Please use keywords. e.g. "A system MUST NOT set the UDP checksum to zero in packets that do not contain tunneled packets." ---- Section 4: "We note that these outcomes not equally likely, as most require multiple bit errors with errored bits in separate fields. " - It seems wrong to suggest that single bit inversions are a likely cause of residual errors at the transport layer. I do not think this is the case. I suggest direct replacement of a sequence of bytes is a likely form of corruption. Suggest you omit the second part of the sentence? ---- Section 4: " If it is some other application, with very high probability, the application will not recognize the contents of the packet." - I disagree - it all comes down to applications design. The detection is only if the app is defined this way, since the transport does not know, etc. RFC 5405 provides recommended best current practice for applications in general. ---- Section 4: - I think the wording of this section needs to be tightened.It would be good to see more of a focus on what needs to be implemented, rather than discussing the guidance provided in the other working group document. If the guidance itself needs to be updated, then it would be good to explore this - We'd be happy to update the text and guidance if there is something more that should be said. ---- Section 5: " outer encapsulating packet of a lightweight tunneling protocol." - is it intentional to permit this only for *lightweight* tunneling protocols? - The initial request was for *any* tunneling protocol that meets the requirements. ---- Section 5: "UDP endpoints that implement this solution MUST change their behavior and not discard UDP packets received with a 0 checksum on the outer packet of tunneling protocols." - I think we really should add a few words about being enabled only for the set of ports that are supported by system for use by tunneling protocol(s). ---- Section 5: "its behavior should be as specified originally." - replace "should be as specified originally", by "is not updated and uses the method specified in RFC2460". ---- Section 6: " The persistence of this issue among a significant number of protocols being developed in the IETF requires a definitive policy." - Is this a recommendation for more work, or a statement of the motivation for this document. I was not sure. ---- Section 6: - I think it could be useful to include the points in section 6 possibly also as a part of ietf-6man-udpzero. What do you think? ---- I'd suggest we add a normative citation to RFC 5405, stating that this provides the IETF guidance on the design of applications using UDP and includes guidelines on the usage of checksums by application designers. - Possibly best placed in the introduction, indicating that this document adds to this for the case of tunneling applications. ---- -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683.
- draft-ietf-6man-udpchecksums-02.txt Gorry Fairhurst
- Re: draft-ietf-6man-udpchecksums-02.txt Marshall Eubanks
- Re: draft-ietf-6man-udpchecksums-02.txt gorry
- Re: draft-ietf-6man-udpchecksums-02.txt Marshall Eubanks
- Re: draft-ietf-6man-udpchecksums-02.txt gorry
- List name? [Re: draft-ietf-6man-udpchecksums-02.t… Brian E Carpenter
- Re: List name? [Re: draft-ietf-6man-udpchecksums-… Brian Haberman