IETF Logo Mail Archive

Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Ole Troan <otroan@employees.org> Wed, 16 October 2013 15:28 UTC

Return-Path: <otroan@employees.org>
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 7BC4A11E82D9; Wed, 16 Oct 2013 08:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Sb7eTdJmPvaH; Wed, 16 Oct 2013 08:28:57 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8291711E813A; Wed, 16 Oct 2013 08:28:57 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id F41D35F68; Wed, 16 Oct 2013 08:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=X3Ps8OuUulRCNLuJRt0OK Q88N+8=; b=WMFbI56VSPZrlcpiKgQM7N0yz5xtr+WQprYCJeN+8e0dzci4CV+bb 0odAokdVrXGqSwBGRjNLDDM3S2+sOHZ9dJS5yVmWkdRWM37Xhi3xvDR3O4J+rwhd FDG89KbcT5zKKxquGxnuC4oKXxAO7OWsqtJrAZ4qJDcICE7KBKhN9U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=oWy2Bfko4cK5QPY X2cUHLiQeM2i1/c1As3M3qJIDlDldFdcfkiCRGBMj4AQe8quouVRYlcRySh7qK7P si5e0qPCEHkZsNjz6QBWXvOYilXfHAIJFd5F3sUJlFkjP+3jmGBmwn4iChKbBvtf 8qSqYUCmOCVn2d1ux8MRlHAejGEI=
Received: from dhcp-10-61-106-123.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 16CB75F46; Wed, 16 Oct 2013 08:28:54 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_D90E7994-AC9C-4D8C-8234-D377D47CD6B4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
From: Ole Troan <otroan@employees.org>
In-Reply-To: <2134F8430051B64F815C691A62D9831812F4CA@XCH-BLV-504.nw.nos.boeing.com>
Date: Wed, 16 Oct 2013 17:28:52 +0200
Message-Id: <57E5A58E-0DAF-4545-8580-ACDB59475F46@employees.org>
References: <20131002185522.20697.96027.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831811EB23@XCH-BLV-504.nw.nos.boeing.com> <D1F5CE61-253E-4F07-AED1-4A4AB4C4AB68@employees.org> <2134F8430051B64F815C691A62D9831811EE66@XCH-BLV-504.nw.nos.boeing.com> <E29381FD-C839-4DBA-8711-3A4EBA83E379@employees.org> <2134F8430051B64F815C691A62D9831811EF1C@XCH-BLV-504.nw.nos.boeing.com> <5255D6EE.4050300@gmail.com> <2134F8430051B64F815C691A62D9831811F688@XCH-BLV-504.nw.nos.boeing.com> <5257AD5E.9090806@globis.net> <5257B870.1060003@si6networks.com> <2134F8430051B64F815C691A62D9831812C120@XCH-BLV-504.nw.nos.boeing.com> <52582F8B.8040306@si6networks.com> <52585658.50205@gmail.com> <2134F8430051B64F815C691A62D9831812C654@XCH-BLV-504.nw.nos.boeing.com> <52587EB8.4020506@gmail.com> <f0df0113f68045a1bdadf0155eae5e34@CO1PR05MB442.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D9831812D72D@XCH-BLV-504.nw.nos.boeing.com> <525DD007.8030100@si6networks.com> <2134F8430051B64F815C691A62 D9831812 F4CA@XCH-BLV-504.nw.nos.boeing.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.1510)
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, 6man Mailing List <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Ray Hunter <v6ops@globis.net>, Fernando Gont <fgont@si6networks.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 16 Oct 2013 15:28:58 -0000

Fred,

> To repeat what has already been said many times (and hopefully for
> just one final time), if the host is permitted to include an MTU-sized
> header chain and if there is a tunnel on the path that needs to fragment
> for whatever reason, then that header chain is going to spill into a
> second fragment. Then, middleboxes that wish to examine the entire
> header chain in the first fragment for whatever reason will be unable
> to do so. Consensus or no, those are the facts.

absolutely.

the outer IPv6 header is a new datalink for the inner IPv6 header. there is no architectural difference if that L2 is IPv6, IPv4 or PPP. take IPv4 or PPP as an example, if PPP provides fragmentation, then there is no expectation that the PPP or IPv4 layer keeps the payload IPv6 header chain in one PPP or IPv4 fragment.

the rules in this document are not recursive. the header chain terminates as soon as another IPv6 header is encountered.

does that clarification help?
I'm not quite sure if the document is clear enough on this point.

Best regards,
Ole

v2.35.0 | Report a Bug | By Email | System Status