From nobody Fri Jun 7 00:14:02 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA212017E for ; Fri, 7 Jun 2019 00:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0VBgEZ2p1jtn for ; Fri, 7 Jun 2019 00:13:59 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5D312008B for ; Fri, 7 Jun 2019 00:13:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CE2BA7C3658; Fri, 7 Jun 2019 09:13:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtcMbddonGnv; Fri, 7 Jun 2019 09:13:54 +0200 (CEST) Received: from [192.168.3.141] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id C2E897C360F; Fri, 7 Jun 2019 09:13:54 +0200 (CEST) To: Davey Song , xml2rfc@ietf.org References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <645d1a94-5ade-9c33-0ec9-46bc3646a959@alvestrand.no> Date: Fri, 7 Jun 2019 09:13:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------684891ADEC4B11AFE0986DB1" Content-Language: en-GB Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 07:14:01 -0000 This is a multi-part message in MIME format. --------------684891ADEC4B11AFE0986DB1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit My guess is that he didn't upload the XML in the first place. Try emailing Johan. On 5/30/19 1:52 PM, Davey Song wrote: > Hi folks, > > I'm not sure if it is the best place to ask this question. But it is > appreciated if you can help. >   > The reference xml file line is not available for a expired draft.  > https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ihren-dnsext-threshold-validation-01.xml   > > The online draft is here > :https://tools.ietf.org/html/draft-ihren-dnsext-threshold-validation-01 > > Anything wrong with this draft? > > Best regards, > Davey > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc -- Surveillance is pervasive. Go Dark. --------------684891ADEC4B11AFE0986DB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
My guess is that he didn't upload the XML in the first place.

Try emailing Johan.

On 5/30/19 1:52 PM, Davey Song wrote:
Hi folks,

I'm not sure if it is the best place to ask this question. But it is appreciated if you can help.

Anything wrong with this draft?

Best regards,
Davey

_______________________________________________
xml2rfc mailing list
xml2rfc@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc



-- 
Surveillance is pervasive. Go Dark.
--------------684891ADEC4B11AFE0986DB1-- From nobody Fri Jun 7 00:37:13 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA812017A for ; Fri, 7 Jun 2019 00:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cABsQ1HuGauI for ; Fri, 7 Jun 2019 00:37:09 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674D012013D for ; Fri, 7 Jun 2019 00:37:09 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45KvVq13wdzyfb; Fri, 7 Jun 2019 09:37:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jun 2019 09:37:06 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 581585824.662802-dd91bc63ea80ba0f0f6b4effca349509 Content-Transfer-Encoding: quoted-printable Message-Id: <6F0B5BD9-9547-4EF4-9C14-34435080B43F@tzi.org> References: To: Davey Song X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 07:37:12 -0000 Unless you want to specifically reference the version -01, you should be = using the =E2=80=9Cseries=E2=80=9D URL: = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihren-dnse= xt-threshold-validation.xml Now, interestingly, both = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ihre= n-dnsext-threshold-validation-00.xml and = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ihre= n-dnsext-threshold-validation-01.xml are 404, which sounds like a daemon didn=E2=80=99t do its job properly = some time in 2004. (Compare with, say,=20 = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf= -cbor-cddl-00.xml To = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf= -cbor-cddl-08.xml As well as = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cbor-= cddl.xml which are the version-specific references as well as the series one. = Note that these all anchor to I-D.ietf-cbor-cddl, so you cannot have = multiple version specific references to the same draft or one of these = and the series reference in the same document unless you rewrite, e.g., = the way kramdown-rfc can do for you.) > On May 30, 2019, at 13:52, Davey Song wrote: >=20 > Hi folks, >=20 > I'm not sure if it is the best place to ask this question. But it is = appreciated if you can help. > =20 > The reference xml file line is not available for a expired draft.=20 > = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ihre= n-dnsext-threshold-validation-01.xml =20 >=20 > The online draft is here = :https://tools.ietf.org/html/draft-ihren-dnsext-threshold-validation-01 >=20 > Anything wrong with this draft? >=20 > Best regards, > Davey > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Fri Jun 7 05:51:14 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316BB12026A for ; Fri, 7 Jun 2019 05:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jttL42LxoCVR for ; Fri, 7 Jun 2019 05:51:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435AC12021C for ; Fri, 7 Jun 2019 05:51:07 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53032 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hZEKo-0005Dd-Bp; Fri, 07 Jun 2019 05:51:06 -0700 To: Davey Song , xml2rfc@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Fri, 7 Jun 2019 14:50:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E7IAjpvLq1U5qqdqjmp5AEpLOsrngJGa5" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, songlinjian@gmail.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 12:51:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E7IAjpvLq1U5qqdqjmp5AEpLOsrngJGa5 Content-Type: multipart/mixed; boundary="OrkgxDalDkTkg4KksJdl78LJNWE195aEo"; protected-headers="v1" From: Henrik Levkowetz To: Davey Song , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft References: In-Reply-To: --OrkgxDalDkTkg4KksJdl78LJNWE195aEo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Davey, On 2019-05-30 13:52, Davey Song wrote: > Hi folks, >=20 > I'm not sure if it is the best place to ask this question. But it is > appreciated if you can help. >=20 > The reference xml file line is not available for a expired draft. > https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-i= hren-dnsext-threshold-validation-01.xml That URL is not the proper one for the reference you want. It should not= contain the 'draft-' part after '.I-D.'. The correct URL is: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihren-dn= sext-threshold-validation.xml Regards, Henrik --OrkgxDalDkTkg4KksJdl78LJNWE195aEo-- --E7IAjpvLq1U5qqdqjmp5AEpLOsrngJGa5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlz6XbIACgkQTptXS4+7 FxqtXBAArozJZWxc6jU9yxwldjr9ejiC7Ep7S/xKuTtASg/owaycEouBYbSGfzFl YIPf6T5lYMDP8pgC9Wm48P29GWvgG4nxkKZUqzbfeBfnNcrRxdReRPiBWlp7EAKA HOHZRWM/Mfh1DsPLdmRumyakAKeCqA3S6onn3jzz98aNjExCtLDZXcwbanb0Rhye HBgb6EU9L/ZI3mcM9lfc2wCuQqBFWme22ZP2c15G6jQonrqOf7kAXqPt8ssEIL48 29Tjmi50vLsrQa/QNgseeizdfZJseFoJg0pUNQKWuSRqG2lgU0QR5M3yLgESHlnA FaE8dIfhLcFyTjWdBoMBAcvMu7ngF0H9wAnBNN7/NBEk2oZAeaiQdE25aF5bJt6x 0BCQ4lgaG2B4dRYuFgHMP9oNA9AklEpZ937MWlK/UxY9ejCikrN3NwOqpU4t4JzS 8yAglhaYri8xpOFO1S/WUUvf5Qn+cNFQOlEyzYRr2sEZ0J9RG0YTxDTFWlIF5zwP EcMV9WOHrq05unaM/uRQQgVR1i9I3sNe7ndMKr2AFnY6JfIG9JgFJfrYuaWDN80J fB6fyCnhhYjBMpjBBa4vMpra9zopIOItMSuZ+s5ijjoXoPpcnyKCY0qLTzfTNjQj IkC7iCRrQ0ERsYIgtdS7dgEe/0CVSflDh/Uy9Lt3KhyRxXbFQXM= =5xb4 -----END PGP SIGNATURE----- --E7IAjpvLq1U5qqdqjmp5AEpLOsrngJGa5-- From nobody Fri Jun 7 06:30:30 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02791200B1 for ; Fri, 7 Jun 2019 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QeE60DH_W7Vb for ; Fri, 7 Jun 2019 06:30:26 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A56120058 for ; Fri, 7 Jun 2019 06:30:26 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45L3LS38n2zypK; Fri, 7 Jun 2019 15:30:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jun 2019 15:30:23 +0200 Cc: Davey Song , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 581607020.552719-646954f16ea047c0faaab49781e6b3b9 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 13:30:29 -0000 On Jun 7, 2019, at 14:50, Henrik Levkowetz wrote: >=20 >> The reference xml file line is not available for a expired draft. >> = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ihre= n-dnsext-threshold-validation-01.xml >=20 > That URL is not the proper one for the reference you want. It should = not > contain the 'draft-' part after '.I-D.'. The correct URL is: >=20 > = https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihren-dnse= xt-threshold-validation.xml That is one correct reference URL, but the previous one also is =E2=80=94 = as a way to reference a specific version of a draft. I showed this in = the examples in the previous message. =20 Not sure that Davey actually wants this and didn=E2=80=99t use the = version-specific variant by accident. But the question remains why the = version-specific variants aren=E2=80=99t there for this particular = draft. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jun 7 07:33:32 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FEF12015D for ; Fri, 7 Jun 2019 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7jHP6u6iZhzK for ; Fri, 7 Jun 2019 07:33:28 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BF6120158 for ; Fri, 7 Jun 2019 07:33:13 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45L4kv08Dgzyqv; Fri, 7 Jun 2019 16:33:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jun 2019 16:33:09 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 581610787.995455-0a67be7d0af506e6d6111a0693319cee Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 14:33:31 -0000 On Jun 7, 2019, at 15:30, Carsten Bormann wrote: >=20 > But the question remains why the version-specific variants aren=E2=80=99= t there for this particular draft. Quickly looking at the directory: Of 27455 I-D series I can find, 6071 = do not have any version-specific reference files. Didn=E2=80=99t check = for completeness of those which did have at least one (but they sure = seem to have gaps). There seem to be no version-specific reference = files without a corresponding series reference file. Haven=E2=80=99t = analyzed further. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jun 7 07:56:32 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3A120177 for ; Fri, 7 Jun 2019 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 riXsR8FzJUge for ; Fri, 7 Jun 2019 07:56:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F3B120113 for ; Fri, 7 Jun 2019 07:56:28 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53347 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hZGI7-0008Fb-1M; Fri, 07 Jun 2019 07:56:28 -0700 To: Carsten Bormann References: Cc: Davey Song , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <62235f14-0a01-56ca-3bf4-89aec24565b5@levkowetz.com> Date: Fri, 7 Jun 2019 16:56:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pk5bdGQ47dR2vgwnNrq3PRTsKa9e1jlD6" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, songlinjian@gmail.com, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 14:56:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pk5bdGQ47dR2vgwnNrq3PRTsKa9e1jlD6 Content-Type: multipart/mixed; boundary="EItpEk20V2bu702Nx19nfESrSkpKmDuxq"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: Davey Song , xml2rfc@ietf.org Message-ID: <62235f14-0a01-56ca-3bf4-89aec24565b5@levkowetz.com> Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft References: In-Reply-To: --EItpEk20V2bu702Nx19nfESrSkpKmDuxq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On 2019-06-07 15:30, Carsten Bormann wrote: > On Jun 7, 2019, at 14:50, Henrik Levkowetz wrote= : >>=20 >>> The reference xml file line is not available for a expired draft. >>> https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft= -ihren-dnsext-threshold-validation-01.xml >>=20 >> That URL is not the proper one for the reference you want. It should = not >> contain the 'draft-' part after '.I-D.'. The correct URL is: >>=20 >> https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihren-= dnsext-threshold-validation.xml >=20 > That is one correct reference URL, but the previous one also is =E2=80=94= as > a way to reference a specific version of a draft. I showed this in > the examples in the previous message. Right. Sorry. > Not sure that Davey actually wants this and didn=E2=80=99t use the > version-specific variant by accident. But the question remains why > the version-specific variants aren=E2=80=99t there for this particular > draft. The sources used by the script that generates the reference .xml files aren't available, so I can't check this, but one possibility would be that the datatracker, when generating the 1id-abstracts.txt file at the time, used Johan's surname with a non-ascii character: Ihr=C3=A9n, and th= at botched the creation of the reference file. Inspection of the bibxml3 directory makes me think there must be a differ= ent cause, though, as I see that for year 2004, there are 1365 reference file= s of the generic kind, not using 'draft-' in the name, while I see only 25 version-specific reference files. Henrik --EItpEk20V2bu702Nx19nfESrSkpKmDuxq-- --pk5bdGQ47dR2vgwnNrq3PRTsKa9e1jlD6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlz6exMACgkQTptXS4+7 FxrUYBAAoiWH2tQyMmZuzk9pg9OcVtOgNXFMom4SqzI7geb7g59xhSeFQz6JkwqS zWqYV07crm/s4Vbh1wrfOPYkl8MA82sYwH48kVCQV0Rrx+9DKmpXvAFs82JSEoV3 ugop6Q/ikmBSua+yrcdNGTSruh4aTxV1ju3RWJLpD/G0+4RQmumtfYowSeB6IMYR IuIEJhXRQn4zo771c9J5s7ETCYbxwFyhRaCjTBzOROwWoS7rK12M4d2RJp/twPCp qr35l1ttrypGzlWPYTVzIZt6QNF9BCmEmMPRq+xJ9LgZL6/8RckcveMdqMV1W4uj bH/y/Qh9sAsVtadi6b4aqYIlpWTL//ZJqAwLvyPtfuPeDj3lZdtObO3BSjW6kOFS AOlgQOaUkDqYmCOUBJYzwBj12fHOZ9kLHFthh/cTyx5iGzBVFOlhigaJQCaXgagj hXk1wmHoRu8TJY5OKZT89xG367rP8zq50wt/e2RPoM0o1J0hdyAfgtkg17bpyxbd AlrP8nm2RPCGIYlkt8PdAp3d3icNOy8cSlN0uU3XTYYFRaaCM96sUAPxTMwrEBHf FBGmQ4tJ+nELfcnUnDSmId7ahSBGL0m3/171drMxX6ZhRcyESG2P2NMtiTlEq/4c 0gtnHLEfUCo7lC3UGaTmEyB68gWk5xDQBRuS7IyvehQinnv7qzE= =Iumc -----END PGP SIGNATURE----- --pk5bdGQ47dR2vgwnNrq3PRTsKa9e1jlD6-- From nobody Thu Jun 20 03:33:50 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403AC120090 for ; Thu, 20 Jun 2019 03:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5Ybv3lKY1eZT for ; Thu, 20 Jun 2019 03:33:45 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 D2201120073 for ; Thu, 20 Jun 2019 03:33:44 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id m29so2730931qtu.1 for ; Thu, 20 Jun 2019 03:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=392Ml/7DEzu8Crrfw231UV/4Gw8gil+jSgmJIv9Bjss=; b=kr5WJuyuvOJya+1Si+BggnfZAfLPkd3DrfsT0CNTWSAfaK9LVe67etqRfuSxB4egSv MfzHGMj/1CzXc7DUYn07qIXFhrBQhYzaS7q4z6dSeEa3qVPaQ6aTInTyDMKqjpoVm05b F4ryFsAxubM9jAf71ZnrfJR7PFVZsdVECagmHMEkteNlJ/nA2thnrj3cYIuK/If1EbdH BYO9V9aR1E4yQiIPumtNYT7U+vBJl7XIy/c2XmZaxI63hllHlJNRlnd4LPy/ahxQ/D7b IPGYGO0caCNxcBtopVknwHMNiofdQLr+QTMv+q07B9PppZ6m6YRjrlhlPDXMXug4XkwB Vt8A== 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; bh=392Ml/7DEzu8Crrfw231UV/4Gw8gil+jSgmJIv9Bjss=; b=pKqk4dVPzX40veeUCRx5U/2I1FU0D2FHpGJCPzWAEaZMjiPmLh6A0iaUjhg3G7kT0U ebcimDnvU6Rx+4TpyRO3+fd2k5qjAxZjE9m8uqCt7GpMlmDcWUHV9iL5FKbh49lxdStc hlujIVaq4UqS+MbPGSjhf/EvutR0hgXOLv6m5P8Ey2AXWQ1kcqGMvQ8dr0eUWw+L7nTw cRILkbAu8b7Tz6KTR50cE9bWkUVRProkxQ7QTcJ0YnUBWjmq//0XRCt+mcEoW0CaZ7aq KjvfwiIINVZdvVCUmplgDaBmHaQTRv+EKWpsJo4p1LgwouTNvqiGOvrwFxbEpwFuKkdw ipyA== X-Gm-Message-State: APjAAAU+op7b7+2z/Xt7Bg1zDsrS4OLdHCEIWyTRNS0j+adX0Tf08ome PSJOyPK7RDYuCVevI99PfzaqyX3aFrDi7s7qxm4SSb7ftGg= X-Google-Smtp-Source: APXvYqwDeo05EYZTWRrtDjQW/ldG6MT23SWm3+tFHjayayfJ779A0yarkXAXMp5usWxKVO+hiTcu+pvrSap8VdgMlh0= X-Received: by 2002:ac8:3078:: with SMTP id g53mr108215529qte.126.1561026823903; Thu, 20 Jun 2019 03:33:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davey Song Date: Thu, 20 Jun 2019 18:33:31 +0800 Message-ID: To: Henrik Levkowetz Cc: xml2rfc@ietf.org Content-Type: multipart/alternative; boundary="00000000000052dd54058bbee110" Archived-At: Subject: Re: [xml2rfc] Can not find a reference xml for an expired draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 10:33:48 -0000 --00000000000052dd54058bbee110 Content-Type: text/plain; charset="UTF-8" Sorry for late reply. > That URL is not the proper one for the reference you want. It should not > contain the 'draft-' part after '.I-D.'. The correct URL is: > > > https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihren-dnsext-threshold-validation.xml > > Yes It works. Now I can cite that draft in my draft now. Thank you very much. Best regards, Davey --00000000000052dd54058bbee110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sor= ry for late reply.
=C2=A0
That URL is not the proper one for the reference you want.=C2=A0 It should = not
contain the 'draft-' part after '.I-D.'.=C2=A0 The correct = URL is:

=C2=A0https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ihre= n-dnsext-threshold-validation.xml

=C2=A0
=
Yes It works. Now I can cite that draft in my draft now. Thank you ver= y much.

Best=C2=A0regards,
Davey=C2=A0
--00000000000052dd54058bbee110-- From nobody Fri Jun 21 10:39:11 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5475D120422 for ; Fri, 21 Jun 2019 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DuroViZUrw-i for ; Fri, 21 Jun 2019 10:38:56 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EBDCD12042B for ; Fri, 21 Jun 2019 10:38:55 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id w10so3705280pgj.7 for ; Fri, 21 Jun 2019 10:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=Mz2zyrJ8oiE4wDhFlNyCRuyO+CSH3iMyfoekrGejYDU=; b=MIRH4dJhNGw1ISCmAHwTcU2HvuE+G9tg8fcHHq8DUDsfXJImg88uYsPBD3ISbLUJge HvUfDK2ecp13TQaLDz4lJ5ardi+fkodsZhJireHEoJA4lRKkjanISmFyPBGKMIpUj43Q hkV+ph4Fmt+V8GHkSTmhlqzoB3JMchC36nEYS2G/OTwAncXnnpVbLK6DriRI4sznB1u3 lUngx12GKSGXshhXlyRsNuXEfr6v9R34ThYpXN2tsrfA5tM7FAe/paCh7fQ88hmj8BOa mfMFpU4xm8EOQnWCcuZuvCZGmQE0+XX52C0Bo3FCHVlkLvH2y90yqYdWiqWQ/tQoW/TY O0vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=Mz2zyrJ8oiE4wDhFlNyCRuyO+CSH3iMyfoekrGejYDU=; b=mFVEeuZ14SNxCimjeIUhplUfGACjySSkOaLefiP8Mm7yvjapaWFDaJxB/p3YOdDrdM RzoLkB1sg6iDPiY/S5Ci1DthhOBDMCcYDT4u3DUM2lp69V2ccFxP+Fc2nbq2/+icX4sh y4cP3TE+rQ0XFe4ABj3thxMewxspIpqXfHB9jPJvHfQF3sd+uSCW1bkkyLFxVdZfr7hr I5510CVjhQrUOe05lJR9utoylNrSApTJLGNVtlWNJhcWcHPxd/mnTNVwsrz2ENUPfjoO S/PFeBtiyR/qzQ+HrG9Lmq+4gJT/Ey5TNyX2yyZw4n21KMJkuILFhahbqvuIOLi920R9 LPgg== X-Gm-Message-State: APjAAAUhJjxHXL/OSPs0Ofk31axP+fY2Svb6Uq4Ztj4xxKvrs+08sRzk H7Tbddvc25JK0YmPSKACaL1va2GJ X-Google-Smtp-Source: APXvYqwt8pkjG0hLs4+4+icDtCqy6tSfGONCqOiM3Lmk9MkCvNiNm+JdnJBOUBQnx2QC1TXrt3BrHA== X-Received: by 2002:a17:90a:f498:: with SMTP id bx24mr8209269pjb.91.1561138735104; Fri, 21 Jun 2019 10:38:55 -0700 (PDT) Received: from 252.66.20.149.in-addr.arpa (252.66.20.149.in-addr.arpa. [149.20.66.252]) by smtp.gmail.com with ESMTPSA id r7sm5731247pfl.134.2019.06.21.10.38.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 10:38:54 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_A4FE684D-7768-4A13-8C85-92CF193829D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <528CC4D0-0E22-437E-A3FE-D9DEC4FBBF56@gmail.com> References: To: xml2rfc@ietf.org Date: Fri, 21 Jun 2019 20:38:48 +0300 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [xml2rfc] Fwd: Last Call: (IP Fragmentation Considered Fragile) to Best Current Practice X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 17:39:04 -0000 --Apple-Mail=_A4FE684D-7768-4A13-8C85-92CF193829D8 Content-Type: multipart/alternative; boundary="Apple-Mail=_F3EDB0A0-49CE-462E-AAD2-05FCBD6A9C66" --Apple-Mail=_F3EDB0A0-49CE-462E-AAD2-05FCBD6A9C66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a question for some wise person regarding XML2RFC. I have = attached the current XML and TXT versions of a draft we have in last = call right now, and I'm casting round for the correct fix for the second = of the nits pointed out in this email. What is the proper way to = reference a URL in the context I did in this draft? I suspect it's in a reference , but it's a structure that I have never = quite gotten my head around. > Begin forwarded message: >=20 > From: "C. M. Heard" > Subject: Re: Last Call: (IP = Fragmentation Considered Fragile) to Best Current Practice > Date: June 21, 2019 at 6:27:20 PM GMT+3 > To: draft-ietf-intarea-frag-fragile@ietf.org > Cc: Suresh Krishnan , intarea-chairs = > Resent-From: > Resent-To: rbonica@juniper.net, fredbaker.ietf@gmail.com, = gih@apnic.net, bob.hinden@gmail.com, ot@cisco.com, fgont@si6networks.com >=20 > I've got a couple of nits to bring to the attention of the authors and = thee shepherd. Since they are editorial and not substantive I'm sparing = the WG and IETF lists. >=20 > 1.) Section 1, Introduction, end of 2nd paragraph (page 3): the = phrase "(e.g. PLPMTU)" (a) has the acronym mis-spelled (should be = PLPMTUD) and (b) uses the acronym before it is first expended (in = Section 2.3). There are lots of ways to fix this; an easy one is to = delete the parenthetical phrase. >=20 > 2.) Section 4.6, Security Vulnerabilities, 2nd bullet (page 11): it = took me some poking around to figure out that I was supposed to splice = the two URLS together to get = https://web.archive.org/web/20110723091910/http://www.digital.net/~gandalf= /Rose_Frag_Attack_Explained.htm = . I'm aware that the problem of = rendering the long URL is due to the line length limit of RFCs, but is = there maybe a way to get the underlying hyperlink to come out right in = the html version of the published RFC, as is done with the references? >=20 > Sorry for not catching these things earlier during the WG process. >=20 > Mike Heard = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_F3EDB0A0-49CE-462E-AAD2-05FCBD6A9C66 Content-Type: multipart/mixed; boundary="Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE" --Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have a question for some wise person regarding XML2RFC. I have attached = the current XML and TXT versions of a draft we have in last call right = now, and I'm casting round for the correct fix for the second of the = nits pointed out in this email. What is the proper way to reference a = URL in the context I did in this draft?

I suspect it's in a reference , but = it's a structure that I have never quite gotten my head around.

Begin forwarded message:

From: = "C. M. Heard" <heard@pobox.com>
Subject: = Re: Last Call: = <draft-ietf-intarea-frag-fragile-12.txt> (IP Fragmentation = Considered Fragile) to Best Current Practice
Date: = June 21, 2019 at 6:27:20 PM = GMT+3
To: = draft-ietf-intarea-frag-fragile@ietf.org
Cc: = Suresh Krishnan <Suresh@kaloom.com>, = intarea-chairs <intarea-chairs@ietf.org>
Resent-From: = <alias-bounces@ietf.org>
Resent-To: = rbonica@juniper.net, = fredbaker.ietf@gmail.com, gih@apnic.net, bob.hinden@gmail.com, ot@cisco.com, fgont@si6networks.com

I've got a couple of nits to bring to the = attention of the authors and thee shepherd. Since they are editorial and = not substantive I'm sparing the WG and IETF lists.

1.) Section 1, Introduction, end of 2nd = paragraph (page 3):  the phrase "(e.g. PLPMTU)" (a) has the = acronym mis-spelled (should be PLPMTUD) and (b) uses the acronym before = it is first expended (in Section 2.3). There are lots of ways to fix = this; an easy one is to delete the parenthetical = phrase.

2.) Section 4.6, = Security Vulnerabilities, 2nd bullet (page 11): it took me some poking = around to figure out that I was supposed to splice the two URLS together = to get https://web.archive.org/web/20110723091910/http://www.digital.n= et/~gandalf/Rose_Frag_Attack_Explained.htm. I'm aware that the = problem of rendering the long URL is due to the line length limit of = RFCs, but is there maybe a way to get the underlying hyperlink to come = out right in the html version of the published RFC, as is done with the = references?

Sorry for = not catching these things earlier during the WG = process.

Mike = Heard
= --Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE Content-Disposition: attachment; filename=draft-ietf-intarea-frag-fragile-12.txt Content-Type: text/plain; x-unix-mode=0664; name="draft-ietf-intarea-frag-fragile-12.txt" Content-Transfer-Encoding: quoted-printable Internet Area WG R. Bonica Internet-Draft Juniper Networks Intended status: Best Current Practice F. Baker Expires: December 21, 2019 Unaffiliated G. Huston APNIC R. Hinden Check Point Software O. Troan Cisco F. Gont SI6 Networks June 19, 2019 IP Fragmentation Considered Fragile draft-ietf-intarea-frag-fragile-12 Abstract This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Bonica, et al. Expires December 21, 2019 [Page 1] =0C Internet-Draft IP Fragmentation Fragile June 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. IP-in-IP Tunnels . . . . . . . . . . . . . . . . . . . . 3 2. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Links, Paths, MTU and PMTU . . . . . . . . . . . . . . . 3 2.2. Fragmentation Procedures . . . . . . . . . . . . . . . . 5 2.3. Upper-Layer Reliance on IP Fragmentation . . . . . . . . 6 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 4. Increased Fragility . . . . . . . . . . . . . . . . . . . . . 7 4.1. Policy-Based Routing . . . . . . . . . . . . . . . . . . 7 4.2. Network Address Translation (NAT) . . . . . . . . . . . . 8 4.3. Stateless Firewalls . . . . . . . . . . . . . . . . . . . 9 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless Load-Balancers . . . . . . . . . . . . . . . . . . . . . 9 4.5. IPv4 Reassembly Errors at High Data Rates . . . . . . . . 10 4.6. Security Vulnerabilities . . . . . . . . . . . . . . . . 11 4.7. PMTU Blackholing Due to ICMP Loss . . . . . . . . . . . . 12 4.7.1. Transient Loss . . . . . . . . . . . . . . . . . . . 12 4.7.2. Incorrect Implementation of Security Policy . . . . . 13 4.7.3. Persistent Loss Caused By Anycast . . . . . . . . . . 13 4.7.4. Persistent Loss Caused By Unidirectional Routing . . 14 4.8. Blackholing Due To Filtering or Loss . . . . . . . . . . 14 5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 15 5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 15 5.2. Application Layer Solutions . . . . . . . . . . . . . . . 16 6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 17 6.1. Domain Name Service (DNS) . . . . . . . . . . . . . . . . 17 6.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . 18 6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 18 6.4. UDP Applications Enhancing Performance . . . . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. For Application and Protocol Developers . . . . . . . . . 19 7.2. For System Developers . . . . . . . . . . . . . . . . . . 19 7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 19 7.4. For ECMP, LAG and Load-Balancer Developers And Operators 20 7.5. For Network Operators . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Bonica, et al. Expires December 21, 2019 [Page 2] =0C Internet-Draft IP Fragmentation Fragile June 2019 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Operational experience [Kent] [Huston] [RFC7872] reveals that IP fragmentation introduces fragility to Internet communication. This document describes IP fragmentation and explains the fragility it introduces. It also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. While this document identifies issues associated with IP fragmentation, it does not recommend deprecation. Legacy protocols that depend upon IP fragmentation SHOULD be updated to remove that dependency. However, some applications and environments (see Section 6) require IP fragmentation. In these cases, the protocol will continue to rely on IP fragmentation, but the designer should to be aware that fragmented packets may result in blackholes; a design should include appropriate safeguards (e.g. PLPMTU). Rather than deprecating IP Fragmentation, this document recommends that upper-layer protocols address the problem of fragmentation at their layer, reducing their reliance on IP fragmentation to the greatest degree possible. 1.1. IP-in-IP Tunnels This document acknowledges that in some cases, packets must be fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. Therefore, this document makes no additional recommendations regarding IP-in-IP tunnels. 2. IP Fragmentation 2.1. Links, Paths, MTU and PMTU An Internet path connects a source node to a destination node. A path can contain links and routers. If a path contains more than one link, the links are connected in series and a router connects each link to the next. Internet paths are dynamic. Assume that the path from one node to another contains a set of links and routers. If a link fails, the Bonica, et al. Expires December 21, 2019 [Page 3] =0C Internet-Draft IP Fragmentation Fragile June 2019 path can also change so that it includes a different set of links and routers. Each link is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the link Maximum Transmission Unit (MTU). IPv4 [RFC0791] requires every link to support a specified MTU (see NOTE 1). IPv6 [RFC8200] requires every link to support an MTU of 1280 bytes or greater. These are called the IPv4 and IPv6 minimum link MTU's. Likewise, each Internet path is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the Path MTU (PMTU). For any given path, the PMTU is equal to the smallest of its link MTU's. Because Internet paths are dynamic, PMTU is also dynamic. For reasons described below, source nodes estimate the PMTU between themselves and destination nodes. A source node can produce extremely conservative PMTU estimates in which: o The estimate for each IPv4 path is equal to the IPv4 minimum link MTU. o The estimate for each IPv6 path is equal to the IPv6 minimum link MTU. While these conservative estimates are guaranteed to be less than or equal to the actual PMTU, they are likely to be much less than the actual PMTU. This may adversely affect upper-layer protocol performance. By executing Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] procedures, a source node can maintain a less conservative estimate of the PMTU between itself and a destination node. In PMTUD, the source node produces an initial PMTU estimate. This initial estimate is equal to the MTU of the first link along the path to the destination node. It can be greater than the actual PMTU. Having produced an initial PMTU estimate, the source node sends non- fragmentable IP packets to the destination node (see NOTE 2). If one of these packets is larger than the actual PMTU, a downstream router will not be able to forward the packet through the next link along the path. Therefore, the downstream router drops the packet and sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] Packet Too Big (PTB) message to the source node (see NOTE 3). The ICMP PTB message indicates the MTU of the link through which the packet could not be forwarded. The source node uses this information to refine its PMTU estimate. Bonica, et al. Expires December 21, 2019 [Page 4] =0C Internet-Draft IP Fragmentation Fragile June 2019 PMTUD produces a running estimate of the PMTU between a source node and a destination node. Because PMTU is dynamic, the PMTU estimate can be larger than the actual PMTU. In order to detect PMTU increases, PMTUD occasionally resets the PMTU estimate to its initial value and repeats the procedure described above. Ideally, PMTUD operates as described above. However, in some scenarios, PMTUD fails. For example: o PMTUD relies on the network's ability to deliver ICMP PTB messages to the source node. If the network cannot deliver ICMP PTB messages to the source node, PMTUD fails. o PMTUD is susceptible to attack because ICMP messages are easily forged [RFC5927] and not authenticated by the receiver. Such attacks can cause PMTUD to produce unnecessarily conservative PMTU estimates. NOTE 1: In IPv4, every host must be capable of receiving a packet whose length is equal to 576 bytes. However, the IPv4 minimum link MTU is not 576. Section 3.2 of RFC 791 explicitly states that the IPv4 minimum link MTU is 68 bytes. But for practical purposes, many network operators consider the IPv4 minimum link MTU to be 576 bytes, to minimize the requirement for fragmentation en route. So, for the purposes of this document, we assume that the IPv4 minimum path MTU is 576 bytes. NOTE 2: A non-fragmentable packet can be fragmented at its source. However, it cannot be fragmented by a downstream node. An IPv4 packet whose DF-bit is set to zero is fragmentable. An IPv4 packet whose DF-bit is set to one is non-fragmentable. All IPv6 packets are also non-fragmentable. NOTE 3:: The ICMP PTB message has two instantiations. In ICMPv4 [RFC0792], the ICMP PTB message is a Destination Unreachable message with Code equal to (4) fragmentation needed and DF set. This message was augmented by [RFC1191] to indicate the MTU of the link through which the packet could not be forwarded. In ICMPv6 [RFC4443], the ICMP PTB message is a Packet Too Big Message with Code equal to (0). This message also indicates the MTU of the link through which the packet could not be forwarded. 2.2. Fragmentation Procedures When an upper-layer protocol submits data to the underlying IP module, and the resulting IP packet's length is greater than the PMTU, the packet is divided into fragments. Each fragment includes an IP header and a portion of the original packet. Bonica, et al. Expires December 21, 2019 [Page 5] =0C Internet-Draft IP Fragmentation Fragile June 2019 [RFC0791] describes IPv4 fragmentation procedures. An IPv4 packet whose DF-bit is set to one can be fragmented by the source node, but cannot be fragmented by a downstream router. An IPv4 packet whose DF-bit is set to zero can be fragmented by the source node or by a downstream router. When an IPv4 packet is fragmented, all IP options appear in the first fragment, but only options whose "copy" bit is set to one appear in subsequent fragments. [RFC8200] describes IPv6 fragmentation procedures. An IPv6 packet can be fragmented at the source node only. When an IPv6 packet is fragmented, all extension headers appear in the first fragment, but only per-fragment headers appear in subsequent fragments. Per- fragment headers include the following: o The IPv6 header. o The Hop-by-hop Options header (if present) o The Destination Options header (if present and if it precedes a Routing header) o The Routing Header (if present) o The Fragment Header In both IPv4 and IPv6, the upper-layer header appears in the first fragment only. It does not appear in subsequent fragments. 2.3. Upper-Layer Reliance on IP Fragmentation Upper-layer protocols can operate in the following modes: o Do not rely on IP fragmentation. o Rely on IP fragmentation by the source node only. o Rely on IP fragmentation by any node. Upper-layer protocols running over IPv4 can operate in all of the above-mentioned modes. Upper-layer protocols running over IPv6 can operate in the first and second modes only. Upper-layer protocols that operate in the first two modes (above) require access to the PMTU estimate. In order to fulfil this requirement, they can: o Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link MTU. Bonica, et al. Expires December 21, 2019 [Page 6] =0C Internet-Draft IP Fragmentation Fragile June 2019 o Access the estimate that PMTUD produced. o Execute PMTUD procedures themselves. o Execute Packetization Layer PMTUD (PLPMTUD) [RFC4821] [I-D.ietf-tsvwg-datagram-plpmtud] procedures. According to PLPMTUD procedures, the upper-layer protocol maintains a running PMTU estimate. It does so by sending probe packets of various sizes to its upper-layer peer and receiving acknowledgements. This strategy differs from PMTUD in that it relies on acknowledgement of received messages, as opposed to ICMP PTB messages concerning dropped messages. Therefore, PLPMTUD does not rely on the network's ability to deliver ICMP PTB messages to the source. 3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Increased Fragility This section explains how IP fragmentation introduces fragility to Internet communication. 4.1. Policy-Based Routing IP Fragmentation causes problems for routers that implement policy- based routing. When a router receives a packet, it identifies the next-hop on route to the packet's destination and forwards the packet to that next-hop. In order to identify the next-hop, the router interrogates a local data structure called the Forwarding Information Base (FIB). Normally, the FIB contains destination-based entries that map a destination prefix to a next-hop. Policy-based routing allows destination-based and policy-based entries to coexist in the same FIB. A policy-based FIB entry maps multiple fields, drawn from either the IP or transport-layer header, to a next-hop. Bonica, et al. Expires December 21, 2019 [Page 7] =0C Internet-Draft IP Fragmentation Fragile June 2019 +-------+--------------+-----------------+------------+-------------+ | Entry | Type | Dest. Prefix | Next Hdr / | Next-Hop | | | | | Dest. Port | | +-------+--------------+-----------------+------------+-------------+ | | | | | | | 1 | Destination- | 2001:db8::1/128 | Any / Any | 2001:db8::2 | | | based | | | | | | | | | | | 2 | Policy- | 2001:db8::1/128 | TCP / 80 | 2001:db8::3 | | | based | | | | +-------+--------------+-----------------+------------+-------------+ Table 1: Policy-Based Routing FIB Assume that a router maintains the FIB in Table 1. The first FIB entry is destination-based. It maps the a destination prefix (2001:db8::1/128) to a next-hop (2001:db8::2). The second FIB entry is policy-based. It maps the same destination prefix (2001:db8::1/128) and a destination port ( TCP / 80 ) to a different next-hop (2001:db8::3). The second entry is more specific than the first. When the router receives the first fragment of a packet that is destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. Both FIB entries satisfy the query. The router selects the second FIB entry because it is more specific and forwards the packet to 2001:db8::3. When the router receives the second fragment of the packet, it interrogates the FIB again. This time, only the first FIB entry satisfies the query, because the second fragment contains no indication that the packet is destined for TCP port 80. Therefore, the router selects the first FIB entry and forwards the packet to 2001:db8::2. Policy-based routing is also known as filter-based-forwarding. 4.2. Network Address Translation (NAT) IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT device detects a new, outbound flow, it maps that flow's source port and IP address to another source port and IP address. Having created that mapping, the NAT device translates: o The Source IP Address and Source Port on each outbound packet. Bonica, et al. Expires December 21, 2019 [Page 8] =0C Internet-Draft IP Fragmentation Fragile June 2019 o The Destination IP Address and Destination Port on each inbound packet. A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common NAT strategies. In both approaches the NAT device must virtually reassemble fragmented packets in order to translate and forward each fragment. (See NOTE 1.) Virtual reassembly in the network is problematic, because it is computationally expensive and because it is prone to attacks (Section 4.6). NOTE 1: Virtual reassembly is a procedure in which a device reassembles a packet, forwards its fragments, and discards the reassembled copy. In A+P and CGN, virtual reassembly is required in order to correctly translate fragment addresses. 4.3. Stateless Firewalls As discussed in more detail in Section 4.6, IP fragmentation causes problems for stateless firewalls whose rules include TCP and UDP ports. Because port information is not available in the trailing fragments the firewall is limited to the following options: o Accept all trailing fragments, possibly admitting certain classes of attack. o Block all trailing fragments, possibly blocking legitimate traffic. Neither option is attractive. 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless Load- Balancers IP fragmentation causes problems for Equal Cost Multipath (ECMP), Link Aggregate Groups (LAG) and other stateless load-balancing technologies. In order to assign a packet or packet fragment to a link, an intermediate node executes a hash (i.e., load-balancing) algorithm. The following paragraphs describe a commonly deployed hash algorithm. If the packet or packet fragment contains a transport-layer header, the algorithm accepts the following 5-tuple as input: o IP Source Address. o IP Destination Address. Bonica, et al. Expires December 21, 2019 [Page 9] =0C Internet-Draft IP Fragmentation Fragile June 2019 o IPv4 Protocol or IPv6 Next Header. o transport-layer source port. o transport-layer destination port. If the packet or packet fragment does not contain a transport-layer header, the algorithm accepts only the following 3-tuple as input: o IP Source Address. o IP Destination Address. o IPv4 Protocol or IPv6 Next Header. Therefore, non-fragmented packets belonging to a flow can be assigned to one link while fragmented packets belonging to the same flow can be divided between that link and another. This can cause suboptimal load-balancing. [RFC6438] offers a partial solution to this problem for IPv6 devices only. According to [RFC6438]: "At intermediate routers that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple." If the algorithm includes only the 3-tuple {dest addr, source addr, flow label}, it will assign all fragments belonging to a packet to the same link. (See [RFC6437] and [RFC7098]). In order to avoid the problem described above, implementations SHOULD implement the recommendations provided in Section 7.4 of this document. 4.5. IPv4 Reassembly Errors at High Data Rates IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. [RFC4963] describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. Bonica, et al. Expires December 21, 2019 [Page 10] =0C Internet-Draft IP Fragmentation Fragile June 2019 These reassembly issues are not easily reproducible in IPv6 because the IPv6 identification field is 32 bits long. 4.6. Security Vulnerabilities Security researchers have documented several attacks that exploit IP fragmentation. The following are examples: o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] o Resource exhaustion attacks (such as the Rose Attack, https://web.archive.org/web/20110723091910/ http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm) o Attacks based on predictable fragment identification values [RFC7739] o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] In the overlapping fragment attack, an attacker constructs a series of packet fragments. The first fragment contains an IP header, a transport-layer header, and some transport-layer payload. This fragment complies with local security policy and is allowed to pass through a stateless firewall. A second fragment, having a non-zero offset, overlaps with the first fragment. The second fragment also passes through the stateless firewall. When the packet is reassembled, the transport layer header from the first fragment is overwritten by data from the second fragment. The reassembled packet does not comply with local security policy. Had it traversed the firewall in one piece, the firewall would have rejected it. A stateless firewall cannot protect against the overlapping fragment attack. However, destination nodes can protect against the overlapping fragment attack by implementing the procedures described in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures detect the overlap and discard the packet. The fragment reassembly algorithm is a stateful procedure in an otherwise stateless protocol. Therefore, it can be exploited by resource exhaustion attacks. An attacker can construct a series of fragmented packets, with one fragment missing from each packet so that the reassembly is impossible. Thus, this attack causes resource exhaustion on the destination node, possibly denying reassembly services to other flows. This type of attack can be mitigated by flushing fragment reassembly buffers when necessary, at the expense of possibly dropping legitimate fragments. Bonica, et al. Expires December 21, 2019 [Page 11] =0C Internet-Draft IP Fragmentation Fragile June 2019 Each IP fragment contains an "Identification" field that destination nodes use to reassemble fragmented packets. Many implementations set the Identification field to a predictable value, thus making it easy for an attacker to forge malicious IP fragments that would cause the reassembly procedure for legitimate packets to fail. NIDS aims at identifying malicious activity by analyzing network traffic. Ambiguity in the possible result of the fragment reassembly process may allow an attacker to evade these systems. Many of these systems try to mitigate some of these evasion techniques (e.g. By computing all possible outcomes of the fragment reassembly process, at the expense of increased processing requirements). 4.7. PMTU Blackholing Due to ICMP Loss As mentioned in Section 2.3, upper-layer protocols can be configured to rely on PMTUD. Because PMTUD relies upon the network to deliver ICMP PTB messages, those protocols also rely on the networks to deliver ICMP PTB messages. According to [RFC4890], ICMP PTB messages must not be filtered. However, ICMP PTB delivery is not reliable. It is subject to both transient and persistent loss. Transient loss of ICMP PTB messages can cause transient PMTU black holes. When the conditions contributing to transient loss abate, the network regains its ability to deliver ICMP PTB messages and connectivity between the source and destination nodes is restored. Section 4.7.1 of this document describes conditions that lead to transient loss of ICMP PTB messages. Persistent loss of ICMP PTB messages can cause persistent black holes. Section 4.7.2, Section 4.7.3, and Section 4.7.4 of this document describe conditions that lead to persistent loss of ICMP PTB messages. The problem described in this section is specific to PMTUD. It does not occur when the upper-layer protocol obtains its PMTU estimate from PLPMTUD or from any other source. 4.7.1. Transient Loss The following factors can contribute to transient loss of ICMP PTB messages: o Network congestion. o Packet corruption. Bonica, et al. Expires December 21, 2019 [Page 12] =0C Internet-Draft IP Fragmentation Fragile June 2019 o Transient routing loops. o ICMP rate limiting. The effect of rate limiting may be severe, as RFC 4443 recommends strict rate limiting of IPv6 traffic. 4.7.2. Incorrect Implementation of Security Policy Incorrect implementation of security policy can cause persistent loss of ICMP PTB messages. Assume that a Customer Premise Equipment (CPE) router implements the following zone-based security policy: o Allow any traffic to flow from the inside zone to the outside zone. o Do not allow any traffic to flow from the outside zone to the inside zone unless it is part of an existing flow (i.e., it was elicited by an outbound packet). When a correct implementation of the above-mentioned security policy receives an ICMP PTB message, it examines the ICMP PTB payload in order to determine whether the original packet (i.e., the packet that elicited the ICMP PTB message) belonged to an existing flow. If the original packet belonged to an existing flow, the implementation allows the ICMP PTB to flow from the outside zone to the inside zone. If not, the implementation discards the ICMP PTB message. When a incorrect implementation of the above-mentioned security policy receives an ICMP PTB message, it discards the packet because its source address is not associated with an existing flow. The security policy described above is implemented incorrectly on many consumer CPE routers. 4.7.3. Persistent Loss Caused By Anycast Anycast can cause persistent loss of ICMP PTB messages. Consider the example below: A DNS client sends a request to an anycast address. The network routes that DNS request to the nearest instance of that anycast address (i.e., a DNS Server). The DNS server generates a response and sends it back to the DNS client. While the response does not exceed the DNS server's PMTU estimate, it does exceed the actual PMTU. Bonica, et al. Expires December 21, 2019 [Page 13] =0C Internet-Draft IP Fragmentation Fragile June 2019 A downstream router drops the packet and sends an ICMP PTB message the packet's source (i.e., the anycast address). The network routes the ICMP PTB message to the anycast instance closest to the downstream router. That anycast instance may not be the DNS server that originated the DNS response. It may be another DNS server with the same anycast address. The DNS server that originated the response may never receive the ICMP PTB message and may never update its PMTU estimate. 4.7.4. Persistent Loss Caused By Unidirectional Routing Unidirectional routing can cause persistent loss of ICMP PTB messages. Consider the example below: A source node sends a packet to a destination node. All intermediate nodes maintain a route to the destination node, but do not maintain a route to the source node. In this case, when an intermediate node encounters an MTU issue, it cannot send an ICMP PTB message to the source node. 4.8. Blackholing Due To Filtering or Loss In RFC 7872, researchers sampled Internet paths to determine whether they would convey packets that contain IPv6 extension headers. Sampled paths terminated at popular Internet sites (e.g., popular web, mail and DNS servers). The study revealed that at least 28% of the sampled paths did not convey packets containing the IPv6 Fragment extension header. In most cases, fragments were dropped in the destination autonomous system. In other cases, the fragments were dropped in transit autonomous systems. Another recent study [Huston] confirmed this finding. It reported that 37% of sampled endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response. It is difficult to determine why network operators drop fragments. Possible causes follow: o Hardware inability to process fragmented packets. o Failure to change vendor defaults. o Unintentional misconfiguration. Bonica, et al. Expires December 21, 2019 [Page 14] =0C Internet-Draft IP Fragmentation Fragile June 2019 o Intentional configuration (e.g., network operators consciously chooses to drop IPv6 fragments in order to address the issues raised in Section 4.1 through Section 4.7, above.) 5. Alternatives to IP Fragmentation 5.1. Transport Layer Solutions The Transport Control Protocol (TCP) [RFC0793]) can be operated in a mode that does not require IP fragmentation. Applications submit a stream of data to TCP. TCP divides that stream of data into segments, with no segment exceeding the TCP Maximum Segment Size (MSS). Each segment is encapsulated in a TCP header and submitted to the underlying IP module. The underlying IP module prepends an IP header and forwards the resulting packet. If the TCP MSS is sufficiently small, the underlying IP module never produces a packet whose length is greater than the actual PMTU. Therefore, IP fragmentation is not required. TCP offers the following mechanisms for MSS management: o Manual configuration o PMTUD o PLPMTUD Manual configuration is always applicable. If the MSS is configured to a sufficiently low value, the IP layer will never produce a packet whose length is greater than the protocol minimum link MTU. However, manual configuration prevents TCP from taking advantage of larger link MTU's. Upper-layer protocols can implement PMTUD in order to discover and take advantage of larger path MTUs. However, as mentioned in Section 2.1, PMTUD relies upon the network to deliver ICMP PTB messages. Therefore, PMTUD can only provide an estimate of the PMTU in environments where the risk of ICMP PTB loss is acceptable (e.g., known to not be filtered). By contrast, PLPMTUD does not rely upon the network's ability to deliver ICMP PTB messages. It utilises probe messages sent as TCP segments to determine whether the probed PMTU can be successfully used across the network path. In PLPMTUD, probing is separated from congestion control, so that loss of a TCP probe segment does not Bonica, et al. Expires December 21, 2019 [Page 15] =0C Internet-Draft IP Fragmentation Fragile June 2019 cause a reduction of the congestion control window. [RFC4821] defines PLPMTUD procedures for TCP. While TCP will never knowingly cause the underlying IP module to emit a packet that is larger than the PMTU estimate, it can cause the underlying IP module to emit a packet that is larger than the actual PMTU. For example, if routing changes and as a result the PMTU becomes smaller, TCP will not know until the ICMP PTB message arrives. If this occurs, the packet is dropped, the PMTU estimate is updated, the segment is divided into smaller segments and each smaller segment is submitted to the underlying IP module. The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the Stream Control Transport Protocol (SCTP) [RFC4960] also can be operated in a mode that does not require IP fragmentation. They both accept data from an application and divide that data into segments, with no segment exceeding a maximum size. DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms for managing that maximum size. Datagram protocols can also implement PLPMTUD to estimate the PMTU via[I-D.ietf-tsvwg-datagram-plpmtud]. This proposes procedures for performing PLPMTUD with UDP, UDP-Options, SCTP, QUIC and other datagram protocols. Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation mechanism of its own and relies on IP fragmentation. However, [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for UDP. 5.2. Application Layer Solutions [RFC8085] recognizes that IP fragmentation reduces the reliability of Internet communication. It also recognizes that UDP lacks a fragmentation mechanism of its own and relies on IP fragmentation. Therefore, [RFC8085] offers the following advice regarding applications the run over the UDP. "An application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself to determine whether the path to a destination will support its desired message size without fragmentation." RFC 8085 continues: Bonica, et al. Expires December 21, 2019 [Page 16] =0C Internet-Draft IP Fragmentation Fragile June 2019 "Applications that do not follow the recommendation to do PMTU/ PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter than the default effective MTU for sending (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the first-hop MTU. For IPv6, EMTU_S is 1280 bytes [RFC8200]. The effective PMTU for a directly connected destination (with no routers on the path) is the configured interface MTU, which could be less than the maximum link payload size. Transmission of minimum- sized UDP datagrams is inefficient over paths that support a larger PMTU, which is a second reason to implement PMTU discovery." RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently small is sufficiently small to be supported by most current Internet paths, even though the IPv4 minimum link MTU is 68 bytes. This advice applies equally to any application that runs directly over IP. 6. Applications That Rely on IPv6 Fragmentation The following applications rely on IPv6 fragmentation: o DNS [RFC1035] o OSPFv3 [RFC2328][RFC5340] o Packet-in-packet encapsulations Each of these applications relies on IPv6 fragmentation to a varying degree. In some cases, that reliance is essential, and cannot be broken without fundamentally changing the protocol. In other cases, that reliance is incidental, and most implementations already take appropriate steps to avoid fragmentation. This list is not comprehensive, and other protocols that rely on IP fragmentation may exist. They are not specifically considered in the context of this document. 6.1. Domain Name Service (DNS) DNS relies on UDP for efficiency, and the consequence is the use of IP fragmentation for large responses, as permitted by the DNS EDNS(0) options in the query. It is possible to mitigate the issue of fragmentation-based packet loss by having queries use smaller EDNS(0) UDP buffer sizes, or by having the DNS server limit the size of its UDP responses to some self-imposed maximum packet size that may be Bonica, et al. Expires December 21, 2019 [Page 17] =0C Internet-Draft IP Fragmentation Fragile June 2019 less than the preferred EDNS(0) UDP Buffer Size. In both cases, large responses are truncated in the DNS, signalling to the client to re-query using TCP to obtain the complete response. However, the operational issue of the partial level of support for DNS over TCP, particularly in the case where IPv6 transport is being used, becomes a limiting factor of the efficacy of this approach [Damas]. Larger DNS responses can normally be avoided by aggressively pruning the Additional section of DNS responses. One scenario where such pruning is ineffective is in the use of DNSSEC, where large key sizes act to increase the response size to certain DNS queries. There is no effective response to this situation within the DNS other than using smaller cryptographic keys and adoption of DNSSEC administrative practices that attempt to keep DNS response as short as possible. 6.2. Open Shortest Path First (OSPF) OSPF implementations can emit messages large enough to cause fragmentation. However, in order to optimize performance, most OSPF implementations restrict their maximum message size to a value that will not cause fragmentation. 6.3. Packet-in-Packet Encapsulations In this document, packet-in-packet encapsulations include IP-in-IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459] describes fragmentation issues associated with all of the above- mentioned encapsulations. The fragmentation strategy described for GRE in [RFC7588] has been deployed for all of the above-mentioned encapsulations. This strategy does not rely on IP fragmentation except in one corner case. (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). Section 3.3 of [RFC7676] further describes this corner case. See [I-D.ietf-intarea-tunnels] for further discussion. 6.4. UDP Applications Enhancing Performance Some UDP applications rely on IP fragmentation to achieve acceptable levels of performance. These applications use UDP datagram sizes that are larger than the path MTU so that more data can be conveyed between the application and the kernel in a single system call. To pick one example, the Licklider Transmission Protocol (LTP), [RFC5326]which is in current use on the International Space Station Bonica, et al. Expires December 21, 2019 [Page 18] =0C Internet-Draft IP Fragmentation Fragile June 2019 (ISS), uses UDP datagram sizes larger than the path MTU to achieve acceptable levels of performance even though this invokes IP fragmentation. More generally, SNMP and video applications may transmit an application-layer quantum of data, depending on the network layer to fragment and reassemble as needed. 7. Recommendations 7.1. For Application and Protocol Developers Developers SHOULD NOT develop new protocols or applications that rely on IP fragmentation. When a new protocol or application is deployed in an environment that does not fully support IP fragmentation, it SHOULD operate correctly, either in its default configuration or in a specified alternative configuration. Developers MAY develop new protocols or applications that rely on IP fragmentation if the protocol or application is to be run only in environments where IP fragmentation is known to be supported. Legacy protocols that depend upon IP fragmentation SHOULD be updated to break that dependency. However, in some cases, there may be no viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- in-IP encapsulation). In these cases, the protocol will continue to rely on IP fragmentation but should only be used in environments where IP fragmentation is known to be supported. Protocols may be able to avoid IP fragmentation by using a sufficiently small MTU (e.g. The protocol minimum link MTU), disabling IP fragmentation, and ensuring that the transport protocol in use adapts its segment size to the MTU. Other protocols may deploy a sufficiently reliable PMTU discovery mechanism (e.g.,PLMPTUD). UDP applications SHOULD abide by the recommendations stated in Section 3.2 of [RFC8085]. 7.2. For System Developers Software libraries SHOULD include provision for PLPMTUD for each supported transport protocol. 7.3. For Middle Box Developers Middle boxes should process IP fragments in a manner that is consistent with [RFC0791] and [RFC8200]. In many cases, middle boxes must maintain state in order to achieve this goal. Bonica, et al. Expires December 21, 2019 [Page 19] =0C Internet-Draft IP Fragmentation Fragile June 2019 Price and performance considerations frequently motivate network operators to deploy stateless middle boxes. These stateless middle boxes may perform sub-optimally, process IP fragments in a manner that is not compliant with RFC 791 or RFC 8200, or even discard IP fragments completely. Such behaviors are NOT RECOMMENDED. If a middleboxes implements non-standard behavior with respect to IP fragmentation, then that behavior MUST be clearly documented. 7.4. For ECMP, LAG and Load-Balancer Developers And Operators In their default configuration, when the IPv6 Flow Label is not equal to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP) Routing as described in OSPF [RFC2328] and other routing protocols, Link Aggregation Grouping (LAG) [RFC7424], or other load-balancing technologies SHOULD accept only the following fields as input to their hash algorithm: o IP Source Address. o IP Destination Address. o Flow Label. Operators SHOULD deploy these devices in their default configuration. These recommendations are similar to those presented in [RFC6438] and [RFC7098]. They differ in that they specify a default configuration. 7.5. For Network Operators Operators MUST ensure proper PMTUD operation in their network, including making sure the network generates PTB packets when dropping packets too large compared to outgoing interface MTU. However, implementations MAY rate limit ICMP messages as per [RFC1812] and [RFC4443]. As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB messages unless they are known to be forged or otherwise illegitimate. As stated in Section 4.7, filtering ICMPv6 PTB packets causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. As per RFC 8200, network operators MUST NOT deploy IPv6 links whose MTU is less than 1280 bytes. Network operators SHOULD NOT filter IP fragments if they are known to have originated at a domain name server or be destined for a domain name server. This is because domain name services are critical to operation of the Internet. Bonica, et al. Expires December 21, 2019 [Page 20] =0C Internet-Draft IP Fragmentation Fragile June 2019 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations This document mitigates some of the security considerations associated with IP fragmentation by discouraging its use. It does not introduce any new security vulnerabilities, because it does not introduce any new alternatives to IP fragmentation. Instead, it recommends well-understood alternatives. 10. Acknowledgements Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, Lorenzo Colitti, Gorry Fairhurst, Mike Heard, Tom Herbert, Tatuya Jinmei, Jen Linkova, Paolo Lucente, Manoj Nayak, Eric Nygren, Fred Templin and Joe Touch for their comments. 11. References 11.1. Normative References [I-D.ietf-tsvwg-datagram-plpmtud] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and T. Voelker, "Packetization Layer Path MTU Discovery for Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 (work in progress), June 2019. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Bonica, et al. Expires December 21, 2019 [Page 21] =0C Internet-Draft IP Fragmentation Fragile June 2019 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . Bonica, et al. Expires December 21, 2019 [Page 22] =0C Internet-Draft IP Fragmentation Fragile June 2019 11.2. Informative References [Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018, . [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS (http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", August 2017. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-09 (work in progress), July 2018. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-07 (work in progress), March 2019. [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524", August 1987, . [Ptacek1998] Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection", 1998, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, . [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . Bonica, et al. Expires December 21, 2019 [Page 23] =0C Internet-Draft IP Fragmentation Fragile June 2019 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, DOI 10.17487/RFC3128, June 2001, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, . [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, . Bonica, et al. Expires December 21, 2019 [Page 24] =0C Internet-Draft IP Fragmentation Fragile June 2019 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, . [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 10.17487/RFC7098, January 2014, . [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, January 2015, . [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem", RFC 7588, DOI 10.17487/RFC7588, July 2015, . [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . Bonica, et al. Expires December 21, 2019 [Page 25] =0C Internet-Draft IP Fragmentation Fragile June 2019 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . Appendix A. Contributors' Address Authors' Addresses Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 USA Email: rbonica@juniper.net Fred Baker Unaffiliated Santa Barbara, California 93117 USA Email: FredBaker.IETF@gmail.com Geoff Huston APNIC 6 Cordelia St Brisbane, 4101 QLD Australia Email: gih@apnic.net Robert M. Hinden Check Point Software 959 Skyway Road San Carlos, California 94070 USA Email: bob.hinden@gmail.com Bonica, et al. Expires December 21, 2019 [Page 26] =0C Internet-Draft IP Fragmentation Fragile June 2019 Ole Troan Cisco Philip Pedersens vei 1 N-1366 Lysaker Norway Email: ot@cisco.com Fernando Gont SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires Argentina Email: fgont@si6networks.com Bonica, et al. Expires December 21, 2019 [Page 27] --Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE Content-Disposition: attachment; filename=draft-ietf-intarea-frag-fragile-12.xml Content-Type: application/xml; x-unix-mode=0664; name="draft-ietf-intarea-frag-fragile-12.xml" Content-Transfer-Encoding: 7bit IP Fragmentation Considered Fragile Juniper Networks
2251 Corporate Park Drive Herndon 20171 Virginia USA rbonica@juniper.net
Unaffiliated
Santa Barbara California 93117 USA FredBaker.IETF@gmail.com
APNIC
6 Cordelia St Brisbane 4101 QLD Australia gih@apnic.net
Check Point Software
959 Skyway Road San Carlos California 94070 USA bob.hinden@gmail.com
Cisco
Philip Pedersens vei 1 N-1366 Lysaker Norway ot@cisco.com
SI6 Networks
Evaristo Carriego 2644 Haedo Provincia de Buenos Aires Argentina fgont@si6networks.com
Internet Area Internet Area WG IPv6 Fragmentation This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.
Operational experience reveals that IP fragmentation introduces fragility to Internet communication. This document describes IP fragmentation and explains the fragility it introduces. It also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. While this document identifies issues associated with IP fragmentation, it does not recommend deprecation. Legacy protocols that depend upon IP fragmentation SHOULD be updated to remove that dependency. However, some applications and environments (see ) require IP fragmentation. In these cases, the protocol will continue to rely on IP fragmentation, but the designer should to be aware that fragmented packets may result in blackholes; a design should include appropriate safeguards (e.g. PLPMTU). Rather than deprecating IP Fragmentation, this document recommends that upper-layer protocols address the problem of fragmentation at their layer, reducing their reliance on IP fragmentation to the greatest degree possible.
This document acknowledges that in some cases, packets must be fragmented within IP-in-IP tunnels . Therefore, this document makes no additional recommendations regarding IP-in-IP tunnels.
An Internet path connects a source node to a destination node. A path can contain links and routers. If a path contains more than one link, the links are connected in series and a router connects each link to the next. Internet paths are dynamic. Assume that the path from one node to another contains a set of links and routers. If a link fails, the path can also change so that it includes a different set of links and routers. Each link is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the link Maximum Transmission Unit (MTU). IPv4 requires every link to support a specified MTU (see NOTE 1). IPv6 requires every link to support an MTU of 1280 bytes or greater. These are called the IPv4 and IPv6 minimum link MTU's. Likewise, each Internet path is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the Path MTU (PMTU). For any given path, the PMTU is equal to the smallest of its link MTU's. Because Internet paths are dynamic, PMTU is also dynamic. For reasons described below, source nodes estimate the PMTU between themselves and destination nodes. A source node can produce extremely conservative PMTU estimates in which: The estimate for each IPv4 path is equal to the IPv4 minimum link MTU. The estimate for each IPv6 path is equal to the IPv6 minimum link MTU. While these conservative estimates are guaranteed to be less than or equal to the actual PMTU, they are likely to be much less than the actual PMTU. This may adversely affect upper-layer protocol performance. By executing Path MTU Discovery (PMTUD) procedures, a source node can maintain a less conservative estimate of the PMTU between itself and a destination node. In PMTUD, the source node produces an initial PMTU estimate. This initial estimate is equal to the MTU of the first link along the path to the destination node. It can be greater than the actual PMTU. Having produced an initial PMTU estimate, the source node sends non-fragmentable IP packets to the destination node (see NOTE 2). If one of these packets is larger than the actual PMTU, a downstream router will not be able to forward the packet through the next link along the path. Therefore, the downstream router drops the packet and sends an Internet Control Message Protocol (ICMP) Packet Too Big (PTB) message to the source node (see NOTE 3). The ICMP PTB message indicates the MTU of the link through which the packet could not be forwarded. The source node uses this information to refine its PMTU estimate. PMTUD produces a running estimate of the PMTU between a source node and a destination node. Because PMTU is dynamic, the PMTU estimate can be larger than the actual PMTU. In order to detect PMTU increases, PMTUD occasionally resets the PMTU estimate to its initial value and repeats the procedure described above. Ideally, PMTUD operates as described above. However, in some scenarios, PMTUD fails. For example: PMTUD relies on the network's ability to deliver ICMP PTB messages to the source node. If the network cannot deliver ICMP PTB messages to the source node, PMTUD fails. PMTUD is susceptible to attack because ICMP messages are easily forged and not authenticated by the receiver. Such attacks can cause PMTUD to produce unnecessarily conservative PMTU estimates. NOTE 1: In IPv4, every host must be capable of receiving a packet whose length is equal to 576 bytes. However, the IPv4 minimum link MTU is not 576. Section 3.2 of RFC 791 explicitly states that the IPv4 minimum link MTU is 68 bytes. But for practical purposes, many network operators consider the IPv4 minimum link MTU to be 576 bytes, to minimize the requirement for fragmentation en route. So, for the purposes of this document, we assume that the IPv4 minimum path MTU is 576 bytes. NOTE 2: A non-fragmentable packet can be fragmented at its source. However, it cannot be fragmented by a downstream node. An IPv4 packet whose DF-bit is set to zero is fragmentable. An IPv4 packet whose DF-bit is set to one is non-fragmentable. All IPv6 packets are also non-fragmentable. NOTE 3:: The ICMP PTB message has two instantiations. In ICMPv4, the ICMP PTB message is a Destination Unreachable message with Code equal to (4) fragmentation needed and DF set. This message was augmented by to indicate the MTU of the link through which the packet could not be forwarded. In ICMPv6, the ICMP PTB message is a Packet Too Big Message with Code equal to (0). This message also indicates the MTU of the link through which the packet could not be forwarded.
When an upper-layer protocol submits data to the underlying IP module, and the resulting IP packet's length is greater than the PMTU, the packet is divided into fragments. Each fragment includes an IP header and a portion of the original packet. describes IPv4 fragmentation procedures. An IPv4 packet whose DF-bit is set to one can be fragmented by the source node, but cannot be fragmented by a downstream router. An IPv4 packet whose DF-bit is set to zero can be fragmented by the source node or by a downstream router. When an IPv4 packet is fragmented, all IP options appear in the first fragment, but only options whose "copy" bit is set to one appear in subsequent fragments. describes IPv6 fragmentation procedures. An IPv6 packet can be fragmented at the source node only. When an IPv6 packet is fragmented, all extension headers appear in the first fragment, but only per-fragment headers appear in subsequent fragments. Per-fragment headers include the following: The IPv6 header. The Hop-by-hop Options header (if present) The Destination Options header (if present and if it precedes a Routing header) The Routing Header (if present) The Fragment Header In both IPv4 and IPv6, the upper-layer header appears in the first fragment only. It does not appear in subsequent fragments.
Upper-layer protocols can operate in the following modes: Do not rely on IP fragmentation. Rely on IP fragmentation by the source node only. Rely on IP fragmentation by any node. Upper-layer protocols running over IPv4 can operate in all of the above-mentioned modes. Upper-layer protocols running over IPv6 can operate in the first and second modes only. Upper-layer protocols that operate in the first two modes (above) require access to the PMTU estimate. In order to fulfil this requirement, they can: Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link MTU. Access the estimate that PMTUD produced. Execute PMTUD procedures themselves. Execute Packetization Layer PMTUD (PLPMTUD) procedures. According to PLPMTUD procedures, the upper-layer protocol maintains a running PMTU estimate. It does so by sending probe packets of various sizes to its upper-layer peer and receiving acknowledgements. This strategy differs from PMTUD in that it relies on acknowledgement of received messages, as opposed to ICMP PTB messages concerning dropped messages. Therefore, PLPMTUD does not rely on the network's ability to deliver ICMP PTB messages to the source.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
This section explains how IP fragmentation introduces fragility to Internet communication.
IP Fragmentation causes problems for routers that implement policy-based routing. When a router receives a packet, it identifies the next-hop on route to the packet's destination and forwards the packet to that next-hop. In order to identify the next-hop, the router interrogates a local data structure called the Forwarding Information Base (FIB). Normally, the FIB contains destination-based entries that map a destination prefix to a next-hop. Policy-based routing allows destination-based and policy-based entries to coexist in the same FIB. A policy-based FIB entry maps multiple fields, drawn from either the IP or transport-layer header, to a next-hop. Entry Type Dest. Prefix Next Hdr / Dest. Port Next-Hop 1 Destination- based 2001:db8::1/128 Any / Any 2001:db8::2 2 Policy- based 2001:db8::1/128 TCP / 80 2001:db8::3 Assume that a router maintains the FIB in . The first FIB entry is destination-based. It maps the a destination prefix (2001:db8::1/128) to a next-hop (2001:db8::2). The second FIB entry is policy-based. It maps the same destination prefix (2001:db8::1/128) and a destination port ( TCP / 80 ) to a different next-hop (2001:db8::3). The second entry is more specific than the first. When the router receives the first fragment of a packet that is destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. Both FIB entries satisfy the query. The router selects the second FIB entry because it is more specific and forwards the packet to 2001:db8::3. When the router receives the second fragment of the packet, it interrogates the FIB again. This time, only the first FIB entry satisfies the query, because the second fragment contains no indication that the packet is destined for TCP port 80. Therefore, the router selects the first FIB entry and forwards the packet to 2001:db8::2. Policy-based routing is also known as filter-based-forwarding.
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT device detects a new, outbound flow, it maps that flow's source port and IP address to another source port and IP address. Having created that mapping, the NAT device translates: The Source IP Address and Source Port on each outbound packet. The Destination IP Address and Destination Port on each inbound packet. A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT device must virtually reassemble fragmented packets in order to translate and forward each fragment. (See NOTE 1.) Virtual reassembly in the network is problematic, because it is computationally expensive and because it is prone to attacks. NOTE 1: Virtual reassembly is a procedure in which a device reassembles a packet, forwards its fragments, and discards the reassembled copy. In A+P and CGN, virtual reassembly is required in order to correctly translate fragment addresses.
As discussed in more detail in , IP fragmentation causes problems for stateless firewalls whose rules include TCP and UDP ports. Because port information is not available in the trailing fragments the firewall is limited to the following options: Accept all trailing fragments, possibly admitting certain classes of attack. Block all trailing fragments, possibly blocking legitimate traffic. Neither option is attractive.
IP fragmentation causes problems for Equal Cost Multipath (ECMP), Link Aggregate Groups (LAG) and other stateless load-balancing technologies. In order to assign a packet or packet fragment to a link, an intermediate node executes a hash (i.e., load-balancing) algorithm. The following paragraphs describe a commonly deployed hash algorithm. If the packet or packet fragment contains a transport-layer header, the algorithm accepts the following 5-tuple as input: IP Source Address. IP Destination Address. IPv4 Protocol or IPv6 Next Header. transport-layer source port. transport-layer destination port. If the packet or packet fragment does not contain a transport-layer header, the algorithm accepts only the following 3-tuple as input: IP Source Address. IP Destination Address. IPv4 Protocol or IPv6 Next Header. Therefore, non-fragmented packets belonging to a flow can be assigned to one link while fragmented packets belonging to the same flow can be divided between that link and another. This can cause suboptimal load-balancing. offers a partial solution to this problem for IPv6 devices only. According to : "At intermediate routers that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple." If the algorithm includes only the 3-tuple {dest addr, source addr, flow label}, it will assign all fragments belonging to a packet to the same link. (See and ). In order to avoid the problem described above, implementations SHOULD implement the recommendations provided in of this document.
IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. These reassembly issues are not easily reproducible in IPv6 because the IPv6 identification field is 32 bits long.
Security researchers have documented several attacks that exploit IP fragmentation. The following are examples: Overlapping fragment attacks Resource exhaustion attacks (such as the Rose Attack, https://web.archive.org/web/20110723091910/http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm) Attacks based on predictable fragment identification values Evasion of Network Intrusion Detection Systems (NIDS) In the overlapping fragment attack, an attacker constructs a series of packet fragments. The first fragment contains an IP header, a transport-layer header, and some transport-layer payload. This fragment complies with local security policy and is allowed to pass through a stateless firewall. A second fragment, having a non-zero offset, overlaps with the first fragment. The second fragment also passes through the stateless firewall. When the packet is reassembled, the transport layer header from the first fragment is overwritten by data from the second fragment. The reassembled packet does not comply with local security policy. Had it traversed the firewall in one piece, the firewall would have rejected it. A stateless firewall cannot protect against the overlapping fragment attack. However, destination nodes can protect against the overlapping fragment attack by implementing the procedures described in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures detect the overlap and discard the packet. The fragment reassembly algorithm is a stateful procedure in an otherwise stateless protocol. Therefore, it can be exploited by resource exhaustion attacks. An attacker can construct a series of fragmented packets, with one fragment missing from each packet so that the reassembly is impossible. Thus, this attack causes resource exhaustion on the destination node, possibly denying reassembly services to other flows. This type of attack can be mitigated by flushing fragment reassembly buffers when necessary, at the expense of possibly dropping legitimate fragments. Each IP fragment contains an "Identification" field that destination nodes use to reassemble fragmented packets. Many implementations set the Identification field to a predictable value, thus making it easy for an attacker to forge malicious IP fragments that would cause the reassembly procedure for legitimate packets to fail. NIDS aims at identifying malicious activity by analyzing network traffic. Ambiguity in the possible result of the fragment reassembly process may allow an attacker to evade these systems. Many of these systems try to mitigate some of these evasion techniques (e.g. By computing all possible outcomes of the fragment reassembly process, at the expense of increased processing requirements).
As mentioned in , upper-layer protocols can be configured to rely on PMTUD. Because PMTUD relies upon the network to deliver ICMP PTB messages, those protocols also rely on the networks to deliver ICMP PTB messages. According to , ICMP PTB messages must not be filtered. However, ICMP PTB delivery is not reliable. It is subject to both transient and persistent loss. Transient loss of ICMP PTB messages can cause transient PMTU black holes. When the conditions contributing to transient loss abate, the network regains its ability to deliver ICMP PTB messages and connectivity between the source and destination nodes is restored. of this document describes conditions that lead to transient loss of ICMP PTB messages. Persistent loss of ICMP PTB messages can cause persistent black holes. , , and of this document describe conditions that lead to persistent loss of ICMP PTB messages. The problem described in this section is specific to PMTUD. It does not occur when the upper-layer protocol obtains its PMTU estimate from PLPMTUD or from any other source.
The following factors can contribute to transient loss of ICMP PTB messages: Network congestion. Packet corruption. Transient routing loops. ICMP rate limiting. The effect of rate limiting may be severe, as RFC 4443 recommends strict rate limiting of IPv6 traffic.
Incorrect implementation of security policy can cause persistent loss of ICMP PTB messages. Assume that a Customer Premise Equipment (CPE) router implements the following zone-based security policy: Allow any traffic to flow from the inside zone to the outside zone. Do not allow any traffic to flow from the outside zone to the inside zone unless it is part of an existing flow (i.e., it was elicited by an outbound packet). When a correct implementation of the above-mentioned security policy receives an ICMP PTB message, it examines the ICMP PTB payload in order to determine whether the original packet (i.e., the packet that elicited the ICMP PTB message) belonged to an existing flow. If the original packet belonged to an existing flow, the implementation allows the ICMP PTB to flow from the outside zone to the inside zone. If not, the implementation discards the ICMP PTB message. When a incorrect implementation of the above-mentioned security policy receives an ICMP PTB message, it discards the packet because its source address is not associated with an existing flow. The security policy described above is implemented incorrectly on many consumer CPE routers.
Anycast can cause persistent loss of ICMP PTB messages. Consider the example below: A DNS client sends a request to an anycast address. The network routes that DNS request to the nearest instance of that anycast address (i.e., a DNS Server). The DNS server generates a response and sends it back to the DNS client. While the response does not exceed the DNS server's PMTU estimate, it does exceed the actual PMTU. A downstream router drops the packet and sends an ICMP PTB message the packet's source (i.e., the anycast address). The network routes the ICMP PTB message to the anycast instance closest to the downstream router. That anycast instance may not be the DNS server that originated the DNS response. It may be another DNS server with the same anycast address. The DNS server that originated the response may never receive the ICMP PTB message and may never update its PMTU estimate.
Unidirectional routing can cause persistent loss of ICMP PTB messages. Consider the example below: A source node sends a packet to a destination node. All intermediate nodes maintain a route to the destination node, but do not maintain a route to the source node. In this case, when an intermediate node encounters an MTU issue, it cannot send an ICMP PTB message to the source node.
In RFC 7872, researchers sampled Internet paths to determine whether they would convey packets that contain IPv6 extension headers. Sampled paths terminated at popular Internet sites (e.g., popular web, mail and DNS servers). The study revealed that at least 28% of the sampled paths did not convey packets containing the IPv6 Fragment extension header. In most cases, fragments were dropped in the destination autonomous system. In other cases, the fragments were dropped in transit autonomous systems. Another recent study confirmed this finding. It reported that 37% of sampled endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response. It is difficult to determine why network operators drop fragments. Possible causes follow: Hardware inability to process fragmented packets. Failure to change vendor defaults. Unintentional misconfiguration. Intentional configuration (e.g., network operators consciously chooses to drop IPv6 fragments in order to address the issues raised in through , above.)
The Transport Control Protocol (TCP)) can be operated in a mode that does not require IP fragmentation. Applications submit a stream of data to TCP. TCP divides that stream of data into segments, with no segment exceeding the TCP Maximum Segment Size (MSS). Each segment is encapsulated in a TCP header and submitted to the underlying IP module. The underlying IP module prepends an IP header and forwards the resulting packet. If the TCP MSS is sufficiently small, the underlying IP module never produces a packet whose length is greater than the actual PMTU. Therefore, IP fragmentation is not required. TCP offers the following mechanisms for MSS management: Manual configuration PMTUD PLPMTUD Manual configuration is always applicable. If the MSS is configured to a sufficiently low value, the IP layer will never produce a packet whose length is greater than the protocol minimum link MTU. However, manual configuration prevents TCP from taking advantage of larger link MTU's. Upper-layer protocols can implement PMTUD in order to discover and take advantage of larger path MTUs. However, as mentioned in , PMTUD relies upon the network to deliver ICMP PTB messages. Therefore, PMTUD can only provide an estimate of the PMTU in environments where the risk of ICMP PTB loss is acceptable (e.g., known to not be filtered). By contrast, PLPMTUD does not rely upon the network's ability to deliver ICMP PTB messages. It utilises probe messages sent as TCP segments to determine whether the probed PMTU can be successfully used across the network path. In PLPMTUD, probing is separated from congestion control, so that loss of a TCP probe segment does not cause a reduction of the congestion control window. defines PLPMTUD procedures for TCP. While TCP will never knowingly cause the underlying IP module to emit a packet that is larger than the PMTU estimate, it can cause the underlying IP module to emit a packet that is larger than the actual PMTU. For example, if routing changes and as a result the PMTU becomes smaller, TCP will not know until the ICMP PTB message arrives. If this occurs, the packet is dropped, the PMTU estimate is updated, the segment is divided into smaller segments and each smaller segment is submitted to the underlying IP module. The Datagram Congestion Control Protocol (DCCP) and the Stream Control Transport Protocol (SCTP) also can be operated in a mode that does not require IP fragmentation. They both accept data from an application and divide that data into segments, with no segment exceeding a maximum size. DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms for managing that maximum size. Datagram protocols can also implement PLPMTUD to estimate the PMTU via. This proposes procedures for performing PLPMTUD with UDP, UDP-Options, SCTP, QUIC and other datagram protocols. Currently, User Data Protocol (UDP) lacks a fragmentation mechanism of its own and relies on IP fragmentation. However, proposes a fragmentation mechanism for UDP.
recognizes that IP fragmentation reduces the reliability of Internet communication. It also recognizes that UDP lacks a fragmentation mechanism of its own and relies on IP fragmentation. Therefore, offers the following advice regarding applications the run over the UDP. "An application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself to determine whether the path to a destination will support its desired message size without fragmentation." RFC 8085 continues: "Applications that do not follow the recommendation to do PMTU/PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter than the default effective MTU for sending (EMTU_S in ). For IPv4, EMTU_S is the smaller of 576 bytes and the first-hop MTU. For IPv6, EMTU_S is 1280 bytes . The effective PMTU for a directly connected destination (with no routers on the path) is the configured interface MTU, which could be less than the maximum link payload size. Transmission of minimum-sized UDP datagrams is inefficient over paths that support a larger PMTU, which is a second reason to implement PMTU discovery." RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently small is sufficiently small to be supported by most current Internet paths, even though the IPv4 minimum link MTU is 68 bytes. This advice applies equally to any application that runs directly over IP.
The following applications rely on IPv6 fragmentation: DNS OSPFv3 Packet-in-packet encapsulations Each of these applications relies on IPv6 fragmentation to a varying degree. In some cases, that reliance is essential, and cannot be broken without fundamentally changing the protocol. In other cases, that reliance is incidental, and most implementations already take appropriate steps to avoid fragmentation. This list is not comprehensive, and other protocols that rely on IP fragmentation may exist. They are not specifically considered in the context of this document.
DNS relies on UDP for efficiency, and the consequence is the use of IP fragmentation for large responses, as permitted by the DNS EDNS(0) options in the query. It is possible to mitigate the issue of fragmentation-based packet loss by having queries use smaller EDNS(0) UDP buffer sizes, or by having the DNS server limit the size of its UDP responses to some self-imposed maximum packet size that may be less than the preferred EDNS(0) UDP Buffer Size. In both cases, large responses are truncated in the DNS, signalling to the client to re-query using TCP to obtain the complete response. However, the operational issue of the partial level of support for DNS over TCP, particularly in the case where IPv6 transport is being used, becomes a limiting factor of the efficacy of this approach . Larger DNS responses can normally be avoided by aggressively pruning the Additional section of DNS responses. One scenario where such pruning is ineffective is in the use of DNSSEC, where large key sizes act to increase the response size to certain DNS queries. There is no effective response to this situation within the DNS other than using smaller cryptographic keys and adoption of DNSSEC administrative practices that attempt to keep DNS response as short as possible.
OSPF implementations can emit messages large enough to cause fragmentation. However, in order to optimize performance, most OSPF implementations restrict their maximum message size to a value that will not cause fragmentation.
In this document, packet-in-packet encapsulations include IP-in-IP , Generic Routing Encapsulation (GRE) , GRE-in-UDP and Generic Packet Tunneling in IPv6. describes fragmentation issues associated with all of the above-mentioned encapsulations. The fragmentation strategy described for GRE in has been deployed for all of the above-mentioned encapsulations. This strategy does not rely on IP fragmentation except in one corner case. (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). Section 3.3 of further describes this corner case. See for further discussion.
Some UDP applications rely on IP fragmentation to achieve acceptable levels of performance. These applications use UDP datagram sizes that are larger than the path MTU so that more data can be conveyed between the application and the kernel in a single system call. To pick one example, the Licklider Transmission Protocol (LTP),which is in current use on the International Space Station (ISS), uses UDP datagram sizes larger than the path MTU to achieve acceptable levels of performance even though this invokes IP fragmentation. More generally, SNMP and video applications may transmit an application-layer quantum of data, depending on the network layer to fragment and reassemble as needed.
Developers SHOULD NOT develop new protocols or applications that rely on IP fragmentation. When a new protocol or application is deployed in an environment that does not fully support IP fragmentation, it SHOULD operate correctly, either in its default configuration or in a specified alternative configuration. Developers MAY develop new protocols or applications that rely on IP fragmentation if the protocol or application is to be run only in environments where IP fragmentation is known to be supported. Legacy protocols that depend upon IP fragmentation SHOULD be updated to break that dependency. However, in some cases, there may be no viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-in-IP encapsulation). In these cases, the protocol will continue to rely on IP fragmentation but should only be used in environments where IP fragmentation is known to be supported. Protocols may be able to avoid IP fragmentation by using a sufficiently small MTU (e.g. The protocol minimum link MTU), disabling IP fragmentation, and ensuring that the transport protocol in use adapts its segment size to the MTU. Other protocols may deploy a sufficiently reliable PMTU discovery mechanism (e.g.,PLMPTUD). UDP applications SHOULD abide by the recommendations stated in Section 3.2 of .
Software libraries SHOULD include provision for PLPMTUD for each supported transport protocol.
Middle boxes should process IP fragments in a manner that is consistent with and . In many cases, middle boxes must maintain state in order to achieve this goal. Price and performance considerations frequently motivate network operators to deploy stateless middle boxes. These stateless middle boxes may perform sub-optimally, process IP fragments in a manner that is not compliant with RFC 791 or RFC 8200, or even discard IP fragments completely. Such behaviors are NOT RECOMMENDED. If a middleboxes implements non-standard behavior with respect to IP fragmentation, then that behavior MUST be clearly documented.
In their default configuration, when the IPv6 Flow Label is not equal to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP) Routing as described in OSPF and other routing protocols, Link Aggregation Grouping (LAG), or other load-balancing technologies SHOULD accept only the following fields as input to their hash algorithm: IP Source Address. IP Destination Address. Flow Label. Operators SHOULD deploy these devices in their default configuration. These recommendations are similar to those presented in and . They differ in that they specify a default configuration.
Operators MUST ensure proper PMTUD operation in their network, including making sure the network generates PTB packets when dropping packets too large compared to outgoing interface MTU. However, implementations MAY rate limit ICMP messages as per and . As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB messages unless they are known to be forged or otherwise illegitimate. As stated in , filtering ICMPv6 PTB packets causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. As per RFC 8200, network operators MUST NOT deploy IPv6 links whose MTU is less than 1280 bytes. Network operators SHOULD NOT filter IP fragments if they are known to have originated at a domain name server or be destined for a domain name server. This is because domain name services are critical to operation of the Internet.
This document makes no request of IANA.
This document mitigates some of the security considerations associated with IP fragmentation by discouraging its use. It does not introduce any new security vulnerabilities, because it does not introduce any new alternatives to IP fragmentation. Instead, it recommends well-understood alternatives.
Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, Lorenzo Colitti, Gorry Fairhurst, Mike Heard, Tom Herbert, Tatuya Jinmei, Jen Linkova, Paolo Lucente, Manoj Nayak, Eric Nygren, Fred Templin and Joe Touch for their comments.
IPv6, Large UDP Packets and the DNS (http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html) "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524
Measuring ATR Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection Secure Networks, Inc. Secure Networks, Inc.
--Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

--Apple-Mail=_DDEE4577-7577-4F38-ADE9-014E82F1D1EE-- --Apple-Mail=_F3EDB0A0-49CE-462E-AAD2-05FCBD6A9C66-- --Apple-Mail=_A4FE684D-7768-4A13-8C85-92CF193829D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0NFigACgkQEhdRnd2G P+AtOxAAx4QFXXfSJjxrma9zpOoev/lio5gk2L/8jpnMVwcsUA0PvFkmo8eBL9mr P+pPPTm6IjXMYX9WWLLD5EXC/1tN3Z2vZ0IdKbFEuuewkUKcVaqYipOflKbN8Po/ tX84OmoL+Ohtl/xmxTfv3EGRn9epVWKGtP8feM5+3HJvuJyraeQ7hGZvAeCR4XAV h450cqWMzJhaBJi8yiDgg/TaHF+E7Eszkf2uhmUX2d1loVI9x/YdLgE9t5tO5o51 u4fDX2n5bZX4Dtrro9D6NxDxXzkVJPYQJnL+tKIwGFVkuYz86zLHjn1J+MYIorqs cFvhLbzwnmnJf1oIlVp19O5GUhVYtKB/JcS76y+QZbEEFqkAje/q3E7YbgxLWZfg WeD22Jpx92yGNoVUL+7nmP8OVumRjmdqI7ZbVteXmRPunBErMCmaxY67O7ndt3iM a1u176CCHDd2Uxbb2HgrxL8zqrTyLm1VQsIBzEXFU+mMMSRXjBxa1oFEf0IAQ08F B6SZeULN6JnYj6GQEPTXVjgRtYNU6upsHNK3XOtnB9veOCr+YBWZ1hIzNd617bWH yhCGamLg8sAw3+8scBpL6AzR7r8ScRGimBEWNH0wVrbXgG4qh10PfwWwlAJkat87 SBBtlsGLEKBEYQZEecXnAnpMYKAIT4ZEHvOdnomdWwB5Vf/jRow= =amw9 -----END PGP SIGNATURE----- --Apple-Mail=_A4FE684D-7768-4A13-8C85-92CF193829D8-- From nobody Fri Jun 21 10:51:24 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1C12008B for ; Fri, 21 Jun 2019 10:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 ktJT4QDREpU3 for ; Fri, 21 Jun 2019 10:51:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8D29C12001A for ; Fri, 21 Jun 2019 10:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1561139474; bh=7E0O9BS2gp0DWtMAbuL6K1gJcbuldG4RzIxKVZ5fFnk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=jTmuxQAliJZhAWkVN7zJNeLhi80fWL25vRpm7GpYHJvhzBkciiA1T00ZLiaKABlB0 7LN8xZSneshUGGE8RwZgkeJbepmoC11aTr1DrbWSYsv/aaSbbcpkydGVjN7xBLPQjs 0bKMuHsmWx2xOYG60nVjobZH1Ek/xoySI2xKcKjw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.55.38]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRmjw-1i3E762omI-00TFsq; Fri, 21 Jun 2019 19:51:14 +0200 To: Fred Baker , xml2rfc@ietf.org References: <528CC4D0-0E22-437E-A3FE-D9DEC4FBBF56@gmail.com> From: Julian Reschke Message-ID: Date: Fri, 21 Jun 2019 19:51:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <528CC4D0-0E22-437E-A3FE-D9DEC4FBBF56@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:KnSj0tmwRGu8QLm1nKhnpxtESp3QqVTF1n4diiI2TLcTA2wR+6/ +8+0EDmcZc3N1mkdTnWmTcCLnTQhUAQFeYSBROexVg8o0kE4F1QgjXuRhL4W8EHhhI5QjuP YuB85+dnZgxumUzylYp6bv2wGovzOhEoOvm5bzIcxGim8G1EhrbBezMRw+IvBgH5ge/iNw9 G153HSR1+kX1V+ODc/PYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:HiKaewtg/gI=:5OhYHH3/jSUIagAAFEf0Kk 4ZpItq3UiNoo7HNQHs51/9CnlBmQZp8PGi5zgN7qi4+xjPoO7e67Nnj/0c5x6Hq/zXuDgqmKi rU1JORB1T595Q1gXir4bnhdGOn8v2qXey6YcdHK96tx4Hg+GiYOsv7Q7XfHRbmk8SPsqzryx5 265mB3HItjcusRylKTuOmTtuN/gAscRGTk8bQt2OdmuFqLByT8m3MpeXNK+ghRoz7O3kepJLp UzN/Xiucc+6/amX7HK5n/nzdeKPZoDUBOHycQDmYg+wkjEIDNt1H8ghlicLdT7IRtfkvl6qDw s/z23mCtsSeQxomcdT6692emWKvTQi5un13FO25BfpT0/GmzpX+zfaIhlAPMqZMiOC8dczD/v xyNZHNDRlCKn7huXgBNDJElv4t312B7MIouclLFDlZJYUCzdMGEGgr9nVjxpqVhbQxfDUMsSe 7uXVCngEJBnqO30OVRcVoNCFtqC9w7UGp2es8ykY1NzAujI5JcaVMdEBVX7LieD91by4JdjIY cZEGm8b7uulWwCq1yjSwqIrgH+BQUJvdiZ9M3+vH7nCP9Gh3lKXJcvE/LRT/94RxkuqupT2CP q1G7dMtle5fJfBs0GDddfNHbGawoxGAxE6hFQttX7xGoE5DVQVtqvvtposDCrwi0TvWHJRhs6 mCxh2Dfg+Ck331e024Th6WomCVcneJ7KsT8H7SV1Q0BgPi4JSRPStEVPataNa5OZno/1Iff+6 00Pi/KxpqIPIfd38uQaQ693i+/6GXseY6HpduBrJkwoH65rsKsK/9jjs0LU7JYFjtQ+7NdoK6 hyk3HF7rk5cTM64mATUW3pkJYtdIlIx6WSPMtVRT9b1iDJEiyMPAJ2rHhEdJdcRovP8GE0yx8 j5y0t2XK9MTbDCWqUoS0jmkwS4EmIfNct/ss7PKGt3hBYOxDodjdOuE/wRc61l+l6UkENhBbN roHTsK1q6GiK8gNsLlmtkcxFwge1+3YjXHpvdOoysRv1sUeSmH7Eq Archived-At: Subject: Re: [xml2rfc] Fwd: Last Call: (IP Fragmentation Considered Fragile) to Best Current Practice X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 17:51:22 -0000 On 21.06.2019 19:38, Fred Baker wrote: > I have a question for some wise person regarding XML2RFC. I have > attached the current XML and TXT versions of a draft we have in last > call right now, and I'm casting round for the correct fix for the second > of the nits pointed out in this email. What is the proper way to > reference a URL in the context I did in this draft? > > I suspect it's in a reference , but it's a structure that I have never > quite gotten my head around. > ... >> 2.) Section 4.6, Security Vulnerabilities, 2nd bullet (page 11): it >> took me some poking around to figure out that I was supposed to splice >> the two URLS together to get >> https://web.archive.org/web/20110723091910/http://www.digital.net/~gand= alf/Rose_Frag_Attack_Explained.htm. >> I'm aware that the problem of rendering the long URL is due to the >> line length limit of RFCs, but is there maybe a way to get the >> underlying hyperlink to come out right in the html version of the >> published RFC, as is done with the references? >> >> Sorry for not catching these things earlier during the WG process. > ... There is no published proper HTML. What tools.ietf.org has is the text version, converted to HTML with heuristics that transforms certain parts of the text into HTML links. So if a long URI is broken across lines in the text, it's unlikely to be treated "correctly" by that transformation. The published ID currently says: o Resource exhaustion attacks (such as the Rose Attack, https://web.archive.org/web/20110723091910/ http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm) I'd recommend to use the following XML: > https://web.archive.org/= web/20110723091910/http://www.digital.net/~gandalf/Rose_Frag_Attack_Explai= ned.htm If there *was* a published proper HTML version (once the transition to xml2rfc v3 has happened), this should work. Best regards, Julian From nobody Fri Jun 21 10:52:30 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1301D120096 for ; Fri, 21 Jun 2019 10:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 dl-pxJ_QtJfd for ; Fri, 21 Jun 2019 10:52:27 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 2F06F120092 for ; Fri, 21 Jun 2019 10:52:27 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id j2so3978236pfe.6 for ; Fri, 21 Jun 2019 10:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JH/ozFtRNMkOjT034Zoz5DwE1AwUS9KjZAoU8yv9Kzs=; b=vgJ42GrND8ybIJIEHfzqEaGmOsgRgRYOrQhdcIP1ffGwUA050ISBtjPWdkWz34hpgv B3QEub08twNhFwZbdtchG8dlXUtuFLXMXhJeba5V/yPeNp4NZtJNh90ArB8dsqaSnXuQ j0lnUeOXvLbg8meETaqae0IHaXDduo7UKVfcknrayTAaE+z3f3kqKePXb6NbiaiF9Sad ykO+OxffE05JGeu0nFF+qmKNAWy4JJ7+0m90AzfBcFwEfGFS8mJ9xkiPCOIjri3dR4xL cNM4aS7o9hc5NpL03boNYo3y9L81rok37HZVABOlJr2dRfQfAgpssJixNZKSdNx/XwAZ 8Mmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JH/ozFtRNMkOjT034Zoz5DwE1AwUS9KjZAoU8yv9Kzs=; b=jtIltSsvgguWJjJxH2nKVsGuyZdzTwJgkwETJbBmA3YjVTkl1F2wcS17tC+NOVfg8X 4V76cBpojT1+05rkVETFlJGLdUNFRinbJ42Uj9ukZSRM0MhQZSm015R1bhsvk2BaKe5o Fx/jJBMb4ukRTLnYtqrkmfO9cDeDUqE3b5f6K4H99YbIPOz3dO6Rsci3iYBwbvmuGT/c v1+0RNzhzIo5mYLzEZv68cRte9qbnZLaif9FLuJO8OGf2JLhjtdfNnLFfStUnbSX/FoE kv+BmozJL5Mlh5iX+qRPrIZiEdAeIBIZR2Qq00QoLxHHHuPtLMsf3zSBYSefPer+1WqX XCkw== X-Gm-Message-State: APjAAAVHMME3Ok5/3IpzxcQIalpIhOfYVQTEqzze/Vfle3zxKQpofWDE 3JBMl7z72xrQlpolYOyNHro= X-Google-Smtp-Source: APXvYqx4l7lrAkQ8kh/bArcmdmyiKG3XUscxuvzyZKAmxxbuufpNXIZSQhT6XN/pCI0y16AkuqHw4Q== X-Received: by 2002:a65:5302:: with SMTP id m2mr19315990pgq.266.1561139546688; Fri, 21 Jun 2019 10:52:26 -0700 (PDT) Received: from 252.66.20.149.in-addr.arpa (252.66.20.149.in-addr.arpa. [149.20.66.252]) by smtp.gmail.com with ESMTPSA id x3sm3962352pja.7.2019.06.21.10.52.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 10:52:26 -0700 (PDT) From: Fred Baker Message-Id: <9E44D125-8EA7-4216-980E-34829A7453C8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4C2E1B22-D941-447F-994F-3339C7613DCF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Jun 2019 20:52:21 +0300 In-Reply-To: Cc: xml2rfc@ietf.org To: Julian Reschke References: <528CC4D0-0E22-437E-A3FE-D9DEC4FBBF56@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [xml2rfc] Fwd: Last Call: (IP Fragmentation Considered Fragile) to Best Current Practice X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 17:52:29 -0000 --Apple-Mail=_4C2E1B22-D941-447F-994F-3339C7613DCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks much. > On Jun 21, 2019, at 8:51 PM, Julian Reschke = wrote: >=20 > I'd recommend to use the following XML: >=20 >> https://web.archive.org/web/2011= 0723091910/http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm<= /eref> >=20 = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_4C2E1B22-D941-447F-994F-3339C7613DCF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0NGVUACgkQEhdRnd2G P+CsTg//ZDHAVClIPPoe5ED0sfpiG0qXy4KssHfWL4ALm+Ff8HgnRb9JscJH3rt8 2z5QBxZB0IsdlnnkWwHybzXmEnRIGGkh2PnGkYsXX/vllnQN44bDWwkiV2BS+NsG +rIxVi79oN4mhDICsR2VHFvu84I8ksJ+9oQ4XJVDAlWQEAwhPsgf2uCfGbNKO7Iu uxG30CJy4Dnnvv6HjnQT8CgLgMujX1HQksIrIToY6jwM3U5n/grGN7USzbyM+DRX rOJ3uqoYBAfCiMjGmBTTo7/joQmyOpnfkfObm8RfnJr2RaLHi5JjiIm5gqCJ++wk xMhhXF/8gJf6P0tIYJ5lofy6WE6ZCxKD9SoYn/iccWEkW2bkR2lJg01zBHP6IR/k lEwiAvsXJijD5DVccY6yTcqoFfSZ2WhUYBpdkNuOU34rY/5BFfZ0BfZxz1S8PDsO Y7xmA6RCsc7VgM9UNHb6AoZ9hMMxqQXwuWMYVW99x59mTF7ZkafdSO95zBVRnXrf UHiqYg5FZEfAiqdBpS186IRN4hkLX13cTp5fvRU/DvfyRlmUU6GVfnVUEfzLAM55 WtLGK8RXCCZHASyyE+p2dqN8/R1tcO1i+KGS8pL3/epl+PpGWMlCqU2y9acT49ZB 7bS72Uuki2BfSpxrGT/9eGct2qbGd8kPuZA9e8g5LHgmUGwH9lQ= =5hxJ -----END PGP SIGNATURE----- --Apple-Mail=_4C2E1B22-D941-447F-994F-3339C7613DCF-- From nobody Thu Jun 27 04:33:45 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88A1200B8; Thu, 27 Jun 2019 04:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2Ont6DoOY0DK; Thu, 27 Jun 2019 04:33:34 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84C112004A; Thu, 27 Jun 2019 04:33:34 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1hgSek-0004w5-76; Thu, 27 Jun 2019 04:33:34 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Thu, 27 Jun 2019 04:33:34 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.23.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 11:33:37 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.23.0, generated when running the mkrelease script. Release notes: xml2rfc (2.23.0) ietf; urgency=medium This release adds v2v3 support for conversion of v2 code with both text and external image sources to v3 format, and provides improved cache handling. It also contains a long list of bugfixes. Here is an excerpt from the commit log: * Fixed an issue where cache clearing did not consider custom cache locations. * Added retry on connection error for external includes. This fixes an issue which has appearing more often recently, where the first connection to fetch a reference file has failed to provide the right redirect. * Added inclusion of metadata.js in the html renderer, for future handling of dynamic metadata (updated-by and obsoleted-by information, for instance). Added a default instance of the metadata javascript file to the distribution, and added an command-line option to specify an alternative version of the javascript metadata script. * Added