Re: I-D Action: draft-herbert-6man-eh-limits-00.txt
Tom Herbert <tom@herbertland.com> Tue, 29 June 2021 15:09 UTC
Return-Path: <tom@herbertland.com>
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 68E0B3A371D for <ipv6@ietfa.amsl.com>; Tue, 29 Jun 2021 08:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqwgFQRS5bEq for <ipv6@ietfa.amsl.com>; Tue, 29 Jun 2021 08:09:19 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C36B3A371E for <ipv6@ietf.org>; Tue, 29 Jun 2021 08:09:18 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id v20so18386471eji.10 for <ipv6@ietf.org>; Tue, 29 Jun 2021 08:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3KDgZ6K8U41mDypRvvfiNxbCcDKI5F5qJTdXfNut7ME=; b=aqmLY95VG5DpXQ6DCG0bwSW9hP9S/hwVkVEXRseWXHafOI32rKEzcDOrs4f3u4yzTJ WCYZ2gSLWOBJjl8TmviuFh1Ja0VKxMgdQBGSE3V3uxNHL6ss0SzsY++Ve4X9J4BVqieQ u0tsANdIKy1xlDmlnZy/1+7EsHtcHOPFcdlVidD9KUKFrLa+/cslk0snemeL8bWEFAot K05/6u+nApxHRAUEW1P43FxA471kpV5UzqmTlawbo/p/38qc2LXhZjPWi8UO7vS1A1wK k2muhSePmeqtKx4dtFP+8KgZ48HuRkb++E2X9WG9stDA6nCW1I+rCnIM+Dup142cy6ie Y6zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3KDgZ6K8U41mDypRvvfiNxbCcDKI5F5qJTdXfNut7ME=; b=fMRy/fLIMAyfjk5aj/g2XBhCAq5o7x0JGLjoSir3D6aljGaSmCo9mmthIoq7s/Gsm1 RFEqJqEdSGzu9xdzI21FUoWX+F29lE6q6aUTMQNx6RXw8Ea+lgYmKfcrhcG388XUZDfw o8HsuFFC6wHXid4xRmdNEgHzGyBcBiefmWkCdlhsJy6GA1v/RU2iwpuV1e1Xcf+tO4z9 qOCjd3L6V0TKhWp36QZCgye6VUv6ZueNLpX8xwABnnJGYUxii5O4yXXHrRFti4AnIa8T hl25duqWJm82NZlZ1VXxFwrJllXZ6m/DmCjKma+Z33zgQbNknBugIW37e4JA1CIDGSQz xHLg==
X-Gm-Message-State: AOAM531YYS3XjHCxSfDh31wT1SsoMtz1tDkHI5YRK6C7YPVgDeTpXXpL dyYa3vh5MH+Hqc8Yn3CeflOIDpuW7ya6ZBKiYEmJNQ==
X-Google-Smtp-Source: ABdhPJyrQPd1P5XFE9mbXLDRfBVjiUS+Y/UNQOzuTdPAbmc9d/e86lDSLG/4ae6LQ5iUocKzuCouQ73fQe/+rDAoZGs=
X-Received: by 2002:a17:906:498b:: with SMTP id p11mr31050786eju.295.1624979356591; Tue, 29 Jun 2021 08:09:16 -0700 (PDT)
MIME-Version: 1.0
References: <162441011024.16699.3109899403536421779@ietfa.amsl.com> <380f8ddb-2b12-c7b2-b141-f6eaba06968a@gmail.com>
In-Reply-To: <380f8ddb-2b12-c7b2-b141-f6eaba06968a@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 29 Jun 2021 08:09:05 -0700
Message-ID: <CALx6S34TGkeD35MJZ9R4NtwJvaR8uG2KeVDoE7bRuqK9Xd0=Zw@mail.gmail.com>
Subject: Re: I-D Action: draft-herbert-6man-eh-limits-00.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/z6ZXrY3bebRZO2tnNf0s4AEe2KA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 29 Jun 2021 15:09:25 -0000
On Mon, Jun 28, 2021 at 4:23 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > I think the basic proposal is to limit extension headers to a total of 64 bytes, if outside a limited domain (TL;DR: see page 9 of the draft). > > Now, I'm well aware that shim6 (RFC5533) is not used; the main reason being that the Internet is largely opaque to its extension headers. Nevertheless, shim6 is a fully worked out use case for extension headers that would need to cross the open Internet. > > I wrote in 2016 as part of the RFC2460bis discussion that "I was surprised a while back to discover that a legal shim6 extension header could in fact exceed a kilobyte, specifically it is only limited to 1240 bytes by the standard." More to the point, a typical "large" shim6 extension header would be 40 bytes between dual-homed hosts. If hosts were more-than-dual-homed and therefore needed to exchange more addresses, the extension header would increase by 16 bytes per extra address. > > So, if we prescribed a 64 byte limit, we would also limit what extension headers can achieve. > Hi Brian, It is ironic, but it seems the only way to save extension headers is to limit them. This is a consequence of the robustness principle. For instance, if one sends a shim6 header of 1240 bytes into the Internet, there's a good chance the packet will be dropped by some intermediate node that needs to look at the transport layer but doesn't have capabilities to look deep into the packet. So sending a packet with 1240 bytes of extension headers to an arbitrary destination on the public Internet and expecting it to work probably isn't the best idea ;-). But, this implies there should be some acceptable number of bytes value N where 0 < N < 1240 (we want N > 0 lest extension headers are obsoleted). This draft suggests N be 64. As you point out, a greater limit could be applied when sending into a limited domain. More specifically, a greater limit could be applied if the sender has knowledge that all nodes in the path to a destination will accept packets that exceed the limit. There is a lot of latitude in how this knowledge is acquired, the sender may know that the whole path to the destination is confined to a limited domain, or the sender may use capabilities probing to the destination or have a priori information about the path (like from a mash-up map of capabilities of the Internet). The send clause of the robustness principle might be amended as "be conservative in what you send unless you possess knowledge that allows otherwise". The receive clause of the robustness principle is also pertinent, This draft states that all nodes MUST accept packets with sixty-four bytes of extension headers. Grant it, per RFC8200 all nodes are supposed to accept packets with extension headers up to the MTU, however it's pretty clear that is not sufficiently supported in reality. I believe that the sixty-four byte requirement is realistic for deployment (and it's much greater than zero byte limits, i.e. better than devices arbitrarily dropping packets with any extension header). There is precedent for limiting the number of bytes of extension headers that a sender can send. For instance, the number of bytes in extension headers in QUIC packets is limited. From RFC9000: "This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes." This follows the same philosophy of this draft, a baseline limit is established for sending into the Internet, and the limit can be exceeded if there is information that allows otherwise. In the case of QUIC the information that would allow sending more than thirty-two bytes of extension headers would be that the path MTU is greater than 1280 bytes. As for protocols that carry lists of IPv6 addresses, it's often been pointed out that constitutes considerable packet overhead (for example in discussions about SRv6)-- i.e. each IPv6 address in a packet represents 1% overhead in standard MTU. The answer to this seems to be to compress the list (like CRH for example). Tom > Regards > Brian > > On 23-Jun-21 13:01, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Limits on Sending and Processing IPv6 Extension Headers > > Author : Tom Herbert > > Filename : draft-herbert-6man-eh-limits-00.txt > > Pages : 18 > > Date : 2021-06-22 > > > > Abstract: > > This specification defines various limits that may be applied to > > receiving, sending, and otherwise processing packets that contain > > IPv6 extension headers. The need for such limits is pragmatic to > > facilitate interoperability amongst hosts and routers in the presence > > of extension headers and thereby increasing the feasibility of > > deployment of extension headers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-herbert-6man-eh-limits/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Re: I-D Action: draft-herbert-6man-eh-limits-00.t… Brian E Carpenter
- Re: I-D Action: draft-herbert-6man-eh-limits-00.t… Nick Hilliard
- Re: I-D Action: draft-herbert-6man-eh-limits-00.t… Tom Herbert